Historical implementation of the wait-builtin of both sh and csh relied on wait(2) (and/or friends), which only affords wait-ing for the current shell's children. However, for some time BSD's kevent(2)'s EVFILT_PROC has allowed monitoring any visible process for the NOTE_EXIT -- a feature used by pwait(1) already. I'd like the wait-builtin of our current base shells to be rewritten to make use of the feature -- providing the same functionality the traditional implementation offered (exit status), but allowing to watch a wider variety of processes. One immediate application of this will allow service-scripts (such as those inside /etc/rc.d) to properly wait for the service stop before exiting or starting it again. I'd be happy to offer the necessary patches, but wish to secure the acquiescence in principle first.
Or, maybe, the wait()-function found in libc should be rewritten to use kqueue() instead of the wait() system call? That would expand the functionality of all traditional wait-users at once...
Thank you very much, Jan, for your work and patience.
Argh, my comment #2 was meant for an entirely different bug...
As noted by the pwait(1) man page, pwait is not a replacement for the wait builtin, since it can wait for a process to terminate and show the exit status but cannot clean up zombies or state on the parent process. Therefore, I don't think the wait builtin should be changed -- if a script wants to wait for an unrelated process, it can use pwait. rc.subr already uses pwait when waiting for a service to stop. This does not work optimally because pwait waits for a process to terminate, while rc.subr wants to wait for the zombie to be reaped by the parent such as init (by waiting until kill -0 PID fails).
I don't think the wait builtin should be changed due to its dual role of waiting and reporting exit status on one hand and cleaning up associated status on the other hand.
(In reply to Jilles Tjoelker from comment #5) > role of waiting and reporting exit status on one hand and cleaning up associated status I still think, sh's wait can play both roles for all processes and only the latter -- the cleaning up -- role for the sh's children. Without breaking any existing scripts...
POSIX is clear that wait should report status 127 when a process ID is not a child of the current shell environment, and I expect that there are scripts which rely on that. Apart from that, using the same command with the same syntax to do something quite different seems confusing.