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:$LINEN
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_COMM
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.h
> $ 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"
> 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 woul
