[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Fix foreground dead jobs in trap handlers reported like back

From: Chet Ramey
Subject: Re: [PATCH] Fix foreground dead jobs in trap handlers reported like background ones in `jobs'
Date: Mon, 3 Oct 2022 11:55:57 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.3.0

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'.


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/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]