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

[Koichi Murase]

2024年5月3日(金) 23:36 Chet Ramey <chet.ramey@case.edu>:
> > To the email [2]. In particular, to the question in the second paragraph 
> > [2].
>
> OK. No, it doesn't make sense to do that.
>
> The better option is to change the notification strategy so that the jobs
> list doesn't contain terminated unnotified foreground jobs when run in a
> trap.

Thank you for your reply.

I agree with that. Actually, that should have been the intent of my
initial patch, though I don't remember how I did it exactly at that
time. Anyway, I guess you will have a better idea about how it should
be modified.

> > I think the description of the standard is still unclear, or the
> > standard doesn't try to specify this detail.
>
> Probably the latter.

I agree.

> > In that theory, what happens when `sleep 20' is successfully
> > terminated without any signals?
>
> Shells wouldn't, and don't, notify about that.

Then, after that, does `jobs' after the `sleep 20' print the
information about the foreground job `sleep 20'? That was my question.
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.

> > With this interpretation, the `jobs' builtin will never print
> > foreground jobs because, at the point when the `jobs' builtin is
> > running in the foreground, any other foreground jobs should have been
> > terminated (while setting $?) or turned into background jobs as no
> > more than one jobs can run in the foreground at the same time.
>
> Sure. In addition, I want to preserve the behavior of notifying about
> terminated foreground jobs that were killed by a signal we don't ignore.

I think it is better to preserve the behavior of notifying about
signaled foreground jobs, yet I wouldn't expect the jobs builtin's
behavior of reporting foreground jobs in funsubs to be preserved. The
standard only describes the job status report of the background jobs
in Issue 8 [XCU 2.11]. Even if the notification of the foreground jobs
is not mentioned in the standard, I think the foreground-job
notification is not forbidden.

----

I think it is simpler to update the standard wording of [XCU 3 jobs -
OPTIONS] from "all jobs whose ..." to "all background jobs whose "
instead of trying to interpret `setting $?' as a way of `job status
reporting' and letting the readers deduce the fact that the jobs
builtin will not print the foreground jobs. Draft [XCU 3 jobs -
DESCRIPTION / paragraph 1] says "the jobs utility shall display the
status of background jobs that ...", so I think the jobs builtin is
intended for printing the background jobs.

--
Koichi