Re: process substitution and wait()

[Daniel Kahn Gillmor]

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