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 >
