[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: extdebug now implies errtrace which implies `trap ... ERR` execution

From: Chet Ramey
Subject: Re: extdebug now implies errtrace which implies `trap ... ERR` execution w/out `set -e`
Date: Wed, 10 Feb 2021 10:06:45 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.7.0

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 > +      
+       - shopt_set_debug_mode: call set_shellopts after setting 
+         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

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


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/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]