Re: extdebug now implies errtrace which implies `trap ... ERR` execution w/out `set -e`

[Mike Frysinger]

On 09 Feb 2021 11:12, Chet Ramey wrote:
> On 2/8/21 11:54 PM, Mike Frysinger wrote:
> > this set of changes between bash-4.3 & bash-4.4:
> > https://git.savannah.gnu.org/cgit/bash.git/commit/?h=814e1ff513ceca5d535b92f6c8dd9af7554fe83e
> 
> I'm glad you're upgrading to bash-4.4. This change was made nearly five
> years ago; the time to relitigate it has long passed.

we're on bash-4.3 atm.  we would upgrade to the latest if that were actually
a reliable process.  unfortunately, moving between bash versions is often full
of random regressions or changes in behavior.  like this one.

i understand your point, but the real world of shipping code doesn't have the
luxury of burning the house down for the latest shiny features.

> > has this buried nugget:
> > +   - shopt_set_debug_mode: make sure error_trace_mode reflects the setting
> > +     of extdebug.  This one is tentative.  Fix from Grisha Levit > +       
> >   <grishalevit@gmail.com>
> > +   - shopt_set_debug_mode: call set_shellopts after setting 
> > error_trace_mode
> > +     or function_trace_mode.  Fix from Grisha Levit <grishalevit@gmail.com>
> 
> You can take that and find the original bug report, with Grisha's patch:
> 
> https://lists.gnu.org/archive/html/bug-bash/2016-05/msg00000.html
> 
> Since the bash-4.3 man page said that setting `extdebug' means that error
> tracing is enabled, and implies the opposite is true, it makes sense to
> ensure that the `errtrace' value reflects the value of `extdebug' when it's
> changed.

thanks, i wanted to double check it was intentional.

it looks like we can mitigate this with `set -E` after we turn on extdebug.
it's unfortunate that there's no way to get extended debug info without also
opting in to side-effects like this.  all we really want is to get backtrace
info for logging messages when we abort down a few layers.
-mike