On 5/4/24 8:47 PM, Koichi Murase wrote:
If we take the theory that « the notification of the signaled foreground jobs are required because it is not considered `reported' by `$?' », given that the shells don't notify the normally terminated foreground jobs, the jobs builtins are still required to print the unnotified foreground jobs. This theory is not consistent with the actual behavior in shells.
That doesn't follow. The notification isn't performed by the jobs
builtin (the shell doesn't run `jobs' internally). 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. Every shell still notifies the user that a foreground
job is terminated by a signal, whether the shell is interactive or not.
When that happens, the job can be removed from the list. The idea is
that the notification, which is useful to users, happens upon job
termination, not when the jobs builtin gets run.
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.
--
``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
