Re: 'wait -n' with and without id arguments

[Zachary Santer]

On Fri, Aug 9, 2024 at 10:38 AM Chet Ramey <chet.ramey@case.edu> wrote:
>
> OK, I see what's happening. When the shell is interactive, it notifies
> the user when a background job terminates and prints a message to the
> terminal. That's the series of
>
> [2]   Done                    random_sleep
>
> messages you see.
>
> Once that happens, the shell considers the job `notified' and removes it
> from the jobs table. That's when it moves to the list of saved background
> pids and statuses. It's available there for `wait' when you supply a pid
> argument, but no longer eligible to be returned by `wait -n' without
> arguments, since it's already terminated and the user has been notified of
> the status.
>
> When I source your script on macOS with the current devel build, I get the
> set of notification messages and termination with a false argument, and an
> infinite loop with a true argument.

I don't necessarily understand why someone would call 'wait -n' from
the interactive shell, so I don't really know what the desired
behavior would be when they do so. Would be nice if other people want
to chime in on that point.

Recapping some stuff I've already said:

- If you didn't know how bash handled child processes internally, it
might be more natural to expect the behavior of 'wait -n' without id
arguments to be consistent between a script and the interactive shell.
For this to be the case, 'wait -n' without id arguments would have to
look in the list of saved background pids and statuses. even though
the user has already been notified of those.

- 'wait' without id arguments doesn't look in the list because doing
so would serve no purpose, as it doesn't return the termination status
of any background process. Given that, 'wait -n' ignoring the list,
simply because 'wait' does, doesn't make any sense.

- From what little of the original discussion I read, and then what
happened in the "waiting for process substitutions" thread, I thought
'wait -n' without arguments would also ignore child processes that had
already terminated in a script. I'm glad it doesn't, but you might be
able to see some benefit to consistent behavior, here.