On 9/20/18 7:39 PM, Jeremy Townshend wrote:
> Bash Version: 4.4
> Patch Level: 19
> Release Status: release
>
> Description:
> The behaviour of the "trap" builtin command changes merely by printing
> the
> list of commands associated with each signal (trap command issued
> without
> arguments).
>
> Repeat-By:
> Case 1: In a fresh terminal emulator issue the following:
>
> ( trap 'echo trapped >&2' HUP; { sleep 10 & sleepPID=$!; wait
> $sleepPID; } > >( sleep 1; kill -HUP $BASHPID; cat ) )
>
> Case 2: Then in a fresh terminal emulator issue the following:
>
> ( trap 'echo trapped >&2' HUP; { sleep 10 & sleepPID=$!; wait
> $sleepPID; } > >( trap; sleep 1; kill -HUP $BASHPID; cat ) )
>
> Expected outcome: either the trap is triggered in both cases or in
> neither
> since the only difference is the additional trap command with no
> arguments
> (for printing the list of commands associated with each signal). That
> is, in
> this case, "trapped" is expected to be printed in both cases or in
> neither
> case.
The trap command shouldn't be executed in either case. The process
substitution is executed in a subshell environment, which doesn't inherit
traps from its parent (though it inherits the trap strings; see
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_28).
The process substitution sends the SIGHUP to itself ($BASHPID), which
should cause it to terminate but not result in a signal being sent to its
parent. However, the parent is getting a SIGHUP from somewhere.
It seems like this behavior is the result of the shell being interactive.
I'll take a look.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
