Thank you. 2024年5月6日(月) 22:16 Chet Ramey <chet.ra...@case.edu>: > 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).
Yes, of course. But in this thread, I have been talking about `sleep 20; jobs' [1] where the user explicitly calls the `jobs' builtin. [1] Second last paragraph in https://lists.gnu.org/archive/html/bug-bash/2024-05/msg00000.html "The jobs builtin" in my previous reply corresponds to `jobs' called after `sleep 20' in `sleep 20; jobs'. It's not something internally called somewhere. > 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"? 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? Hmm, maybe you mean that a shell is free to anytime remove the terminated foreground jobs from the list regardless of whether it has been reported or not, and "all jobs whose ... reported" do not count the foreground jobs that the shell has removed from the list regardless of reporting. Is this your interpretation? > 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? If it is the only thing I can do, does that mean the jobs builtin continues to print the foreground jobs with funsubs/traps/etc? Is it impossible to differentiate the foreground jobs from the background ones in the output of the jobs builtin? -- Koichi
