++bugfixes++
On Wed, Feb 26, 2025, 3:15 PM Chet Ramey wrote:
> On 2/23/25 12:20 PM, Max Bowsher wrote:
>
> > Bash Version: 5.2
> > Patch Level: 37
> > Release Status: release
> >
> > Description:
> >
> > When using $BASH_COMMAND in an EXIT trap t
On 2/23/25 12:20 PM, Max Bowsher wrote:
Bash Version: 5.2
Patch Level: 37
Release Status: release
Description:
When using $BASH_COMMAND in an EXIT trap to tell the user what failed, I
came across a problem where errors in subshells would instead implicate the
command immediately before the
: x86_64-pc-linux-gnu
Bash Version: 5.2
Patch Level: 37
Release Status: release
Description:
When using $BASH_COMMAND in an EXIT trap to tell the user what failed, I
came across a problem where errors in subshells would instead implicate the
command immediately before the subshell, instead of the
On 8/25/23 10:40 PM, Grisha Levit wrote:
There is some inconsistency betweeen various command types in the order of
(1) setting the value used for BASH_COMMAND (2) running the DEBUG trap and
checking its return value and (3) printing the PS4 string.
Thanks for the report and patch.
--
``The
There is some inconsistency betweeen various command types in the order of
(1) setting the value used for BASH_COMMAND (2) running the DEBUG trap and
checking its return value and (3) printing the PS4 string.
While simple, arithmetic, and conditional commands follow the order above,
`for
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
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
>
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 execu
OURCE:$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
ease
> >
> > 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 me
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
> $ 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 "$BAS
> 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:$LINE
; -DSYS_BASHRC='/etc/bash.bashrc'
-DSYS_BASH_LOGOUT='/etc/bash.bash_logout'
-DNON_INTERACTIVE_LOGIN_SHELLS
uname output: Linux t420 5.10.75-1-lts #1 SMP Wed, 20 Oct 2021
11:02:09 + x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.1
Patch Level: 8
Release Stat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/22/12 3:35 PM, Mike Frysinger wrote:
> On Wednesday 22 August 2012 12:30:11 Mike Frysinger wrote:
>> consider this simple code:
>>
>> $ cat test.sh
>> #!/bin/bash
>> trap 'echo $BASH_COMMAND; exit 1
On Wednesday 22 August 2012 12:30:11 Mike Frysinger wrote:
> consider this simple code:
>
> $ cat test.sh
> #!/bin/bash
> trap 'echo $BASH_COMMAND; exit 1' ERR
> set -e
> true
> (false)
> true
>
> when run, we see:
> $ ./test.sh
> true 1
err,
consider this simple code:
$ cat test.sh
#!/bin/bash
trap 'echo $BASH_COMMAND; exit 1' ERR
set -e
true
(false)
true
when run, we see:
$ ./test.sh
true 1
this can be confusing when utilized with automatic backtraces :(
even when using errtrace and debugtrace, BASH_COMMAND is incor
Is there something I am mis-understanding about $BASH_COMMAND? The
manpage says:
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
18 matches
Mail list logo
