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

[Chet Ramey]

On 4/30/24 3:59 AM, Koichi Murase wrote:
> 2024年4月30日(火) 5:07 Chet Ramey <chet.ramey@case.edu>:
> > OK, let's explore this again.
>
> I haven't yet been convinced by the previous discussion [1,2] about
> the reporting of the foreground dead jobs in the trap handler, but
> this time, the situation is slightly different. The `jobs' builtin
> reports the foreground dead jobs even in a normal context of the
> commands executed through the command line when the new function
> substitutions are used.

Yes, and I said I could work around this case.

> [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?

> > POSIX says `jobs' should report on
> >
> > "the status [...] not been reported by the shell"
> >
> > So the question is what exactly constitutes a foreground job whose status
> > has "not been reported."
>
> 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


> POSIX Draft (202x/D4.1) XCU 2.11
> mentions the reporting of the ``background'' jobs ``immediately prior
> to writing the next prompt'', but the reporting of the foreground jobs
> does not seem to be described.

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

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.

So it's not exactly the jobs builtin, nor precisely jobs list management.
It's more about which terminated foreground processes get a message
displayed -- all of them set $? -- and which ones are silent, and whether
that counts as `reporting'.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/