Re: surprising condition value in TRAP in 5.1

[Chet Ramey]

On 8/3/22 2:53 PM, Robert E. Griffith wrote:
> This DEBUG trap in a 5.0 Bash cmdline and again in a 5.1 Bash cmdline 
> produces different results (line 3b is the difference)
>
>     (1a) 5.0.17$ trap 'if ([[ "$BASH_COMMAND" =~ BOB  ]]); then echo "oh, 
> no, not BOB"; fi; true' DEBUG
>     (2a) 5.0.17$ echo hi
>     (3a) hi
>     (4a) 5.0.17$ echo BOB
>     (5a) oh, no, not BOB
>     (6a) BOB
>     (7a) 5.0.17$
>
>
>     (1b) 5.1.16$ trap 'if ([[ "$BASH_COMMAND" =~ BOB  ]]); then echo "oh, 
> no, not BOB"; fi; true' DEBUG
>     (2b) 5.1.16$ echo hi
>     *(3b) oh, no, not BOB***(4b) hi
>     (5b) 5.1.16$ echo BOB
>     (6b) oh, no, not BOB
>     (7b) BOB
>     (8b) 5.1.16$
>
> Under 5.1, only when the condition is inside the (), it returns true even 
> though the [[]] cmd is false.
>
> Is this known behavior?

Yes.

If you had run this code with xtrace enabled, you would have seen the
difference.

BASH_COMMAND is set from the command that's about to be run, unless the
shell is running a trap, in which case it remains unchanged.

Subshells forget that they are running a trap, since the traps and signal 
dispositions are all reset when the subshell is created. (If they didn't,
bash would prevent subshells from trapping and running traps on that
signal.)

So, putting this together, the subshell does not `know' it's running a
DEBUG trap, the value of BASH_COMMAND is `[[ "$BASH_COMMAND" =~ BOB  ]]',
and matching that against `BOB' succeeds.

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