[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SIGINT handling during async functions
From: |
Chet Ramey |
Subject: |
Re: SIGINT handling during async functions |
Date: |
Mon, 23 Jan 2023 16:35:07 -0500 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 |
On 1/21/23 7:55 AM, Tycho Kirchner wrote:
Am 16.01.23 um 18:26 schrieb Chet Ramey:
The fix is to add enough state machinery to detect this situation and
behave in a way that can satisfy both the standard and the later
interpretation, while being careful not to undo this work later. This is
obviously not how bash worked in the past.
Thanks for the explanation. While editing the state machinery I would like
to suggest to add a new shopt, let's call it keepsigint, which a user may
set to preserve the SIGINT trap set in the parent shell for all
asynchronous commands.
Is this really what you want, since none of the scenarious you describe use
it?
I suggest that what you are asking for is a way to set the signal
disposition to SIG_DFL instead of SIG_IGN.
While the POSIX behavior to ignore SIGINT for background processes if job
control is disabled makes totally sense for interactive shells, for scripts
to me it often appears not constructive.
How often do you have job control disabled in interactive shells? It seems
to me that scripts are the primary motivaation for this behavior.
Please consider a script launching
several commands in background and waiting for their completion:
cmd1 &
cmd2 &
wait
If the user having launched this script from the interactive terminal
aborts it by hitting Ctrl+C, by default, the shell sends SIGINT to the
process group (pgid) of the script. However, while cmd1 and cmd2 get their
signal, they usually (if they don't override it) ignore it due to above
POSIX requirement. In my experience, what the user usually wants in such a
case is to abort cmd1, cmd2 as well as the script having launched them.
Odd, my experience is the opposite. I have run commands asynchronously from
scripts quite often in my previous lives, with the intent of insulating
them from signals.
It's pretty clear that the historical bash behavior, which ends up the way
you want, is not correct.
Anyway, if your goal is to allow CMD to have SIG_DFL for SIGINT and
SIGQUIT, the POSIX way to do it is similar to your fourth option.
{ trap - SIGINT ; exec cmd1; } &
{ trap - SIGINT ; exec cmd2; } &
which interp 751 says has to work (you can pick and choose your use of
`exec' depending on what you're running, of course).
It obviously doesn't work in bash-5.2, but bash-5.2 doesn't have that new
option, either, and already makes such asynchronous commands interruptible.
As to `sanity': I would argue that expecting any behavior other than to
have asynchronous commands with SIGINT and SIGQUIT set to SIG_IGN is not a
reasonable expectation. The Bourne family of shells has always behaved
that way. Now, you might have to work around it, but the workaround should
be possible, not the default.
--
``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/