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

[Philippe Cerfon]

Hey Chet and Greg.

On Tue, Dec 13, 2022 at 2:07 PM Greg Wooledge <greg@wooledge.org> wrote:
> This is false.

See below.



> Do you have an example that reproduces your claim?  With or without an INT
> trap?  Is ssh still involved?  Does the problem reproduce if ssh is
> removed from the picture?

The following shell script is more or less what I do...
----------------
#HUP shall not cause the service to be stopped
trap -- 'echo HUP; trap -- - EXIT; exit 0' HUP;

#but INT shall
trap -- 'echo INT; exit 0' INT;
trap -- "echo EXIT; systemctl --user stop my.service; exit 0" EXIT;

#start some demo service (sleep here)
systemd-run --quiet -G -u my.service --user --service-type=exec sleep 10000;

#keep the ssh open (e.g. port forwardings)
while true; do
        #can't use wait here, as the process ain't a child of the shell

        #check whether the service was closed by some other means than INT
        #and also cleans up the remote side bash -c with the command, when
        #a HUP had happened (but leaves the service running)
        systemctl --user is-active my.service  ||  exit 0;

        sleep 5;
done
----------------

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?


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.

Maybe ssh sends the INT to any child processes? Which is why sleep
dies at th point and then bash would process the INT.

But something similar must then happen when I locally Ctrl-C, as that
also immediately quits.

Thanks,
Philippe.