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

[Chet Ramey]

On 12/20/22 1:41 AM, Philippe Cerfon wrote:

> So I tried to make it behave like an interactive shell, where ^C
> wouldn't kill the sleep 100 in the background, which I did by adding
> set -m in the command:
> $ ssh -t -t example.org "set -m; trap 'echo HUP>> /tmp/csingal; exit'
> HUP; trap 'echo INT>> /tmp/csingal; exit' INT; trap 'echo QUIT>>
> /tmp/csingal; exit' QUIT; sleep 100 &  while true; do sleep 60; done"
>
> # ps -e --forest -o pid  -o ppid   -o pgid -o tpgid -o args
>      PID    PPID    PGID   TPGID COMMAND
>   388461  388455  388461  388463      \_ bash -c set -m; trap 'echo
> HUP>> /tmp/csingal; exit' HUP; trap 'echo INT>> /tmp/csingal; exit'
> INT; trap 'echo QUIT>> /tmp/csingal; exit' QUIT; sleep
>   388462  388461  388462  388463          \_ sleep 100
>   388463  388461  388463  388463          \_ sleep 60
> looks good, the sleep 100's PGID differs from the TPGID
>
> ^C lets the sleep 60 receive a INT, expected. The sleep 100 sees
> nothing (expected) but gets a PPID of 1 and a TPGID of -1 and
> continues to run (also expected). Bash gets a SIGCHILD, also expected,
> but then exits, which I don't understand. Shouldn't it just start the
> next seep 60?

When the shell is running a loop and a child process dies due to SIGINT,
the shell pretends it got the SIGINT to break the loop. This reduces user
surprise and frustration.

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