On 1/28/24 7:19 PM, Steven Pelley wrote:
Thank you Chet for your thorough reply.You make a few comments about differences in output (stderr for not finding a job, notifications for jobs terminating) and in all cases I believe you are correct. Let's assume job control is disabled.
OK, but remember: "When job control isn't enabled (usually in a non-interactive shell), the shell doesn't notify users about terminated background jobs, but it still removes dead jobs from the jobs list before reading the next command. It cleans the jobs table of notified jobs at other times, too, to move dead jobs out of the jobs list and keep it a manageable size." These exit statuses are still available to `wait pid' (but not `wait -n pid') as POSIX specfies.
I expect the line ending (BUG) to indicate a return code of 143.It might, if `wait -n' looked for already-notified jobs in the table of saved exit statuses, but it doesn't. Should it, even if the user has already been notified of the status of that job?When job control is disabled I get this output for the same test (just for consistent reference):
The results are consistent with what I described previously.
There's no user notification of the job terminating because job control is disabled. The "wait -n" returning 127 is the firstopportunity the shell might have to notify the user of the job.
So should the shell require the user to periodically run `wait' in a non- interactive shell without job control to clean dead jobs out of the jobs list? I don't think so.
In this context I think that "even if the user has already been notified of the status of that job" doesn't apply -- the user hasn't beennotified of the job terminating.
See above.
Even so, this behavior differs from a similar example but where the first job ends successfully, or at least without being killed by a signal. It still terminates prior to calling "wait -n" (this is from Jan 24 but I'll post again to keep everything in a linear thread). echo "TEST: EXIT 0 PRIOR TO wait -n @${SECONDS}" { sleep 1; echo "child finishing @${SECONDS}"; exit 1; } & pid=$! echo "child proc $pid @${SECONDS}" sleep 2 wait -n $pid echo "wait -n $pid return code $? @${SECONDS}" output (no job control): TEST: EXIT 0 PRIOR TO wait -n @0 child proc 2779 @0 child finishing @1 wait -n 2779 return code 1 @2 It does look in the table of saved exit statuses, returning 1.
It doesn't. In this case, the code path it follows marks the job as dead but doesn't mark it as notified (since it exited normally), so it's still in the jobs list when `wait -n' is called, and available for returning. That's probably a bug there.
I think the sticking point is the notion of the user being notified ofthe status of a job.
I think it's whether or not `wait -n pid' behaves the same as `wait pid' and looks in the list of saved exit statuses if the pid isn't found in a job in the jobs list. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature