Re: wait -n shouldn't collect multiple processes

[Robert Elz]

    Date:        Sat, 23 Mar 2019 11:48:33 -0400
    From:        Chet Ramey <chet.ramey@case.edu>
    Message-ID:  <36545673-c287-6d8a-5e99-004ce9c6b321@case.edu>

  | Yes. It waits for the next process to exit and then reaps all exited
  | children.

That doesn't sound very useful.   Our version (the NetBSD sh) finds one
exited process (job), and returns it (whether it had exited previously,
or not).

Aside from anything else, that makes the exit status of wait -n be
the exit status of exactly 1 job, and the number of times that works
is the same as the number of (previously unwaited for) background jobs
started.

wait also doesn't print (or allow to be printed) "jobs" type exit
status reports - if those are wanted, use jobs instead.

  | If you want to associated an exit status with a process, changing wait -n
  | wouldn't make a difference.

It does when you add the "-p var" option, which returns the pid of the
process (job) that exited as $var

  | What's your goal here? If you want to associate an exit status with a
  | process, you're going to have to save $! and wait for each process in
  | turn.

That involves predicting what order the processes are going to exit.
That's useless when a script is running multiple jobs, and when each
finishes, wants to run the next in its sequence.   That could also be
done by running each sequence in a sub-shell - but then the script has
no control over resource usage, as the sub-shells cannot communicate
with each other (without lots more mechanism) about just how much they
are running, and a sub-shell can't determine when one of its siblings
has finished (both of which are trivial when it is all done from one
shell).

In bash as it stands, using a SIGCHLD trap handler is probably the
way forward, but I'm not sure what info is available in the handler
about the process that is done, and caused the SIGCHLD, though.

kre