Re: wait -n misses signaled subprocess

[Robert Elz]

    Date:        Sun, 28 Jan 2024 18:21:42 -0500
    From:        Chet Ramey <chet.ramey@case.edu>
    Message-ID:  <3347f790-529b-4bee-91fd-de39bed3f49e@case.edu>

  | because `wait -n' doesn't look in the table
  | of saved statuses -- its job is to wait for `new' jobs to terminate, not
  | ones that have already been removed from the table.

That's very interesting, and most unexpected information.

I always wondered why the option was 'n' - I would have made it
be 'a' probably, as a shorthand for "any" - but then I decided
that perhaps 'n' was a better choice, as "a" could also be "all",
the option name would not be providing any real clue at all, so
I assumed you'd been ultra clever and used 'n' as the next char
in "any" and also as it can be read like the first part of "en" "ee"
(which you need to say out loud, or at least in your head, to get the
effect of).

It never even dawned on me that 'n' might mean "new", as in only
processes that hadn't terminated at the time the wait -n was done,
as that's essentially a recipe for script madness, race conditions
galore, as the one reported here.

What wait(1) needed was an alternative to its normal "all" semantic,
just "wait" waits for every background job to terminate, what's needed
is a way to wait for any one of them (whether already terminated, but
not previously waited for or not).   That's what I always assumed
wait -n was doing, and how I implemented it in the NetBSD shell.

Similarly "wait pid1 pid2 pid3" waits for all 3 of those to
terminate, so "wait -n pid1 pid2 pid3" should wait for any one
of them - already terminated or not.   When there's just one pid
in the list, the -n option always seemed useless to me, there
ought be no difference between "wait pid" and "wait -n pid"
(as in wait for all of one, and wait for any of one, mean the
same thing, wait for that one), but obviously should still be
supported for consistency.   To think that it might be interpreted
as "wait for a new process "pid" to terminate, ignoring the one that
just finished a few milliseconds ago" is simply astounding, completely
unbelievable.

And from what I have seen of the other comments, several from
long term & dedicated bash users, it is just as astounding to
them as well.   Please treat this as a bug, and fix it.  Quickly.

kre