On Fri 2019-04-12 12:05:24 -0400, Chet Ramey wrote: > But the execs mean that the shell that is eventually invoked to run the > `wait' is the parent of the process substitution. So the subshell has > children, whether or not it has run the process substitution itself.
Yes, agreed. This is the situation i've been struggling with on the
debian CI infrastructure noted in the original ticket.
> Then the question becomes whether wait without arguments should wait for
> all children of the shell, or whether it should only wait for those
> children it knows it has started.
I agree with you that this is the nub of the question, given that other
(non-bash) processes might end up exec'ing a bash shell despite already
having child proceses.
> I can change the code to wait for just the process substitution processes
> the current shell has started and "are known to the invoking shell". The
> difference between this code and bash-4.4 is that bash-4.4, of course,
> didn't try to wait for process substitution processes at all, and didn't
> care about children that weren't attached to a job (e.g., coprocs). (That
> in itself generated some complaints.)
None of the other bourne-derived shells that i have tried have a builtin
wait that waits on child processes that they didn't directly create.
It's odd that bash 5.0 does this. I don't have any objection to the
wait builtin waiting on coprocesses or on process substitutions that it
knows about.
It seems very odd to me that this bash program:
#!/bin/bash
echo hi there
jobs
wait
might or might not hang forever, depending on whether it inherited some
child processes from before it was exec()ed. In particular, i don't see
how anyone can use the wait builtin with no arguments safely/reliably at
all, if this is the behavior.
What do you think is the right behavior here?
--dkg
signature.asc
Description: PGP signature
