help-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Philippe Cerfon
Subject: Re: why are pipeline commands (allowed to be) executed in subshells?
Date: Tue, 13 Dec 2022 02:29:01 +0100

On Sat, Nov 26, 2022 at 6:48 PM Chet Ramey <chet.ramey@case.edu> wrote:
> It's necessary for job control.

Thanks!


I have a similar issue where I don't understand why things are
(allowed to be) as they are:

POSIX says:
When a signal for which a trap has been set is received while the
shell is waiting for the completion of a utility executing a
foreground command, the trap associated with that signal shall not be
executed until after the foreground command has completed.

So when I have e.g.
while true; do
    sleep 60
    check_for_condition && break
done

as well as a trap on e.g. HUP and INT that set some condition to be true,
and then send a HUP to the executing shell, I'd expect that it
waits(!) for the sleep to finish until it breaks out of the loop. And
indeed it does. The HUP signal is only received by the shell, the
child processes don't seem to get it.


However, when sending an INT, the child immediately seems to see the INT.

Why is this happening and not a violation of the above rule?

Is it, that the above only forbids to execute it's own handler for the
signal while the child process is still running, but still allows the
shell to send the INT to it's children (and it just doesn't do so for
HUP) ... when it sends the INT to the child, that quits and then
"immediately" the handler runs?


Thanks,
Philippe.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]