Re: wait -n shouldn't collect multiple processes

[Robert Elz]

    Date:        Mon, 25 Mar 2019 10:49:32 -0400
    From:        Chet Ramey <chet.ramey@case.edu>
    Message-ID:  <9c536452-4f4e-b309-7a99-e85235364a3a@case.edu>

Great to see that revised description of how it works, that makes
much more sense.   I also should have tested it.

  | `wait -n' is only useful in scripts with job control enabled,

Why is that?   It should be useful in any script that has started multiple
asynchronous jobs, job control (for this) should be irrelevant, I would
have thought (what's more, so it seems to be).

  | so let's
  | run a quick test and see what happens under those conditions.
  |
  | Given the following script:

I ran the same script under the NetBSD sh with the same results (kind of,
given it all depends upon the order in which the 4 "sleep 5" processes
happen to complete)

I removed the "set -m", that made no difference, not with the NetBSD sh,
nor bash 4 or bash 5 (bash 2, the only other bash I have available
to test doesn't have wait -n so that test was useless...)

Then I modified the test to add "echo $!" after each background job
is started (so we know what pids are assigned to the subshells) and
changed the wait -n to
         wait -n -p who
and the following echo to include "from $who"   (This is for the NetBSD
sh only, right now anyway)

[jinx]$ /bin/sh /tmp/AB
3020
3330
27447
9894
wait return status: 1 from 3020
wait return status: 3 from 27447
wait return status: 2 from 3330
wait return status: 4 from 9894
[jinx]$ /bin/sh /tmp/AB
201
16865
5886
2065
wait return status: 4 from 2065
wait return status: 2 from 16865
wait return status: 3 from 5886
wait return status: 1 from 201

kre

ps: the other advantage of use of -p, is that it allows the script
to tell between exit status 127 that comes from either

        /no/such/command &
        wait -p pid $!
or
        {exit 127;} &
        wait -p pid $!

(though not to distinguish those cases, as from the context of the
parent shell they are identical) - in each case there $pid
becomes the same as $! (and $? becomes 127).

and

        whatever &
        wait -p pid $RANDOM

which also (usually) returns 127 (without waiting for anything)
but that one causes $pid to be unset.   That is, the error return from
wait for "id does not represent a child" can be distinguished from
"child returned status 127", which cannot otherwise be done.

The definition of "-p var" is that the wait command first unsetd var
(and errors if var is read only, or not a valid var name), and then
if the status from some process is returned, sets var to the pid of
that process (or lead process id of a process group).

And yes, that makes
        wait -p var
equivalent to
        unset var; wait
which isn't particularly useful, but what else could it do?