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

[Chet Ramey]

On 2/10/21 2:10 AM, Mike Frysinger wrote:
> On 09 Feb 2021 16:40, Chet Ramey wrote:
> > On 2/9/21 11:51 AM, Mike Frysinger wrote:

> > > 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.

It's your characterization of the change as "random." Clearly, it was not.

> 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.

It would probably have made things easier for you now, but that's not the
point of the comapt settings. Those exist as a bridge so people can fix
code, and they exist as a function of how many people use the code in
question. One report in five years doesn't rise to that level.

And you should start using BASH_COMPAT. You'll thank yourself in ten years.

> > > 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.

Sure. Waiting five years to do it guarantees that nothing will get fixed
or changed once you do. Most reports will generate a "that was fixed in
[next release]" response.

> > > > > 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. 

Bisecting git is pretty fast. My point is that once you find the right 
commit, you have to look at the change log (as you did) to find out what
happened and that there are other sources of information to tell you
whether or not an individual change is intentional.

 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 has discrete sets of changes, just more than one change. They're works
in development.

> > > 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.

My point is that those features exist for the debugger's use, and exposing 
them outside the debugger has to come with a benefit that outweighs their
cost.

For instance, very few people outside the debugger use BASH_ARGV and
BASH_ARGC. Yet setting them up had a noticable performance cost when
invoking a script with lots of arguments, for example

https://lists.gnu.org/archive/html/bug-bash/2018-02/msg00024.html

which happens a lot more often than using BASH_ARGV, so bash-5.0 sets
up BASH_ARGV and BASH_ARGC at startup only when in debugging mode. (There
is some lazy evaluation there so that they will get set up the first
time you enable debugging mode, but you still have to have debugging mode
set to update them for functions or sourced files).

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