Re: 5.0 regression: Script stuck when waiting in trap

[mwnx]

On Mon, Jun 03, 2019 at 03:42:22PM -0400, Chet Ramey wrote:
> Here's what happens. The relevant change is that wait without options now
> waits for the last process substitution, since that sets $! and is "known"
> to the shell.
>
> The sequence of events is approximately:
>
> 1. Subshell starts, forks to run process substitution, opens a pipe to the
>    process substitution, and runs the group command. The group command
>    means the redirection is performed by the subshell, not the `sleep',
>    since the redirections persist for the entire group command.
>
> 2. Main shell starts, runs sleep, kills the subshell started in step 1.
>    This doesn't kill the sleep or the cat. The sleep exits on its own.
>    The cat continues to run.
>
> 3. The main shell waits for the subshell.
>
> 4. The subshell, having received a fatal signal, runs the exit trap and
>    waits for the process substitution ($!). It doesn't have a chance to do
>    anything with the the file descriptor open to the process substitution
>    as the result of the redirection, and the `cat' continues to run because
>    it doesn't get the signal. The wait doesn't complete.
>
> Chet

Thanks for the explanation. In view of the change you describe,
there is another behaviour that I think might qualify as a bug. I'll
give you my actual use case first.

I simply want to make sure all processes running inside a given
subshell are killed on exit. To that means, I set up the following
trap in the shell (and potentially, its subshells and so on):

    trap 'kill $(jobs -p) &>/dev/null || true; wait' EXIT

This was working fine in bash 4.x, despite `jobs -p` not returning
the process ID of process substitutions. But now that `wait` (with
no arguments) waits for process substitutions in addition to
"ordinary" foreground and background processes, the situation is
asymmetric, leading to my subshells freezing when killed while a
process substitution is running.

So, although I realise that complete backwards compatibility is not
to be expected since this is a new major version, it would in my
opinion be consistent to have `jobs`'s output include process
substitutions, and would ensure that the use case I describe remains
supported. If you agree with the sentiment, I could try and submit a
patch for the `jobs` command myself if you wish.

--
mwnx
GPG: AEC9 554B 07BD F60D 75A3  AF6A 44E8 E4D4 0312 C726
     ipfs.io/ipfs/QmV4tMgNmqewgcPgX4ktAbrA9jHeiM2DhEFSB4BKxwj75c