On 5/6/24 10:01 AM, Koichi Murase wrote:
Since no one notifies about foreground jobs that aren't terminated by signals, we can omit them from the discussion -- they are removed from the jobs list as soon as they terminate.I think this is my issue of interpreting the standard, but isn't the `jobs' utility required by the standard to print "all jobs whose status has changed and have not been reported by the shell"?
That's the key phrase, isn't it?
If I literally read it with the theory "$? isn't counted as `reporting'", in the case `sleep 20; jobs' (where `sleep 20' is not terminated by signals), the job `sleep 20' isn't notified at its termination, so the subsequent `jobs' builtin is supposed to print the job "whose status has not been reported". Am I missing something?
If you like, you can interpret it to mean that $? is sufficient for reporting normal terminations, the notification applies to abonormal terminations of interest (which also sets $?), and both can remove jobs from the jobs list. Either way, the notifications have to happen, and they should remove the jobs from the list so jobs doesn't report on them.
The whole issue here is that in some circumstances bash defers that notification too long, and doesn't do it before the user can run `jobs'. You don't need to change `jobs' so it doesn't print foreground jobs that were terminated by a signal, you need to figure out why those jobs are still in the list when `jobs' runs.After figuring out, what should I do?
It's a colloquialism. I have to figure it out, and I believe I have.
--
``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
