a small cosmetic workaround fix
trap 'cmd=$BASH_COMMAND' DEBUG
PS1='$cmd'
On Sat, Mar 19, 2022 at 6:12 PM Taqras via Bug reports for the GNU Bourne
Again SHell 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 EliteBook 5.16.15-arch1-1 #1 SMP PREEMPT Thu, 17 Mar
> 2022 00:30:09 + x86_64 GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
>
> Bash Version: 5.1
> Patch Level: 16
> Release Status: release
>
> Description:
> PS0:
>The value of this parameter is expanded like PS1 and displayed by
>interactive shells after reading a command and before the command is
>executed.
> BASH_COMMAND:
>The command currently being executed or about to be executed, unless
>the shell is executing a command as the result of a trap, in which
>case it is the command executing at the time of the trap. If
>BASH_COMMAND is unset, it loses its special properties,
>even if it is subsequently reset.
> PROBLEM:
>By the time PS0 is displayed, BASH_COMMAND is still set to the
>previous command, not the command about to be executed.
>
>And that's just about the only problem:
>Thank you very much for your good work!!!
>
> Repeat-By:
> PS0="$BASH_COMMAND"
>
> Fix:
> Assign BASH_COMMAND before expanding PS0
>
