Re: trap - inconsistent behaviour

[Chet Ramey]

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    chet@case.edu    http://tiswww.cwru.edu/~chet/