Date: Sat, 23 Mar 2019 11:48:33 -0400 From: Chet Ramey <chet.ra...@case.edu> Message-ID: <36545673-c287-6d8a-5e99-004ce9c6b...@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