Re: surprising condition value in TRAP in 5.1

[Robert E. Griffith]

OK, that makes sense. So was that actually a bug in 5.0 (that my code 
worked) that was fixed in 5.1?  Do you know what changed. I am testing 
my script project in 5.1 and find that my debugger and exception 
mechanisms, two things that use traps heavily, are not working and I am 
chasing things down.

--BobG

On 8/4/22 10:39, Chet Ramey wrote:
> 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.