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

[Mike Frysinger]

On 09 Feb 2021 16:40, Chet Ramey wrote:
> On 2/9/21 11:51 AM, Mike Frysinger wrote:
> > 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.
> 
> Interesting. I suppose one person's bug fix is another's "random change." I
> don't see it in this case, though, since it's a bug fix and making bash do
> what its documentation said it did.

i'm not complaining that the change was made; in fact, my original report
never asked for it to change, or declared it a bug, but was clearly asking
for confirmation that it was an intended behavioral change.

seems like it should have been included under the compat43 knob since it
was changing long standing behavior (bug or otherwise), but it's prob too
late for that now too.

> > 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.
> 
> I understand that distribution stability means that you'd like to encase
> the shell in amber.

i made no such claim or request.  my point is upgrading bash versions
is guaranteed to break something, intentional or not.  i've maintained
bash in distros & products since bash-2.05b, so i understand this is
simply the reality of the project.

jumping more than one release (i.e. to bash-5.1) introduces much more
risk than reward which is why we're only moving to bash-4.4 now, and
once that settles, we can look at the next major step.

> >>> 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 could also have looked in the CHANGES file:
> 
> oooo. Fixed a bug that caused the shell to not enable and disable function
>        tracing with changes to the `extdebug' shell option.

bisecting git is a lot faster than digging through changelog files that
are inconsistent across projects and trying to figure out what might or
might not be relevant.  i wish bash's vcs history had more discrete sets
of changes rather than daily code dumps.  but it's still an improvement
over not having access to any vcs.

> > 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.
> 
> If it works for you, great. But extdebug is always going to be for the
> benefit of the shell debugger.

i didn't ask you to change extdebug behavior.  i'm asking for subsets of
the current extdebug functionality to be exposed without all the other
side-effects.  e.g. having bash populate the BASH_ARGC & BASH_ARGV env
vars for self-introspection.
-mike