Jeff King <p...@peff.net> writes: > But the ^C case is interesting. Try running your script under "sh -x" > and hitting ^C. The signal interrupts the first wait. In my script (or > yours modified to use a single wait), we then proceed immediately to the > "exit", and get output from the subshells after we've exited. > > But in your script with the loop, the first wait is interrupted, and > then the _second_ wait (in the second loop iteration) picks up all of > the exiting processes. The subsequent waits are all noops that return > immediately, because there are no processes left. > > So the right number of waits is either "1" or "2". Looping means we do > too many (which is mostly a harmless noop) or too few (in the off chance > that you have only a single job ;) ). So it works out in practice.
Well, if you time your ^C perfectly, no number of waits is right, I am afraid. You spawn N processes and while looping N times waiting for them, you can ^C out of wait before these N processes all die, no? > But I think a more clear way to do it is to simply wait in the signal > trap, to cover the case when our original wait was aborted. Sounds good.
