Re: SIGINT handling during async functions

[Chet Ramey]

On 1/28/23 5:56 AM, Martin D Kealey wrote:
> Firstly, let's just leave aside "POSIX requires this" for a bit. I know 
> that the requirement is there, and I think it is one of those broken things 
> that ought to have been dropped from POSIX, or at least reduced to optional 
> rather than required.

Be that as it may, POSIX exists and this is a requirement. It's also how
other shells behave.


>     On 1/21/23 7:55 AM, Tycho Kirchner wrote:
>      > Please consider a script launching several commands in background
>      > and waiting for their completion:
>
>
> (note these last 4 words; I suspect they exclude the "common case 
> experience" of people who think that it's only natural to want to insulate 
> new daemons from tty signals)

Sure.

> I contend that it's inconsistent for the actions of "nohup" and "&" to NOT 
> be fully orthogonal.

Maybe, but their historical behavior has always differed: `nohup' ignores
SIGHUP, and background processes ignore SIGINT/SIGQUIT. You could say those
are "fully orthogonal," setting aside the sometimes-confusing manipulation
of input and output FDs. Is the latter what you mean by orthogonality?

> And I contend that a daemon that unexpectedly dies is much more obvious 
> than a bunch of internal processes that are unexpectedly left running; you 
> have to proactively check for orphaned processes, and their continued 
> action may cause weird bugs.

You can get background processes that have SIGINT and SIGQUIT set to
SIG_DFL today with the (buggy) existing bash behavior. The same POSIX-
blessed technique will work in fixed future versions:

{ trap - SIGINT SIGQUIT ; program; } &      # `exec program' if you prefer

instead of

program &

and this has the advantage -- or not -- of granularity.

> I haven't encountered an interactive shell in a tty without job control in 
> the last 35 years. (*1)
> I contend that it's past time this POSIX misfeature was retired.

You absolutely can have that discussion with the POSIX group; since job
control remains an optional POSIX feature, you might want to incorporate a
proposal to make it mandatory.

> In the meantime, « shopt -s background_without_magic » (*2) gets my vote, 

I don't see any advantage over the mechanism above.

> along with incorporating « nohup » as a built-in (so that Bash can 
> guarantee its behaviour, and add options to improve its internal 
> orthogonality.).

What guarantees would you like? Or, what do you consider the essential
parts of nohup's behavior that should be guaranteed that are not now?
nohup's been around for what, 40+ years now; its behavior is pretty
well known. There's little advantage to making it a builtin other than
to nohup builtins, and you basically can do that already.


> *1: I have very occasionally had interactive single-user shell running on 
> /dev/console, which doesn't appear to count as a tty because it doesn't 
> respond to tcsetpgrp.

Try running something in a Docker container; that doesn't guarantee a
controlling terminal.

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