Re: Newlines in ERR trap affect caller 0 line number
On 10/31/21 6:06 PM, Quinn Grier wrote: > Bash Version: 5.1 > Patch Level: 8 > Release Status: release > > Description: > When an ERR trap includes newlines, the line number returned by > "caller 0" is affected. Thanks for the report. I'll take a look. Right now, the ERR trap (really all traps) is treated as if the text of the trap appears inline in the source right after the command that triggered it, so parsing the text of the trap command increments the line number starting at the line number of the triggering command. Chet -- ``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: Newlines in ERR trap affect caller 0 line number
thats around the same as aliases, inline text replacements , yes ? informative question On Thu, Nov 4, 2021, 16:53 Chet Ramey wrote: > On 10/31/21 6:06 PM, Quinn Grier wrote: > > > Bash Version: 5.1 > > Patch Level: 8 > > Release Status: release > > > > Description: > > When an ERR trap includes newlines, the line number returned by > > "caller 0" is affected. > > Thanks for the report. I'll take a look. Right now, the ERR trap (really > all traps) is treated as if the text of the trap appears inline in the > source right after the command that triggered it, so parsing the text of > the trap command increments the line number starting at the line number > of the triggering command. > > Chet > > -- > ``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: Newlines in ERR trap affect caller 0 line number
On 11/4/21 11:55 AM, Alex fxmbsw7 Ratchev wrote: > thats around the same as aliases, inline text replacements , yes ? > informative question No. It's a different processing stage. -- ``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/
BASH_COMMAND does not expand correctly in subshells inside traps.
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/bin' -DSTANDARD_UTILS_PATH='/usr/bin' -DSYS_BASHRC='/etc/bash.bashrc' -DSYS_BASH_LOGOUT='/etc/bash.bash_logout' -DNON_INTERACTIVE_LOGIN_SHELLS uname output: Linux t420 5.10.75-1-lts #1 SMP Wed, 20 Oct 2021 11:02:09 + x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.1 Patch Level: 8 Release Status: release Description: BASH_COMMAND does not expand to the expected value when used in a subshell inside a trap. I tried using the following DEBUG trap that i got from http://mywiki.wooledge.org/BashGuide/Practices in bash-5.1: trap '(read -p "[$BASH_SOURCE:$LINENO] $BASH_COMMAND?")' DEBUG And noticed that $BASH_COMMAND always expanded to: read -p "[...:...] $BASH_COMMAND? where the ...:... is the expanded value of $BASH_SOURCE:$LINENO. Then I tried to use the same trap in bash-4.4 and it worked as expected. Repeat-By: $ cat test1 trap 'echo "$BASH_COMMAND"' DEBUG echo hello $ cat test2 trap '(echo "$BASH_COMMAND")' DEBUG echo hey bash $ ./bash test1 # bash-4.4 echo hey hey $ ./bash test2 # bash-4.4 echo hey hey $ bash test1 # bash-5.1 echo hey hey $ bash test2 # bash-5.1 echo "$BASH_COMMAND" hey $ ./bash --version | head -1 GNU bash, version 4.4.0(3)-release (x86_64-unknown-linux-gnu) $ bash --version | head -1 GNU bash, version 5.1.8(1)-release (x86_64-pc-linux-gnu)
Re: BASH_COMMAND does not expand correctly in subshells inside traps.
> And noticed that $BASH_COMMAND always expanded to: > > read -p "[...:...] $BASH_COMMAND? > > where the ...:... is the expanded value of $BASH_SOURCE:$LINENO. Err, sorry about that. I misremembered. It is actually expanding to read -p "[$BASH_SOURCE:$LINENO] $BASH_COMMAND" as it would normally do when used outside of a trap. The rest of the issue is still valid. On 04/11/2021, Emanuele Torre wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt > -DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/bin' > -DSTANDARD_UTILS_PATH='/usr/bin' -DSYS_BASHRC='/etc/bash.bashrc' > -DSYS_BASH_LOGOUT='/etc/bash.bash_logout' > -DNON_INTERACTIVE_LOGIN_SHELLS > uname output: Linux t420 5.10.75-1-lts #1 SMP Wed, 20 Oct 2021 > 11:02:09 + x86_64 GNU/Linux > Machine Type: x86_64-pc-linux-gnu > > Bash Version: 5.1 > Patch Level: 8 > Release Status: release > > Description: > BASH_COMMAND does not expand to the expected value when used in a > subshell inside a trap. > > I tried using the following DEBUG trap that i got from > http://mywiki.wooledge.org/BashGuide/Practices in bash-5.1: > > trap '(read -p "[$BASH_SOURCE:$LINENO] $BASH_COMMAND?")' DEBUG > > And noticed that $BASH_COMMAND always expanded to: > > read -p "[...:...] $BASH_COMMAND? > > where the ...:... is the expanded value of $BASH_SOURCE:$LINENO. > > Then I tried to use the same trap in bash-4.4 and it worked as > expected. > > Repeat-By: > > $ cat test1 > trap 'echo "$BASH_COMMAND"' DEBUG > echo hello > $ cat test2 > trap '(echo "$BASH_COMMAND")' DEBUG > echo hey > bash > > $ ./bash test1 # bash-4.4 > echo hey > hey > $ ./bash test2 # bash-4.4 > echo hey > hey > $ bash test1 # bash-5.1 > echo hey > hey > $ bash test2 # bash-5.1 > echo "$BASH_COMMAND" > hey > > $ ./bash --version | head -1 > GNU bash, version 4.4.0(3)-release (x86_64-unknown-linux-gnu) > $ bash --version | head -1 > GNU bash, version 5.1.8(1)-release (x86_64-pc-linux-gnu) >
