Hello-
I was somewhat surprised to see the following behavior (this is 3.1.17):
$ x=0; /bin/echo > /tmp/$((++x)); echo $x
0
$ x=0; echo > /tmp/$((++x)); echo $x
1
I guess in the first case the expansion of $((++x)) is taking place after
forking, whereas in the second case there is no forked proc
cwillu wrote:
>> Jérôme REYBERT wrote:
>>> ...
>>>
>>> menu-complete is not able to complete file names. However, it can
>>> complete directories names. Here to reproduce:
>>> $ mkdir bar1 bar2
>>> $ touch foo1 foo2
>>> $ ls ba
>>> $ ls bar1/ # OK
>>> $ ls fo # nothing append
>> Thanks for the repo
Hi!
On Sun, Sep 27, 2009 at 11:06:43PM -0400, Chet Ramey wrote:
> > Description:
> > Looks like 'wait' command in bash-4 is broken: if used together
> > with 'trap myhandler SIGCHLD' the 'wait' (without params) exit
> > just after receiving first child exit, instead of wait
> Jérôme REYBERT wrote:
> > ...
> >
> > menu-complete is not able to complete file names. However, it can
> > complete directories names. Here to reproduce:
> > $ mkdir bar1 bar2
> > $ touch foo1 foo2
> > $ ls ba
> > $ ls bar1/ # OK
> > $ ls fo # nothing append
>
> Thanks for the report. This has a
> > This was reported as a bug against bash-3.2.
>
> Cool. Is there any hint/doc/faq/how-to implement old behaviour, i.e. wait
> until all children of current bash process will exit?
I imagine a loop on wait until it returns because there are no unwaited-for
children. You can detect the "interru
