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

[Chet Ramey]

On 12/13/22 2:58 PM, Philippe Cerfon wrote:

> I tried it both, directly without ssh, i.e.
> $ bash script.sh
> then with either of:
> $ kill -INT
> $ kill -HUP
> 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?

These are not the same thing. Ctrl-C, like other keyboard-generated
signals handled by the terminal driver, sends SIGINT to all processes whose
process group is the same as the terminal's process group. In the case of
the non-interactive shell, since you have not enabled job control, that's
the shell and the processes it runs.


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

This implies that telling ssh to allocate a terminal at the remote end
means the terminal driver gets in the mix to interpret ^C there, and that
ssh converts the SIGINT you send on the local end to the equivalent of a
keyboard-generated ^C at the remote end.

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

This mimics the historical behavior of SIGHUP generation when, say, a modem
line drops (the original `hangup' in HUP). ssh knows the PID of the process
it forks to run RemoteCommand and sends SIGHUP to it.

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