Re: Exit trap changes return value of subshell for uncaught trap signals

[Chet Ramey]

On 10/19/22 5:22 PM, Andrew Neff via Bug reports for the GNU Bourne Again 
SHell wrote:

> Bash Version: 5.1
> Patch Level: 12
> Release Status: release
>
> Description:
>          I discovered an inconsistent bug starting in bash 5.1.12. Setting the 
> EXIT trap in the grandparent of a subshell that exits via an unset trap signal 
> causes different return values. If the EXIT trap is unset, the subshell returns 
> 128+signal number (e.g. 138 , for SIGUSR1 (10)). However when the EXIT trap is 
> set in the grandparent, the subshell returns 0 instead.

Thanks for the report. The scenario goes something like this:

1. Setting the EXIT trap causes the shell to install a signal handlers for
   the terminating signals, including SIGUSR1, so it can clean up and run
   the EXIT trap before resending the signal to itself. So when the shell
   function is called, the signal handler for USR1 is set to this internal
   function.

2. The subshell traps USR1, and saves the old signal handler (from step 1)
   as the handler it had when it started.

3. The second subshell resets the signal handler for USR1 from the trap
   handler back to the original signal handler, which is the one from
   step 1.

4. The second subshell sends SIGUSR1 to itself with `kill', which causes
   the old signal handler from step 1 to be invoked, which sets a flag
   indicating that shell received SIGUSR1.

5. The second subshell exits, having executed its command.

The fix is to check for and handle the terminating signal before the
second subshell exits.

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