Re: wait -n misses signaled subprocess

[Robert Elz]

    Date:        Tue, 30 Jan 2024 10:14:10 -0500
    From:        Steven Pelley <stevenpelley@gmail.com>
    Message-ID:  
<CAGOYURg3g4vvegvHa8k-Vchp_21zTqq_rddTfw0F+T831GPuGA@mail.gmail.com>

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

        Once a process ID that is known in the current shell execution
        environment (see Section 2.13, on page 2522) has been successfully
        waited for, it shall be removed from the list of process IDs that
        are known in the current shell execution environment. If the process
        ID is associated with a background job, the corresponding job shall
        also be removed from the list of background jobs.

That is, if you wait for the same pid again, then all you can get is a
127 status (that pid is not known, or should not be).

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.

Do that, properly, and the loop will always terminate, whether or not
you remove each pid from the list of pending ones as its status is returned.

bash's habit of holding these things forever is weird, but certainly explains
some of Chet's concerns with list sizes and such.


Incidentally, the example code given is not a good example of the issue.
In that, if the first background sleep is allowed to finish, before the
wait -n loop starts, bash still returns its status (achieve that by making
the sleep's be for longer, except the first, then add a (fg) sleep 2 into
the script before the loop starts.   Whatever condition is required to
trigger the behaviour that is being objected to doesn't occur in that case.

kre