2024年4月30日(火) 5:07 Chet Ramey <chet.ra...@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.

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

> 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. If we need to report all the foreground jobs executed in a normal
way, jobs will have to remember all the foreground jobs executed in
the past since the last call of jobs, but I don't think that is a
traditional behavior of most shells. 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.

With this report, I'm not just talking about the implementation of the
`jobs' builtin for a given list of jobs. I guess this should also be
related to the timing when the entries of foreground jobs in the
internal table should be cleared (or marked as ``notified''), though I
haven't checked the actual internal processing in the current
codebase. In particular, since the foreground jobs are not reported by
« (true); b=${ jobs; } » (where only « a=${ (true) } » is changed to «
(true) » and the invocation of the `jobs' builtin is unchanged), it is
more likely to be related to the management of the foreground jobs in
the internal job table rather than the implementation of the `jobs'
builtin, I guess.

--
Koichi

Reply via email to