Re: why are pipeline commands (allowed to be) executed in subshells?

[Greg Wooledge]

On Tue, Dec 13, 2022 at 08:58:25PM +0100, Philippe Cerfon wrote:
> it is as you say, and the shell waits indeed the up to 5 seconds until
> the handler for INT respectively HUP is processed.
> 
> But when I do Ctrl-C, both close immediately. So I guess I just don't
> get what happens when I press Ctrl-C?

When you press Ctrl-C (or whatever key stty intr is bound to) in
a terminal, the terminal driver sends SIGINT to *all* PIDs in the
terminal's foreground process group.

Bash isn't propagating signals, or doing any other magic.  The terminal
driver is the only magician here.

In the case where you're running "bash myscript" in a terminal,
and myscript is currently waiting on a foreground sleep command, the
following three processes receive a SIGINT:

1) Your interactive bash shell.
2) The instance of bash that's running myscript.
3) The sleep process.

The interactive shell ignores SIGINT, because that's what interactive
shells do.  The other two processes receive the SIGINT and act upon
it based on how they've set up their signal handling.

sleep(1) doesn't do any special signal handling, so SIGINT is fatal to
it.  The sleep process dies very quickly.

The instance of bash that's running your script has set up a signal
handler for SIGINT, but it's waiting for a child process, so it doesn't
process the signal immediately.  It waits until the sleep command
terminates.  This doesn't take long.  You probably can't even notice it.

Once the sleep terminates (due to the fatal signal), bash (the one
running the script) resumes control, and receives the SIGINT.  Since
it has a trap in place for SIGINT, that trap is executed.

> Similar via SSH, you can make the above script into one line and set
> it as RemoteCommand="..." and also need to set RequestTTY=force .
> When I Ctrl-C, it always stops immediately (the sleep process sees a
> INT and the bash process, too).
> When I send INT to the local ssh client, the same.
> When I hang up the connection via ssh's escape sequence ~. on a
> newline (per default) then ssh seems to send the HUP to bash (only)
> and it waits for the loop's sleep to finish until it processes that.

I don't feel qualified to debug the behavior with ssh added to the
mix.  If you have questions about how ssh behaves when the local/remote
end receives a signal, I recommend asking the openssh mailing list(s).
Or perhaps someone else who's reading here may know.

You've already observed that the behavior changes depending on whether
you've forced ssh to allocate a pseudoterminal.  That's a pretty strong
hint about the direction you should search for answers.