Re: issue with debug trap
2023年12月16日(土) 6:22 Giacomo Comes : The original post asks the reason for the difference in the status between the following two cases: if ((0)); then :; else echo "here \$? is 1"; fi if ((0)); then :; fi; echo "but here \$? is 0" and the answer is that the former returns the status of ((0)) (which is $? = 1), but the latter returns the status of the entire if-statement (which is $? = 0 because no branch is selected. If any branch was selected, it would've been the exit status of the last command in the selected branch). -- Koichi
Re: issue with debug trap
On Sat, 16 Dec 2023 00:09:10 + Kerin Millar wrote: > At this point, the value of $? is 1, prior to executing true - a simple > command. Just as for any other simple command, the trap code shall be > executed beforehand. Consequently, your test observes that $? is > arithmetically false and acts accordingly. Keep in mind that this is the only > part of your script in which an "else" clause is actually reached. Of course, I meant to write "arithmetically true" there. -- Kerin Millar
Re: issue with debug trap
On Fri, 15 Dec 2023 17:21:23 -0400
Giacomo Comes wrote:
> Hi,
> I have stumbled upon a bug or something I don't understand while
> using the debug trap.
> Please run the script at the end.
> When debug is turned on, during its execution the program
> prints the line number and the line content which returned a non
> zero value (error).
>
> If you look at the script, the only line which should cause
> a non zero return value is:
> ! :
> However the script shows also a non zero return value
> before executing the 'true' command.
> I can only imagine that the sequence
> if ((0)); then
> before the 'else' is the one causing a non zero
> return value, however the previous:
> if ((0)); then
> :
> fi
> (without the else clause) does not cause a non zero return value.
> Is this the expected behavior (and if yes why)?
Yes, it is to be expected.
$ if false; then true; else echo "$?"; fi
1
> Or is it a bug?
> Seen in bash 4.4 and 5.2.
>
> Giacomo Comes
>
> #!/bin/bash
> debugon () {
> trap 'if (($?)); then echo "$((LINENO-1)): $(sed -n "$((LINENO-1))p"
> "$0")" ; fi' DEBUG
> }
The trap here ought to report LINENO without deducting 1. Otherwise, it is a a
recipe for confusion.
> debugoff () {
> trap '' DEBUG
> }
> debugon
>
> :
> ! :
> if ((1)); then
> :
> fi
> if ((0)); then
> :
> fi
> if ((1)); then
> :
> else
> :
> fi
> if ((0)); then
> :
> else
At this point, the value of $? is 1, prior to executing true - a simple
command. Just as for any other simple command, the trap code shall be executed
beforehand. Consequently, your test observes that $? is arithmetically false
and acts accordingly. Keep in mind that this is the only part of your script in
which an "else" clause is actually reached.
> true
> fi
>
> debugoff
>
>
--
Kerin Millar
Job control: process running from pipe doesn't get focus
From: maksym
To: bug-bash@gnu.org
Subject: Job control: process running from pipe doesn't get focus
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
-fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security
-fstack-clash-protection -fcf-protection -g
-ffile-prefix-map=/build/bash/src=/usr/src/debug/bash -flto=auto
-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 inspiron 6.1.61-1-lts #1 SMP PREEMPT_DYNAMIC Thu, 02 Nov
2023 12:57:06 + x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.2
Patch Level: 21
Release Status: release
Description:
Process does not become foreground when run from a pipe.
Repeat-By:
Conditions are very special, and I am not sure who in the chain is cause of
bug.
In short the bug in the following line, but it should executed not from a
running terminal emulator:
uxterm -e bash -c 'echo /etc/fstab | { FILE="$(cat)" ; sudoedit "$FILE"
; }'
It line of script must be run automatically from the WM.
The chain to reproduce:
| sway wm | | uxterm| | bash ... sudoedit |
| i3 wm | --> | alacritty | -> | |
| weston | | | | |
swaywm config file:
exec_always uxterm -e bash -c 'echo /etc/fstab | { FILE="$(cat)" ;
sudoedit "$FILE" ; }'
If sudoedit running not from a pipe, it works good. Some of terminal
emulators do not reproduces
the problem, such as `foot` or `xfce4-terminal`.
The result of the chain is an editor isn't gain a focus and I cant type
anything.
Again, I'm not sure that is definetely bash, but could you please check
that. Thank you.
issue with debug trap
Hi,
I have stumbled upon a bug or something I don't understand while
using the debug trap.
Please run the script at the end.
When debug is turned on, during its execution the program
prints the line number and the line content which returned a non
zero value (error).
If you look at the script, the only line which should cause
a non zero return value is:
! :
However the script shows also a non zero return value
before executing the 'true' command.
I can only imagine that the sequence
if ((0)); then
before the 'else' is the one causing a non zero
return value, however the previous:
if ((0)); then
:
fi
(without the else clause) does not cause a non zero return value.
Is this the expected behavior (and if yes why)?
Or is it a bug?
Seen in bash 4.4 and 5.2.
Giacomo Comes
#!/bin/bash
debugon () {
trap 'if (($?)); then echo "$((LINENO-1)): $(sed -n "$((LINENO-1))p" "$0")"
; fi' DEBUG
}
debugoff () {
trap '' DEBUG
}
debugon
:
! :
if ((1)); then
:
fi
if ((0)); then
:
fi
if ((1)); then
:
else
:
fi
if ((0)); then
:
else
true
fi
debugoff
Re: Ability to display parameters as global with `declare -gp`
On 12/11/23 10:01 AM, Albert Akchurin wrote: Bash Version: 5.2 Patch Level: 21 Release Status: release Description: `declare -p` loses the global flag passed to variable/array on definition. I think this behaviour is reasonable, but sometimes I need to save/restore Global variables in the function. Unfortunately when I source saved variables from a function the variables are scoped to that function. Could you please add the ability to display all the variables as global when using '-g' along with '-p' option? No internal checks needed, just Put the '-g' flag when displaying each variable definition requested. I will consider this for a future version. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
