Re: export loses error
On 2/8/21 5:29 PM, gregrwm wrote: $ export vim=$HOME/.GVim-v8.2.2451.glibc2.15-x86_64.AppImage $ $ vimV=$($vim --version)||echo handle error here #without export, error is captured fuse: failed to exec fusermount: No such file or directory open dir error: No such file or directory handle error here $ $ export vimV=$($vim --version)||echo handle error here #with export, error is lost fuse: failed to exec fusermount: No such file or directory open dir error: No such file or directory $ It's the assignment statement that's the oddball here; it's the only place where the exit status from a command substitution has any effect. This is a POSIX (maybe ksh) invention to provide assignment statements with a useful exit status. The `export' builtin completed successfully: it assigned the correct value to `vimV' and marked it for export. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: extdebug now implies errtrace which implies `trap ... ERR` execution w/out `set -e`
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. 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 error_trace_mode + or function_trace_mode. Fix from Grisha Levit You can take that and find the original bug report, with Grisha's patch: https://lists.gnu.org/archive/html/bug-bash/2016-05/msg0.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. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: extdebug now implies errtrace which implies `trap ... ERR` execution w/out `set -e`
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 > + > > > > + - shopt_set_debug_mode: call set_shellopts after setting > > error_trace_mode > > + or function_trace_mode. Fix from Grisha Levit > > You can take that and find the original bug report, with Grisha's patch: > > https://lists.gnu.org/archive/html/bug-bash/2016-05/msg0.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
Re: extdebug now implies errtrace which implies `trap ... ERR` execution w/out `set -e`
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 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. That's just never going to happen -- taking this argument to its logical conclusion would prohibit all bug fixes because someone might be relying on the buggy behavior. 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 error_trace_mode + or function_trace_mode. Fix from Grisha Levit You could also have looked in the CHANGES file: . Fixed a bug that caused the shell to not enable and disable function tracing with changes to the `extdebug' shell option. 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. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: extdebug now implies errtrace which implies `trap ... ERR` execution w/out `set -e`
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 > + > >>> > >>> + - shopt_set_debug_mode: call set_shellopts after setting > >>> error_trace_mode > >>> + or function_trace_mode. Fix from Grisha Levit > > You could also have looked in the CHANGES file: > > . 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
