Re: `wait -n` returns 127 when it shouldn't

[Martin D Kealey]

On Thu, 18 May 2023 at 02:13, Chet Ramey <chet.ramey@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.