Re: wait -n misses signaled subprocess

[Chet Ramey]

On 1/30/24 2:30 PM, Robert Elz wrote:

>    | If wait -n
>    | looked at terminated processes you'd return jobs repeatedly and
>    | possibly end up in an infinite loop.
>
> That's another bash bug, POSIX says:

It's not a bug, bash has allowed multiple waits for the same pid for
decades. bash works the way posix says it should for wait (without -n)
in posix mode.

> With wait -n, the shell should look to see if any of the process id's
> listed is currently terminated, and if so, return status of one of those
> (and remove it from the lists).   If none are terminated, it should look
> to see if any of the pids are for non-terminated jobs (or processes) and
> if so, just do a wait() until some child changes status.   If that one is
> one that is in the list being waited for, then return its status (and remove
> it from the lists) otherwise just change the status of that process in the
> lists (including remembering the exit status if that is what this was), and
> wait() again - eventually one of them should change status (that or the
> shell will be interrupted by a signal, ending the wait utility).   If none
> of the pids given in the arg list are known to the shell then it should
> return 127.

We can have these different semantics with a new option.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

OpenPGP_signature.asc
Description: OpenPGP digital signature