Re: wait -n misses signaled subprocess

[Steven Pelley]

> OK. Can you think of a use case that would break if wait -n looked at
> terminated processes?

Yes.  If one were to start a number of bg jobs and repeatedly send the
list of pids to wait -n (probably redirecting stderr to /dev/null to
ignore messages about unknown jobs) today you'd process the jobs one
at a time, assuming no races between job completion.  If wait -n
looked at terminated processes you'd return jobs repeatedly and
possibly end up in an infinite loop.

Example:
# associate array used for consistency with later example
declare -A pids
{ sleep 1; exit 1; } &
pids[$!]=""
{ sleep 2; exit 2; } &
pids[$!]=""
{ sleep 3; exit 3; } &
pids[$!]=""

status=0
while [ $status -ne 127 ]; do
    unset finished_pid
    wait -n -p finished_pid "${!pids[@]}" 2>/dev/null
    status=$?
    if [ -n "$finished_pid" ]; then
        echo "$finished_pid: $status @${SECONDS}"
    fi;
done

gives a simple output like:
44080: 1 @1
44081: 2 @2
44083: 3 @3

With the discussed change this would return 44080: 0 in an endless loop.
It would need to change to:

while [ ${#pids[@]} -ne 0 ]; do
    unset finished_pid
    wait -n -p finished_pid "${!pids[@]}"
    status=$?
    if [ -n "$finished_pid" ]; then
        echo "$finished_pid: $status @${SECONDS}"
    fi;
    unset pids[$finished_pid]
done

Where the returned pid is unset in the array.  I like this more but it
will break scripts that run correctly today.