Date: Mon, 14 Jul 2025 10:34:12 -0400
From: Chet Ramey <chet.ra...@case.edu>
Message-ID: <6a02a36f-d31d-4816-8988-5a4ccf960...@case.edu>
| The short story is that `wait -n' now returns the status of any process
| that's completed and hasn't been waited for yet, just like `wait'. It's
| not restricted to processes that terminates after it's invoked.
That's fine, and as it should be. But
| It does this even when it's given a list of pid or job arguments,
That makes no sense at all. wait & wait -n should be more or less
the same, with the -n just meaning "any process" (or next, including
already, to exit), and without -n "all". Then given a list of 1 or
more pid/job args, the wait is restricted to apply to just those
processes (or jobs) - with -n it should wait for any of them, without
-n it waits for all of them. All very orthoganal and useful. The way
you have described it, the list of pids given along with -n are just
a waste of args, achieving nothing at all. That's pointless.
| In fact, your script above
| doesn't need `wait -n' at all; it can use `wait'.
For the abbreviated test case that was given, that's true, but
that's almost certainly what whatever real code encountered this
problem was doing - you should assume that there are other bg
processes running, which it is not intended to wait for, and
potentially other already exited processes which will be waited
for later. Usually (or at least often) the exit status is wanted
as well.
With those restrictions the test program could still work (I assume)
using just "wait !$" - using -n when there is only one candidate doesn't
make a lot of sense, but again, I assume that the real code has more
than that.
kre
