Loop within trap handling
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-suse-linux-gnu' -DCONF_VENDOR='suse' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -g -D_GNU_SOURCE -DRECYCLES_PIDS -Wall -g -Wuninitialized -Wextra -Wno-switch-enum -Wno-unused-variable -Wno-unused-parameter -Wno-parentheses -ftree-loop-linear -pipe -DBNC382214=0 -DIMPORT_FUNCTIONS_DEF=0 -fprofile-use -fprofile-correction uname output: Linux noether 4.15.10-1.g5e4329c-default #1 SMP PREEMPT Thu Mar 15 20:31:17 UTC 2018 (5e4329c) x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-suse-linux-gnu Bash Version: 4.4 Patch Level: 19 Release Status: release Description: A user reports a problem with example code included. By using the the code shown below and doing Ctrl-C twice the code hangs within a SIGINT loop if /bin/echo is used instead of builtin echo command. Repeat-By: cat /tmp/trap.sh #!/bin/sh ## Works #trap 'echo "Type to exit" 1>&2; read xxx; exit 1' 1 2 3 15 ## Does not work trap '/bin/echo "Type to exit" 1>&2; read xxx; exit 1' 1 2 3 15 while :; do sleep 2; done /bin/bash /tmp/trap.sh ^CType to exit ^C
Strange behaviour when sending SIGTERM to bash
Hello, I'm running bash under Debian Stretch: $ echo $BASH_VERSION 4.4.12(1)-release $ trap $ echo $$ 1100 $ kill 1100 $ => Looks fine for me Then I do a kill 1100 from another session and the bash above terminates. => Looks wrong for me Greetings, Martin
command_not_found_handle strange behaviour
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu'
-DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_FORTIFY_SOURCE=2
-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -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
-Wno-parentheses -Wno-format-security
uname output: Linux articunoIceCave 4.15.13-1-ARCH #1 SMP PREEMPT Sun Mar 25
11:27:57 UTC 2018 x86_64 GNU/Linux
Machine Type: x86_64-unknown-linux-gnu
Bash Version: 4.4
Patch Level: 19
Release Status: release
Description:
I can't understand why read works without subshell before it,
but with subshell before read it stops
command_not_found_handle()
{
(true) # subshell call
read line
echo "$line"
}
bash-4.4$ foo
[1]+ Stopped foo
And without subshell call it works fine:
command_not_found_handle()
{
read line
echo "$line"
}
bash-4.4$ foo
smth
smth
bash-4.4$
Repeat-By:
call some command which doesn't exist with different handlers
--
Кириллов Дмитрий
important bug
If you execute the following script the result is wrong. It is self
explaining:
---
#
# GNU bash, version 4.4.12(1)-release (x86_64-slackware-linux-gnu)
# Linux ... 4.9.31 #1 SMP Wed Jun 7 14:57:36 CDT 2017 x86_64 Intel(R)
Core(TM) i5-7400 CPU @ 3.00GHz GenuineIntel GNU/Linux
#
test a = a && {
echo this line should be displayed
test a = b && {
echo this line should also not displayed, but creates the error
}
# echo uncomment this line and all works fine again
} || {
echo this line should never be displayed
}
#
--
If you uncomment the line in the middle, the script works
correct.
I hope, it helps
Mit freundlichen Gruessen / Best regards
Klaus Bartels
///-///
/// Bartels EDV (Bartels Consulting) ///
/// Klaus Bartels ///
/// Am Bullerbach 11 Phone +49-5484/93 91 0 ///
/// D-49536 Lienen FAX +49-5484/93 91 16 ///
/// Germanye-Mail bart...@bartels.com ///
///-///
Re: important bug
On Wed, Mar 28, 2018 at 08:22:16PM +0200, Klaus Bartels wrote:
> If you execute the following script the result is wrong. It is self
> explaining:
> ---
> #
> # GNU bash, version 4.4.12(1)-release (x86_64-slackware-linux-gnu)
> # Linux ... 4.9.31 #1 SMP Wed Jun 7 14:57:36 CDT 2017 x86_64 Intel(R)
> Core(TM) i5-7400 CPU @ 3.00GHz GenuineIntel GNU/Linux
> #
> test a = a && {
> echo this line should be displayed
> test a = b && {
> echo this line should also not displayed, but creates the error
> }
> # echo uncomment this line and all works fine again
> } || {
> echo this line should never be displayed
> }
> #
> --
> If you uncomment the line in the middle, the script works correct.
> I hope, it helps
First of all, your indentation is bad. The way the curly braces fail
to line up hides the intent of the program.
Second, the use of && and || together is a really bad idea, as explained
here:
Here's what you have:
wooledg:~$ true && { echo 1; false && { echo 2; }; } || { echo 3; }
1
3
Here's what you actually (seem to!) want:
wooledg:~$ if true; then echo 1; if false; then echo 2; fi; else echo 3; fi
1
Now, your question is "why does inserting another echo change the
result of my program?" The answer: at the time the || in your program
is evaluated, the current exit status is that of "false" (or in your
original, "test a = b"). The exit status is still set to 1, so the
"echo 3" gets executed.
But by adding another echo statement (with an exit status of 0), by
the time the program gets to the || the current exit status is now 0,
so the "echo 3" is NOT executed.
The whole problem is caused by the chaining of && and || together.
Don't do that. It doesn't do what you think it does. It is NOT a
synonym for if; then; else; fi.
Please use the formal if; then; else; fi instead. And fix your
indentation so that the logic is understandable.
Re: important bug
On 03/28/2018 01:22 PM, Klaus Bartels wrote:
If you execute the following script the result is wrong. It is self
explaining:
Sorry, but your script behaves as documented by POSIX. It is not a bug
in bash, but in your expectations.
---
#
# GNU bash, version 4.4.12(1)-release (x86_64-slackware-linux-gnu)
# Linux ... 4.9.31 #1 SMP Wed Jun 7 14:57:36 CDT 2017 x86_64 Intel(R)
Core(TM) i5-7400 CPU @ 3.00GHz GenuineIntel GNU/Linux
#
test a = a && {
echo this line should be displayed
test a = b && {
echo this line should also not displayed, but creates the error
}
# echo uncomment this line and all works fine again
} || {
echo this line should never be displayed
}
The overall form of your script is:
pipeline1 && pipeline2 || pipeline3
Note that in shell, && and || are left-associative with EQUAL precedence
(this is unlike in C, where && has higher precedence than ||).
In short, pipeline2 is not executed unless pipeline1 has an exit status
of 0 (which it does); and pipeline3 is not executed unless the construct
"pipeline1 && pipeline2" has a non-zero exit status (the presence or
absence of your comment is affecting that; more details below). The
exit status of an AND or OR list is the exit status of the last pipeline
executed in the list, whether or not pipeline3 is executed depends on
the exit status of pipeline2.
Now, let's investigate pipeline2 in more details - you wrote it as a
single compound command containing a list; the first list item is the
echo command (which succeeds in all but corner cases like stdout hitting
ENOSPC), the second is in the form 'pipeline4 && pipeline5', and then
your are basing your test on whether there is a comment or a third
element of another echo. Comments do not count as a command, so they
cannot change the exit status; so you are observing different behavior
based on whether the third echo runs (which changes the overall status
of pipeline2 to be 0) or is a comment (which leaves the overall status
of pipeline2 as the exit status of 'pipeline4 && pipeline5'). But
pipeline4 is something that ALWAYS has non-zero status, and therefore
pipeline5 is never executed, and the exit status of 'pipeline4 &&
pipeline5' is non-zero.
So back to the overall expression: if pipeline2 has non-zero status,
then pipeline3 is run, even though that is the echo statement you
incorrectly surmised would never display.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
Re: important bug
I didn't understand clearly what you were expecting until I actually ran
your example. I think this shows your expectations more clearly:
test a = a && {
echo this line should be displayed
test a = b && {
echo this line should not be displayed and is not
}
# echo uncomment this line and the last echo will not display
} || {
echo this line should never be displayed but is
}
The "test a = b" evaluates to false, which makes the whole enclosure
after "test a = a" also false, and now the last echo will display. The
uncommented echo will make the middle clause true again, causing the
last echo to not display (as expected).
Peter
Klaus Bartels
On 03/29/2018 01:22 AM, Klaus Bartels wrote:
> If you execute the following script the result is wrong. It is self
> explaining:
> ---
> #
> # GNU bash, version 4.4.12(1)-release (x86_64-slackware-linux-gnu)
> # Linux ... 4.9.31 #1 SMP Wed Jun 7 14:57:36 CDT 2017 x86_64 Intel(R)
> Core(TM) i5-7400 CPU @ 3.00GHz GenuineIntel GNU/Linux
> #
> test a = a && {
> echo this line should be displayed
> test a = b && {
> echo this line should also not displayed, but creates the error
> }
> # echo uncomment this line and all works fine again
> } || {
> echo this line should never be displayed
> }
> #
> --
> If you uncomment the line in the middle, the script works correct.
> I hope, it helps
>
>
>
> Mit freundlichen Gruessen / Best regards
> Klaus Bartels
>
> ///-///
> /// Bartels EDV (Bartels Consulting) ///
> /// Klaus Bartels ///
> /// Am Bullerbach 11 Phone +49-5484/93 91 0 ///
> /// D-49536 Lienen FAX +49-5484/93 91 16 ///
> /// Germany e-Mail bart...@bartels.com ///
> ///-///
>
proper bash configure behavior when /dev/stdin is present, /dev/{,self/}fd are not?
When configuring bash on a self-hosted QNX 6.6 or QNX7 system: This is an OS that has /dev/stdin and friends, but does not have /dev/fd. When blind cross-compiling bash for QNX, one would get a guess answer of: bash_cv_dev_fd=standard bash_cv_dev_stdin=present When doing the safer self-hosted native configure, we get several significant improvements, but also: bash_cv_dev_fd=absent bash_cv_dev_stdin=absent When "the truth" for QNX should really be (we think): bash_cv_dev_fd=absent bash_cv_dev_stdin=present The odd configure output is due to the test having the presence of /dev/stdin guarded by testing for the existence of /dev/fd or /dev/self/fd: if *test -d /dev/fd* && (exec test -r /dev/stdin < /dev/null) ; then bash_cv_dev_stdin=present elif *test -d /proc/self/fd* && (exec test -r /dev/stdin < /dev/null) ; then bash_cv_dev_stdin=present else bash_cv_dev_stdin=absent fi At first glance it appears that: lib/sh/eaccess.c redir.c are the only consumers of HAVE_DEV_STDIN, and that the code so guarded would function in the absence of HAVE_DEV_FD. So, can those in the know weigh in on which interpretation below is correct: (a) The DEV_STDIN code block isn't relevant unless you're in the presence of DEV_FD, so it's harmless and appropriate to have the current configure output. (b) The dependency is there for good reason, and we're missing what will break in the presence of DEV_FD=no + DEV_STDIN=yes (c) There is a some other pathological environment where bash wants the DEV_STDIN code disabled when DEV_FD isn't there, and we should refine this test in our patch to further distinguish QNX from the environment that created the test w/ DEV_FD to DEV_STDIN dependency. (d) The DEV_FD -> DEV_STDIN dependency should be removed from the test completely, as a patch for all environments? Thanks! P.S. For completeness: # uname -a QNX localhost 6.6.0 2014/02/22-18:29:34EST x86pc x86 # bash -version GNU bash, version 4.3.48(1)-release (i486-pc-nto-qnx6.6.0) # uname -a QNX localhost 7.0.0 2017/02/14-16:01:20EST x86pc x86_64 # bash -version GNU bash, version 4.3.48(1)-release (x86_64-pc-nto-qnx7.0.0)
proper bash configure behavior when /dev/stdin is present, /dev/{,self/}fd are not?
When configuring bash on a self-hosted QNX 6.6 or QNX7 system: This is an OS that has /dev/stdin and friends, but does not have /dev/fd. When blind cross-compiling bash for QNX, one would get a guess answer of: bash_cv_dev_fd=standard bash_cv_dev_stdin=present When doing the safer self-hosted native configure, we get several significant improvements, but also: bash_cv_dev_fd=absent bash_cv_dev_stdin=absent When "the truth" for QNX should really be (we think): bash_cv_dev_fd=absent bash_cv_dev_stdin=present The odd configure output is due to the test having the presence of /dev/stdin guarded by testing for the existence of /dev/fd or /dev/self/fd: if *test -d /dev/fd* && (exec test -r /dev/stdin < /dev/null) ; then bash_cv_dev_stdin=present elif *test -d /proc/self/fd* && (exec test -r /dev/stdin < /dev/null) ; then bash_cv_dev_stdin=present else bash_cv_dev_stdin=absent fi At first glance it appears that: lib/sh/eaccess.c redir.c are the only consumers of HAVE_DEV_STDIN, and that the code so guarded would function in the absence of HAVE_DEV_FD. So, can those in the know weigh in on which interpretation below is correct: (a) The DEV_STDIN code block isn't relevant unless you're in the presence of DEV_FD, so it's harmless and appropriate to have the current configure output. (b) The dependency is there for good reason, and we're missing what will break in the presence of DEV_FD=no + DEV_STDIN=yes (c) There is some other pathological environment where bash wants the DEV_STDIN code disabled when DEV_FD isn't there, and we should refine this test in our patch to further distinguish QNX from the environment that created the test w/ DEV_FD to DEV_STDIN dependency. (d) The DEV_FD -> DEV_STDIN dependency should be removed from the test completely, as a patch for all environments? Thanks! P.S. For completeness: # uname -a QNX localhost 6.6.0 2014/02/22-18:29:34EST x86pc x86 # bash -version GNU bash, version 4.3.48(1)-release (i486-pc-nto-qnx6.6.0) # uname -a QNX localhost 7.0.0 2017/02/14-16:01:20EST x86pc x86_64 # bash -version GNU bash, version 4.3.48(1)-release (x86_64-pc-nto-qnx7.0.0)
