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

[Koichi Murase]

2024年5月1日(水) 22:58 Chet Ramey <chet.ramey@case.edu>:
> Yes, and I said I could work around this case.

Thank you for your consideration.

> > [1] https://lists.gnu.org/archive/html/bug-bash/2022-10/threads.html#00054
> > [2] https://lists.gnu.org/archive/html/bug-bash/2022-11/threads.html#00049
> > (continued. I haven't received a reply)
>
> To what?

To the email [2]. In particular, to the question in the second paragraph [2].

> > I'm not sure about the answer, but kre's opinion seems reasonable to
> > me.
>
> OK. The standard does say "reporting the exit status with the special
> parameter '?'" in
>
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_08_02

I think the description of the standard is still unclear, or the
standard doesn't try to specify this detail. I'm not sure whether we
can relate "the exit status reported by $?" and "the job status that
has been reported'' just from the description of the standard.
However, when we try to define "the job status that has been reported"
consistently with both the standard description and the actual
behaviors of shells, I think it is *one* reasonable interpretation to
regard the job status is reported when the exit status is stored in
$?.

> Correct. Is setting $? sufficient, or does the standard mean the reporting
> on foreground jobs that are killed by a signal -- one that shells don't
> ignore -- before the next command, which is what all shells do?
>
> For instance, if you run
>
> sleep 20; jobs

As far as I test it, yash and zsh don't print the information of the
signaled foreground jobs in this case, though ash/ksh families and
bash/posh print it as you tell. If we interpret $? can be used to
``report'' the foreground job status, the standard technically
wouldn't require printing the job information to stdout in this case,
but it doesn't prohibit printing either.

> and hit the `sleep' with SIGUSR1 from another process, all shells will
> print some message about the process exiting due to SIGUSR1 before `jobs'
> is executed, and `jobs' prints nothing, because the reporting has already
> happened.

In that theory, what happens when `sleep 20' is successfully
terminated without any signals? If the `reporting' must be the actual
text printed to stdout, « sleep 20; jobs » should print the job
information of the foreground terminated job `sleep 20', but not a
single does that.

----

To summarize my current thinking, I feel the standard didn't intend to
specify the detailed behavior for the foreground jobs. I don't expect
the `jobs' builtin to print any foreground jobs for consistency with
the behavior in the existing shells (except for Bash
trap/bindx/PROMPT_COMMAND handlers and 5.3 funsubs). An
``interpretation'' of the POSIX standard consistent with the existing
shell behavior would be to count $? as `reporting'.

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. In a
case, the `jobs' builtin is inside a background job, the foreground
jobs that started after forking the background jobs are not visible to
the `jobs' builtin anyway.

--
Koichi