Re: [PATCH] Fix foreground dead jobs in trap handlers reported like background ones in `jobs'

[Chet Ramey]

On 10/2/22 11:04 PM, Koichi Murase wrote:
> 2022年10月1日(土) 4:30 Chet Ramey <chet.ramey@case.edu>:
> > On 7/17/22 11:52 PM, Koichi Murase wrote:

> > the change to print_job appears not to be needed (at least
> > all of your test cases work without it).
>
> Maybe it has been fixed in another way, but how about the following
> test cases?  Let us consider the following two functions:
>
>    $ f1() { echo begin;for a in {0..3}; do (kill -9 $BASHPID); done;echo end; }
>    $ f2() { echo begin;for a in {0..3}; do (kill -9 $BASHPID);
> done;jobs;echo end; }
>
> The difference between the two functions is that `f2` calls `jobs'.

Exactly.

> I expect the same behavior of `f1' and `f2' as far as there are no
> background jobs. 

Why? f2 calls `jobs', and so requests information in a particular format,
which may or may not be the same format as the default (compact) format
bash uses when it reports job status before printing a prompt.

Here's how it works. When the shell is interactive, you get notified about
dead jobs in two places: before the shell prints a new prompt, and after
the shell waits for a foreground process to exit and discovers that a
job has completed. You'd think the first would be enough, but it leaves you
vulnerable to job table explosion when you're running a bunch of jobs in a
loop. The pragmatic solution of notifying when the job completes works well
enough to avoid this. Bash has done this for decades.

This default compact format prints a message that strsignal() returns,
since it assumes you can easily associate it with the just-completed job.

So you can see what happens. When run in the foreground, f1 prints the
status from strsignal() after waiting for each process to finish. When
run as a trap handler, f1 defers printing until it's about to print a
prompt, then prints the status from strsignal(). When run in the
foreground, f2 prints the status after waiting for each process to finish
(which means that when you run `jobs' there are no un-notified processes).
When run as a trap handler, f2 tries to defer printing the status until
the trap handler completes, but the function forces status printing with
`jobs' in a specific format, which means there are no un-notified jobs
when the time comes to print the next prompt.

I think this is reasonable behavior.

--
``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/