Chet Ramey wrote, on 06 May 2022: > > > > And last, also in this area, is the question of stopped jobs and the wait > > > command, and how those two are intended to interact. > > > > The wording in my current draft makes clear that wait waits for > > processes to terminate. I could, if desired, add some rationale saying > > that some implementations have, as an extension, an option that allows > > wait to return when a process stops. > > That's not the current behavior. At best, it should be unspecified.
It is already what the standard requires, and with good reason. I have never, ever, seen a shell script use "wait" in a way that would work correctly if the wait returned when the process stopped. The code invariably assumes that wait will not return until the process terminates. If it checks $? after the wait, it is always just to distinguish between different exit status values. Even if an application did want to check for the process stopping, that is not possible (portably) since an exit status of (128+SIGSTOP) can't be distinguished from a call to exit() with the same value. Using "kill" or "ps" to check if the process still exists isn't reliable, as another process could have been given the same pid. In shells where wait (with no options specified) returns when a process stops, that is a horrible misfeature. Kre has already stated he will change NetBSD sh so that it doesn't do that. Hopefully the other ash-bashed shells will follow suit. If you only change bash in POSIX mode, you will be doing your users a disservice. -- Geoff Clare <[email protected]> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
