Re: SIGINT handling during async functions

[Martin D Kealey]

On Fri, 3 Feb 2023 at 07:17, Chet Ramey <chet.ramey@case.edu> wrote:

> On 1/28/23 5:56 AM, Martin D Kealey wrote:
> > Firstly, let's just leave aside "POSIX requires this" for a bit.
> Be that as it may, POSIX exists and this is a requirement. It's also how
> other shells behave.
>

Of course. I'm only contemplating making changes in extended mode, not
POSIX mode.


> > 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?
>

Sorry, nohup was a terrible way to illustrate this, since conflates other
things that I wasn't considering; rather I meant something more along the
lines of "some hypothetical command structured like nohup but which affects
SIGINT & SIGQUIT instead of SIGHUP, and which doesn't redirect stdio" (and
which doesn't make the job automatically backgrounded, though that already
applies to nohup).

By orthogonal, I meant these things should ideally be managed by separate
controls:
 1. ignoring signals (or not)
 2. redirecting filedescriptors
 3. immediately waiting on the process (or not)
 4. creating new process groups
 5. sending a signal to about-to-be orphaned children when the shell exits

The problem, as I see it, is that there's no shell syntax that *only* does
#3.

Yes one could write a shell function, but it'd be pretty contorted, and
waste a lot of effort for things that would be undone when using other
features at the same time, leading to a situation where people would only
bother to use it when they're *not *going to give explicit signal
dispositions; so it's still not *practically* orthogonal.

> In the meantime, « shopt -s background_without_magic » (*2) gets my vote,
>
> I don't see any advantage over the mechanism above.
>

The value proposition in making changes isn't that "this can't already be
done *somehow*", but rather the unorthogonality of the current features is
suboptimal language design, and poor for user understanding.

Rather than a global shopt setting that stops "&" from blocking SIGINT &
SIGQUIT, which I'll grant is a hard sell, perhaps an entirely new notation
would be possible, using some combination of "&" with other punctuation
that isn't already defined, such as "&;" or "&|".

> 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?


I put those the wrong way round. To add extensions, and guarantee that
they're available to every Bash script, nohup would have to be a built-in.

In particular I'm thinking of options along the lines of:

nohup --no-redir --[block/default/keep]=[INT,QUIT,HUP,...]

(exact names not important; hopefully --long-options are self-explanatory)

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

That's a very good point, and I suspect it's for the same underlying
reason: that inside the container, the "top" process has pid 1 or pgrp 0 or
somesuch, and somewhere this is interpreted as "set the terminal so that it
has no pgrp".

-Martin