Re: BASH_COMMAND should be set before PS0

[Alex fxmbsw7 Ratchev]

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 <bug-bash@gnu.org> 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 +0000 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
>