On Fri, Dec 2, 2011 at 8:24 AM, Peng Yu wrote:
> Hi,
>
> ~$ cat ../execute.sh
> #!/usr/bin/env bash
>
> echo "$@"
> "$@"
>
> $ ../execute.sh ls >/tmp/tmp.txt
> $ cat /tmp/tmp.txt #I don't want "ls" be in the file
> ls
> main.sh
>
> '>' will not work unless eval is used in execute.sh.
Hi,
~$ cat ../execute.sh
#!/usr/bin/env bash
echo "$@"
"$@"
$ ../execute.sh ls >/tmp/tmp.txt
$ cat /tmp/tmp.txt #I don't want "ls" be in the file
ls
main.sh
'>' will not work unless eval is used in execute.sh.
$ ../execute.sh ls '>' /tmp/tmp.txt
ls > /tmp/tmp.txt
ls: cannot
* Bob Proulx schrieb am 01.12.11 um 05:34 Uhr:
> Marc Schiffbauer wrote:
> > Greg Wooledge schrieb:
> > > Marc Schiffbauer wrote:
> > > > echo {0..1000}>/dev/null
> > > >
> > > > This makes my system starting to swap as bash will use several GiB of
> > > > memory.
> > >
> > > In my opinion, no
* Chet Ramey schrieb am 01.12.11 um 02:54 Uhr:
> That's probably the result of the power-of-two allocation policy in the
> bash malloc. When this came up before, I wrote:
>
> ==
> That's not a memory leak. Malloc implementations need not release
> memory back to the kernel; the bash mall
Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: darwin11.2.0
Compiler: /Developer/usr/bin/clang
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386'
-DCONF_OSTYPE='darwin11.2.0' -DCONF_MACHTYPE='i386-apple-darwin11.2.0'
-DCONF_VENDOR='apple' -DLOCALED
