Date: Tue, 30 Jan 2024 10:14:10 -0500 From: Steven Pelley <stevenpel...@gmail.com> Message-ID: <cagoyurg3g4vvegvha8k-vchp_21ztqq_rddtfw0f+t831gp...@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