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 <chet.ra...@case.edu> 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, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
>
