Re: BASH_COMMAND does not expand correctly in subshells inside traps.
I see; I thought this change of behaviour was an unintentional
regression since I noticed that there were some changes to traps.
I actually think this new behaviour makes more sense.
I think that that old DEBUG trap can be ported to bash5 like so:
debug_prompt () { read -p "[$BASH_SOURCE:$LINENO] $BASH_COMMAND?" _ ;}
trap 'debug_prompt "$_"' DEBUG
or even like so (to avoid issues with `unset -f debug_prompt'):
trap '
debug_prompt () { read -p "[$BASH_SOURCE:$LINENO] $BASH_COMMAND?" _ ;}
debug_prompt "$_"
' DEBUG
It is a bit inconvenient that this solution requires a function, but it
should not be a big deal in most situations.
Cheers,
emanuele6
On 05/11/2021, Chet Ramey wrote:
> On 11/4/21 5:49 PM, Emanuele Torre wrote:
>
>> 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.
>
> This is a variant of
>
> https://lists.gnu.org/archive/html/help-bash/2021-10/msg00269.html
>
> In this case, as explained in the above message, the subshell `forgets'
> that it's executing as part of the DEBUG trap. Since we're not in the
> DEBUG trap, the value of BASH_COMMAND doesn't get updated. As a
> consequence, since the expansion of the command happens in the subshell,
> the original value (unexpanded in the parent shell) remains.
>
> I think I might have to rethink this strategy. What do you think?
>
> 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: BASH_COMMAND does not expand correctly in subshells inside traps.
am additional meta data structure one for saving and restoring traps one for like is-in-debug-trap On Fri, Nov 5, 2021, 17:12 Chet Ramey wrote: > On 11/4/21 5:49 PM, Emanuele Torre wrote: > > > 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. > > This is a variant of > > https://lists.gnu.org/archive/html/help-bash/2021-10/msg00269.html > > In this case, as explained in the above message, the subshell `forgets' > that it's executing as part of the DEBUG trap. Since we're not in the > DEBUG trap, the value of BASH_COMMAND doesn't get updated. As a > consequence, since the expansion of the command happens in the subshell, > the original value (unexpanded in the parent shell) remains. > > I think I might have to rethink this strategy. What do you think? > > 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: BASH_COMMAND does not expand correctly in subshells inside traps.
On 11/4/21 5:49 PM, Emanuele Torre wrote: 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. This is a variant of https://lists.gnu.org/archive/html/help-bash/2021-10/msg00269.html In this case, as explained in the above message, the subshell `forgets' that it's executing as part of the DEBUG trap. Since we're not in the DEBUG trap, the value of BASH_COMMAND doesn't get updated. As a consequence, since the expansion of the command happens in the subshell, the original value (unexpanded in the parent shell) remains. I think I might have to rethink this strategy. What do you think? 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: BASH_COMMAND does not expand correctly in subshells inside traps.
> $ cat test1 > trap 'echo "$BASH_COMMAND"' DEBUG > echo hello > $ cat test2 > trap '(echo "$BASH_COMMAND")' DEBUG > echo hey > bash And the content of the test files was really: $ cat test1 trap 'echo "$BASH_COMMAND"' DEBUG echo hey $ cat test2 trap '(echo "$BASH_COMMAND")' DEBUG echo hey Sorry again. On 04/11/2021, Emanuele Torre wrote: >> 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) >> >
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) >
