> 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.
