Re: SIGINT handling during async functions

[Chet Ramey]

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/