2024年5月6日(月) 23:01 Koichi Murase <myoga.mur...@gmail.com>:
> > 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?
I've checked the latest devel push. I confirmed the new behaviors that
the signaled foreground jobs are immediately notified even in the middle of
trap/bindx/PROMPT_COMMAND, and therefore the `jobs' builtin wouldn't
print the foreground jobs anymore. This would solve a long-standing
issue of my framework about the ambiguous foreground and background
jobs. Thank you.
Also, I confirmed that a=${ (true) }; b=${ jobs; } would not report
the foreground job `(true)'.
Thank you for your consideration and discussion.
--
Koichi
