Re: 5.3-alpha: the `jobs' builtin prints foreground dead jobs with function substitutions

[Koichi Murase]

Thank you.

2024年5月6日(月) 22:16 Chet Ramey <chet.ramey@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