On Thu, 18 May 2023 at 02:13, Chet Ramey <chet.ra...@case.edu> wrote:
> It's possible for the shell to reap both background jobs before `wait -n' > is called. The underlying function returns < 0 when there aren't any > unwaited-for jobs, which the wait builtin translates to 127. > I know that some platforms (used to?) lack all of the “waitpid()”, “wait3()”, “wait4()”, and “waitid()” syscalls. On those you need to use “wait()” repeatedly until you get the PID the script asked for, and keep track of the others until the script asks for them too. At least, this is what Perl and MSys did when running on older Windows. However Linux has all 5 reaping syscalls available, and can provide the exit status to a signal handler (in the siginfo parameter) without calling any of them, and therefore without *actually* reaping the process. If there is silent reaping going on (other than “wait -n” or “trap ... SIGCHLD”) shouldn't the exit status and pid of each silently reaped process be retained in a queue that “wait -n“ can extract from, in order to maintain the reasonable expected semantics? Arguably this queue should be shared with “fg” when job control is enabled. Would you care to speculate more precisely on where such silent reaping may occur, given the code as shown? -Martin PS: I'm not convinced that “trap ... SIGCHLD” needs to be in that list; it's the “wait” inside the trap that actually matters, and if you *don't* “wait” inside a SIGCHLD trap, things are going to get quite strange anyway.
