Date: Sun, 28 Jan 2024 18:21:42 -0500 From: Chet Ramey <chet.ra...@case.edu> Message-ID: <3347f790-529b-4bee-91fd-de39bed3f...@case.edu>
| because `wait -n' doesn't look in the table | of saved statuses -- its job is to wait for `new' jobs to terminate, not | ones that have already been removed from the table. That's very interesting, and most unexpected information. I always wondered why the option was 'n' - I would have made it be 'a' probably, as a shorthand for "any" - but then I decided that perhaps 'n' was a better choice, as "a" could also be "all", the option name would not be providing any real clue at all, so I assumed you'd been ultra clever and used 'n' as the next char in "any" and also as it can be read like the first part of "en" "ee" (which you need to say out loud, or at least in your head, to get the effect of). It never even dawned on me that 'n' might mean "new", as in only processes that hadn't terminated at the time the wait -n was done, as that's essentially a recipe for script madness, race conditions galore, as the one reported here. What wait(1) needed was an alternative to its normal "all" semantic, just "wait" waits for every background job to terminate, what's needed is a way to wait for any one of them (whether already terminated, but not previously waited for or not). That's what I always assumed wait -n was doing, and how I implemented it in the NetBSD shell. Similarly "wait pid1 pid2 pid3" waits for all 3 of those to terminate, so "wait -n pid1 pid2 pid3" should wait for any one of them - already terminated or not. When there's just one pid in the list, the -n option always seemed useless to me, there ought be no difference between "wait pid" and "wait -n pid" (as in wait for all of one, and wait for any of one, mean the same thing, wait for that one), but obviously should still be supported for consistency. To think that it might be interpreted as "wait for a new process "pid" to terminate, ignoring the one that just finished a few milliseconds ago" is simply astounding, completely unbelievable. And from what I have seen of the other comments, several from long term & dedicated bash users, it is just as astounding to them as well. Please treat this as a bug, and fix it. Quickly. kre