Re: mention what characters need to be escaped inside [...]
On Mon, May 04, 2009 at 12:34:19AM +0800, jida...@jidanni.org wrote: > Maybe mention in the man page at >[...] Matches any one of the enclosed characters... > that one will need to backslash at least any spaces used inside it: > $ ls [^ ] > ls: cannot access [^: No such file or directory > ls: cannot access ]: No such file or directory This isn't due to the behavior of [...] but rather due to word-splitting by the command parser before [...] is handled at all. The unquoted space character causes the word splitting, which is why ls is receiving two arguments. As you can see, the [ and ] are being passed as literal characters, because each of the two words fails to contain both [ and ] to make a whole character-range glob. > $ ls [^\ ] > a The interaction between shell features (in this case, character-range globbing and word splitting) can sometimes be awkward. The intuitive way to handle this would have been "[^ ]" but then you lose the special significance of the [ and ], so that obviously fails. Putting the quotes inside -- [^" "] -- works. But the backslash approach you used is probably the clearest way to write it.
Re: mention what characters need to be escaped inside [...]
Greg Wooledge writes: > quotes inside -- [^" "] -- works. But the backslash approach you used > is probably the clearest way to write it. Anyways, it should be mentioned in the man page's [...] discussion, even though legally one could say it is probably already mentioned, though scattered around the man page.
Re: Memory leak in for loops
On Thursday 30 April 2009 05:56:02 Jan Schampera wrote:
> Sandino Araico Sánchez wrote:
> >1.
> > #!/bin/bash
> >2.
> >
> >3.
> > for i in {0..15000} ; do
> >4.
> > echo $i > /dev/null
> >5.
> > done
> >
> >
> >
> > Repeat-By:
> > Run the script above and the process starts leaking memory very
> > fast.
>
> You know what a memory *leak* is, yes? mallocs() without proper free()s.
>
> What you mean is that your memory is used. Feel free to calculate the
> memory that is needed to store the string representation of
> {0..15000}, I think you will get a number near your RAM size.
granted his example is wrong and his reasoning incorrect, there may actually
be a leak here ...
bash-4.0$ ps -p $$ -F
UIDPID PPID CSZ RSS PSR STIME TTY TIME CMD
vapier 27999 16493 0 5675 3052 1 18:51 pts/100:00:00 bash --norc
bash-4.0$ for n in {0..15000} ; do echo $n; done
^C
bash-4.0$ ps -p $$ -F
UIDPID PPID CSZ RSS PSR STIME TTY TIME CMD
vapier 27999 16493 17 392694 473236 1 18:51 pts/100:00:01 bash --norc
that memory never goes away and bash will chew significant CPU (~10%) while it
should be idle ...
-mike
signature.asc
Description: This is a digitally signed message part.
Re: mention what characters need to be escaped inside [...]
On Monday 04 May 2009 15:46:59 jida...@jidanni.org wrote: > Greg Wooledge writes: > > quotes inside -- [^" "] -- works. But the backslash approach you used > > is probably the clearest way to write it. > > Anyways, it should be mentioned in the man page's [...] discussion, even > though legally one could say it is probably already mentioned, though > scattered around the man page. i dont think so. if we make a special exception here, we need to reproduce random sections of shell quoting rules in many many sections. -mike
Re: Memory leak in for loops
Mike Frysinger wrote:
> On Thursday 30 April 2009 05:56:02 Jan Schampera wrote:
>> Sandino Araico Sánchez wrote:
>>>1.
>>> #!/bin/bash
>>>2.
>>>
>>>3.
>>> for i in {0..15000} ; do
>>>4.
>>> echo $i > /dev/null
>>>5.
>>> done
>>>
>>>
>>>
>>> Repeat-By:
>>> Run the script above and the process starts leaking memory very
>>> fast.
>> You know what a memory *leak* is, yes? mallocs() without proper free()s.
>>
>> What you mean is that your memory is used. Feel free to calculate the
>> memory that is needed to store the string representation of
>> {0..15000}, I think you will get a number near your RAM size.
>
> granted his example is wrong and his reasoning incorrect, there may actually
> be a leak here ...
>
> bash-4.0$ ps -p $$ -F
> UIDPID PPID CSZ RSS PSR STIME TTY TIME CMD
> vapier 27999 16493 0 5675 3052 1 18:51 pts/100:00:00 bash --norc
> bash-4.0$ for n in {0..15000} ; do echo $n; done
> ^C
> bash-4.0$ ps -p $$ -F
> UIDPID PPID CSZ RSS PSR STIME TTY TIME CMD
> vapier 27999 16493 17 392694 473236 1 18:51 pts/100:00:01 bash --norc
>
> that memory never goes away and bash will chew significant CPU (~10%) while
> it
> should be idle ...
That's not a memory leak. Malloc implementations need not release
memory back to the kernel; the bash malloc (and others) do so only
under limited circumstances. Memory obtained from the kernel using
mmap or sbrk and kept in a cache by a malloc implementation doesn't
constitute a leak. A leak is memory for which there is no longer a
handle, by the application or by malloc itself.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Memory leak in for loops
On Monday 04 May 2009 21:12:15 Chet Ramey wrote:
> Mike Frysinger wrote:
> > On Thursday 30 April 2009 05:56:02 Jan Schampera wrote:
> >> Sandino Araico Sánchez wrote:
> >>>1.
> >>> #!/bin/bash
> >>>2.
> >>>
> >>>3.
> >>> for i in {0..15000} ; do
> >>>4.
> >>> echo $i > /dev/null
> >>>5.
> >>> done
> >>>
> >>>
> >>>
> >>> Repeat-By:
> >>> Run the script above and the process starts leaking memory very
> >>> fast.
> >>
> >> You know what a memory *leak* is, yes? mallocs() without proper free()s.
> >>
> >> What you mean is that your memory is used. Feel free to calculate the
> >> memory that is needed to store the string representation of
> >> {0..15000}, I think you will get a number near your RAM size.
> >
> > granted his example is wrong and his reasoning incorrect, there may
> > actually be a leak here ...
> >
> > bash-4.0$ ps -p $$ -F
> > UIDPID PPID CSZ RSS PSR STIME TTY TIME CMD
> > vapier 27999 16493 0 5675 3052 1 18:51 pts/100:00:00 bash
> > --norc bash-4.0$ for n in {0..15000} ; do echo $n; done
> > ^C
> > bash-4.0$ ps -p $$ -F
> > UIDPID PPID CSZ RSS PSR STIME TTY TIME CMD
> > vapier 27999 16493 17 392694 473236 1 18:51 pts/100:00:01 bash
> > --norc
> >
> > that memory never goes away and bash will chew significant CPU (~10%)
> > while it should be idle ...
>
> That's not a memory leak. Malloc implementations need not release
> memory back to the kernel; the bash malloc (and others) do so only
> under limited circumstances. Memory obtained from the kernel using
> mmap or sbrk and kept in a cache by a malloc implementation doesn't
> constitute a leak. A leak is memory for which there is no longer a
> handle, by the application or by malloc itself.
yes, i know what a leak is, but i hadnt thought of the glibc allocator caching
the memory itself. i imagine the cpu usage is simply the glibc allocator
walking its internal structures.
i also dont really care enough about the issue to prove whether it's actually
the glibc malloc implementation at fault vs bash not doing the right thing.
-mike
signature.asc
Description: This is a digitally signed message part.
