Segmentation faults with 64bit bash on sparc64 linux
Configuration Information [Automatically generated, do not change]: Machine: sparc64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='sparc64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='sparc64-unknown-linux-gnu' -DCONF_VENDOR='unknown' -DLOCALEDIR='/pkg/bash/share/locale' -D PACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2 uname output: Linux spawn.secure 2.6.18.1 #1 SMP Thu Oct 19 16:38:47 BST 2006 sparc64 GNU/Linux Machine Type: sparc64-unknown-linux-gnu Bash Version: 3.2 Patch Level: 1 Release Status: release Description: Reproducible Segmentation fault when building large packages like gcc, binutils, glibc etc. This is a 64bit bash running under linux 2.6.18.1 and the latest glibc2.5-branch, built with gcc-4.1.1 and linux binutils 2.17.50.0.6 The problem has been seen with bash 2.05b, 3.0, 3.1 and 3.2, all with the official patches. Different versions seem to segfault at different places during the (for example) gcc build, but always reproducibly and the symtoms are similar. As an example, during the 'make' phase of building gcc-4.1.1, the Makefile runs various configure scripts. Here is a typical failure: Links are now set up to build a native compiler for sparc64-unknown-linux-gnu. updating cache ./config.cache configure: creating ./config.status /home/andrew/dump/gcc-4.1.1/gcc/configure: line 18008: 25581 Segmentation fault (core dumped) $SHELL $CONFIG_STATUS $ac_config_status_args make[1]: *** [configure-gcc] Error 1 make[1]: Leaving directory home/andrew/dump/gcc-4.1.1' make: *** [all] Error 2 Analysing the core file with gdb: [EMAIL PROTECTED] gcc-4.1.1 $ gdb GNU gdb 6.5 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc64-unknown-linux-gnu". (gdb) file /bin/bash Reading symbols from /bin/bash...(no debugging symbols found)...done. Using host libthread_db library "/pkg/glibc/lib/libthread_db.so.1". (gdb) core-file /tmp/corefiles/core warning: core file may not match specified executable file. Reading symbols from /pkg/ncurses/lib/libncurses.so.5...(no debugging symbols found)...done. Loaded symbols for /pkg/ncurses/lib/libncurses.so.5 Reading symbols from /pkg/glibc/lib/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /pkg/glibc/lib/libdl.so.2 Reading symbols from /pkg/glibc/lib/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /pkg/glibc/lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/ld-linux.so.2 Core was generated by bin/sh ./config.status'. Program terminated with signal 11, Segmentation fault. #0 0xf801bed5e9b0 in siglongjmp () from /lib64/ld-linux.so.2 (gdb) bt #0 0xf801bed5e9b0 in siglongjmp () from /lib64/ld-linux.so.2 #1 0xf801bed55ef4 in _dl_signal_error () from /lib64/ld-linux.so.2 (gdb) Given the involvement of ld-linux.so.2, I tried building and using a statically linked bash (3.2), and sure enough it does NOT exhibit the segfaults at all. Google does not show any similar reports, but I may be peculiar in running a pure 64bit sparc64 distro (and hence bash) since debian, ubuntu et al run a predominately 32bit distro with 32bit bash. I'm not entirely sure where to go next; I have temporarily solved the issue by using a statically linked bash, but any suggestions on how to resolve this issue would be gratefully received :) Andrew Walrond ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Segmentation faults with 64bit bash on sparc64 linux
On Thu, Oct 26, 2006 at 03:25:17PM +, [EMAIL PROTECTED] wrote: > > Given the involvement of ld-linux.so.2, I tried building and using a > statically linked bash (3.2), and sure enough it does NOT exhibit the > segfaults at all. > It seems I was a bit premature here. The static bash does indeed segfault with the same symptoms: GNU gdb 6.5 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc64-unknown-linux-gnu". (gdb) file /bin/sh Reading symbols from /bin/sh...(no debugging symbols found)...done. Using host libthread_db library "/pkg/glibc/lib/libthread_db.so.1". (gdb) core-file /tmp/corefiles/core Core was generated by bin/sh /home/public/sparc64/tmp/gcc-4-1.heretix/gcc-4.1.1/libiberty/configure'. Program terminated with signal 11, Segmentation fault. #0 0x00196a90 in siglongjmp () (gdb) bt #0 0x00196a90 in siglongjmp () #1 0x00205cac in _dl_signal_error () (gdb) > > Andrew Walrond ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Segmentation faults with 64bit bash on sparc64 linux
On Fri, Oct 27, 2006 at 12:42:13PM -0400, Chet Ramey wrote: > > OK, but knowing that helps only a little. There is still no indication > of what the problem with bash might be. Since I have no 64-bit linux > or sparc systems, I need a place to start. > Chet - thanks for the reply. Park this for a moment; I am nearly convinced this problem is down to the sparc64 linux kernel being miscompiled by gcc-4.1.1. I'm in the middle of running some tests using a kernel built with a patched compiler; so far, everything is working fine, but I'll let you know the outcome shortly. Andrew Walrond ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Developement
Norman Virus Control a supprimé le message original qui contenait le virus [EMAIL PROTECTED] ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
[PATCH] Avoid pronouns in documentation
In the context of the recent discussion regarding the use of pronouns in
the Bash documentation, here is an alternate patch which rewrites the
relevant sentences to avoid altogether the use of pronouns to refer to
an unspecified person.
(Someone may have once said, "If all your answers are bad ones, you're
asking the wrong question.")
I've left pronouns referring to specific individuals unchanged, on the
assumption that those pronouns are correct for those individuals.
--Andrew Church
http://achurch.org/
diff --git a/doc/bashref.texi b/doc/bashref.texi
index 620e13de..82e15900 100644
--- a/doc/bashref.texi
+++ b/doc/bashref.texi
@@ -7844,11 +7844,11 @@ the shell spawned to execute the script.
The restricted shell mode is only one component of a useful restricted
environment. It should be accompanied by setting @env{PATH} to a value
that allows execution of only a few verified commands (commands that
-allow shell escapes are particularly vulnerable), leaving the user
-in a non-writable directory other than his home directory after login,
-not allowing the restricted shell to execute shell scripts, and cleaning
-the environment of variables that cause some commands to modify their
-behavior (e.g., @env{VISUAL} or @env{PAGER}).
+allow shell escapes are particularly vulnerable), changing the current
+directory to a non-writable directory other than the user's home
+directory after login, not allowing the restricted shell to execute
+shell scripts, and cleaning the environment of variables that cause some
+commands to modify their behavior (e.g., @env{VISUAL} or @env{PAGER}).
Modern systems provide more secure ways to implement a restricted environment,
such as @code{jails}, @code{zones}, or @code{containers}.
diff --git a/doc/oldbash.texi b/doc/oldbash.texi
index b8e9a866..1e3f006e 100644
--- a/doc/oldbash.texi
+++ b/doc/oldbash.texi
@@ -8805,7 +8805,7 @@ fi
LOGIN_SHELL=true
-# If the user has her own init file, then use that one, else use
+# If the user has a custom init file, then use that one, else use
# the canonical one.
@c why in separate rc file instead of right here?
if [ -f ~/.bashrc ]; then
diff --git a/lib/readline/doc/rltech.texi b/lib/readline/doc/rltech.texi
index d234dd8b..caf90f55 100644
--- a/lib/readline/doc/rltech.texi
+++ b/lib/readline/doc/rltech.texi
@@ -1651,8 +1651,8 @@ main (int c, char **v)
Signals are asynchronous events sent to a process by the Unix kernel,
sometimes on behalf of another process. They are intended to indicate
-exceptional events, like a user pressing the interrupt key on his terminal,
-or a network connection being broken. There is a class of signals that can
+exceptional events, like a user pressing the terminal's interrupt key, or
+a network connection being broken. There is a class of signals that can
be sent to the process currently reading input from the keyboard. Since
Readline changes the terminal attributes when it is called, it needs to
perform special processing when such a signal is received in order to
@@ -2199,9 +2199,9 @@ shell variables and hostnames.
@deftypevar int rl_completion_query_items
Up to this many items will be displayed in response to a
-possible-completions call. After that, readline asks the user if she is sure
-she wants to see them all. The default value is 100. A negative value
-indicates that Readline should never ask the user.
+possible-completions call. After that, Readline asks the user for
+confirmation of whether to display them all. The default value is 100.
+A negative value indicates that Readline should never ask the user.
@end deftypevar
@deftypevar {int} rl_completion_append_character
diff --git a/lib/readline/doc/rluser.texi b/lib/readline/doc/rluser.texi
index f4d4860d..19bb395e 100644
--- a/lib/readline/doc/rluser.texi
+++ b/lib/readline/doc/rluser.texi
@@ -338,8 +338,8 @@ typed by the user or be part of the contents of the current
line.
Although the Readline library comes with a set of Emacs-like
keybindings installed by default, it is possible to use a different set
of keybindings.
-Any user can customize programs that use Readline by putting
-commands in an @dfn{inputrc} file, conventionally in his home directory.
+Any user can customize programs that use Readline by putting commands
+in an @dfn{inputrc} file, conventionally in the user's home directory.
The name of this
@ifset BashFeatures
file is taken from the value of the shell variable @env{INPUTRC}. If
Re: Bash reference manual feedback
>> 9. It is probably unhelpful to use the "’" character here. > >You have inadvertently stated the entire point of this section: yes, they >are an unhelpful historical anomaly and should not be used in scripts. Of >course this advisory has to actually show the characters that it's telling >you to avoid. I suspect the intent here was to point out the use of the "smart quote" (U+2019) instead of the intended ASCII single quote (U+0027). --Andrew Church https://achurch.org/
Bash ONESHOT optimization in conjunction with interactive mode breaks
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security uname output: Linux nas 5.15.85 #1-NixOS SMP Wed Dec 21 16:36:38 UTC 2022 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.1 Patch Level: 16 Release Status: release Description: When running a command in interactive mode (i.e. bash -ic '/some/command') a bash script will stop itself and put it in the background unexpectedly. Repeat-By: Take the following script: #!/usr/bin/env bash # Run some command in an interactive shell $SHELL -ic '/usr/bin/env echo hello' export IN_SHELL_TEST=true # Launch a new $SHELL with modified environment $SHELL -i A typical session looks like this: $ ./shell-test hello [1]+ Stopped ./shell-test $ echo $IN_SHELL_TEST $ fg ./shell-test $ echo $IN_SHELL_TEST true This is very unexpected behavior. I would expect to launch directly into the new shell, rather than have it start in the background. Fix: Alex Shpilkin discovered that disabling ONESHOT optimization prevents the bug from presenting. He did this by recompiling bash after removing '#define ONESHOT'. Another mitigation is to prefix the first command with `exec`, for example: $SHELL -ic 'exec /usr/bin/env echo hello'
HP-UX exec tee hanging/not working intermittently
Configuration Information [Automatically generated, do not change]: Machine: ia64 OS: hpux11.31 Compiler: cc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='ia64' -DCONF_OSTYPE='hpux11.31' -DCONF_MACHTYPE='ia64-hp-hpux11.31' -DCONF_VENDOR='hp' -DLOCALEDIR='/u sr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -DHPUX -I. -I. -I./include -I./lib -O -I/usr/local/include -D_XOPEN_SOURCE_EXTENDED uname output: HP-UX van-saml B.11.31 U ia64 3018224905 unlimited-user license Machine Type: ia64-hp-hpux11.31 Bash Version: 4.2 Patch Level: 10 Release Status: release Description: I am attempting to use exec and tee to have my scripts stdout/stderr appended to a log file like such: exec > >(tee -a $LOG) 2>&1 These scripts will often call other scripts with a similar exec statement, often writing to a separate log file. On my GNU/Linux systems, these scripts will run just fine without any issue, but on HP-UX they seem to hang or not display any output. Repeat-By: $ cat test_exec1.sh #!/bin/bash LOG="test_exec.log" exec > >(/usr/bin/tee -a $LOG) 2>&1 echo "i am exec1.." ./test_exec2.sh echo "i am done in exec1.." $ cat test_exec2.sh #!/bin/bash LOG="test_exec2.log" exec > >(/usr/bin/tee -a $LOG) 2>&1 echo "i am exec2.." echo "i am done in exec2.." On one of my HP-UX hosts I can run this script many times before it hangs. $ while true; do ./test_exec1.sh; done i am exec1.. i am done in exec1.. i am exec2.. i am done in exec2.. ...snip lots of repeats... i am done in exec1.. i am exec2.. i am done in exec2.. i am exec1.. $ echo $? 130 On the following host it hangs much more quickly and we don't in fact get any output from test_exec2.sh script. $ while true; do ./test_exec1.sh; done i am exec1.. i am done in exec1.. i am exec1.. i am done in exec1.. i am exec1.. i am done in exec1.. i am exec1.. i am done in exec1.. i am exec1.. i am done in exec1.. i am exec1.. i am done in exec1.. i am exec1.. i am done in exec1.. i am exec1.. i am done in exec1.. i am exec1.. i am done in exec1.. i am exec1.. i am done in exec1.. $ echo $? 130 Other times it just refuses to run at all: $ ./test_exec1.sh $ echo $? 141 I'd really appreciate some guidance on this issue, if you believe it is a bash bug or if in fact it's purely an issue with HP-UX or system configuration. If its helpful, I can provide tusc output for these commands. Thank you.
Re: HP-UX exec tee hanging/not working intermittently
On Tue, Jul 31, 2012 at 4:55 AM, Greg Wooledge wrote: > On Mon, Jul 30, 2012 at 02:17:15PM -0700, Andrew Resch wrote: >> I am attempting to use exec and tee to have my scripts >> stdout/stderr appended to a log file like such: exec > >(tee -a $LOG) >> 2>&1 >> These scripts will often call other scripts with a similar >> exec statement, often writing to a separate log file. On my GNU/Linux >> systems, >> these scripts will run just fine without any issue, but on >> HP-UX they seem to hang or not display any output. > > The major difference here is that bash on HP-UX implements process > substitutions (the <() syntax) with a named pipe, whereas on Linux > it uses a /dev/fd/* file. > >> $ cat test_exec1.sh >> #!/bin/bash >> >> LOG="test_exec.log" >> exec > >(/usr/bin/tee -a $LOG) 2>&1 >> >> echo "i am exec1.." >> >> ./test_exec2.sh >> >> echo "i am done in exec1.." > >> $ while true; do ./test_exec1.sh; done > > You are opening a slew of named pipes and background jobs in rapid > succession, and not waiting for the jobs to finish. (It might still be > considered a bug... I'm just pointing out the practical aspects.) > I would bet that putting a "sleep 1" in the loop would make the problem > stop happening, as horrible a hack as that may be. Yes, fair enough. I did the loop to simply make the issue more apparent, but many times I couldn't even run the test_exec1.sh script once successfully on one of my hosts. In those cases I'm not sure how large of a sleep I'd need to make it work ;) > I discuss this a bit on <http://mywiki.wooledge.org/BashFAQ/106>. The > only way to ensure clean operation is to avoid the <() syntax altogether > and use your own explicit named pipe and background job. Then you can > close the pipe and wait for the background job to terminate before > exiting. Thank you for this. I have removed the process substitution from my scripts and replaced it with using explicit named pipes, and now everything is working as expected.
multi-line alias executed out of order
Configuration Information [Automatically generated, do not change]:Machine: x86_64OS: linux-gnuCompiler: gccCompilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Walluname output: Linux ubuntu 3.11.0-12-generic #19-Ubuntu SMP Wed Oct 9 16:20:46 UTC 2013 x86_64 x86_64 x86_64 GNU/LinuxMachine Type: x86_64-pc-linux-gnu Bash Version: 4.2Patch Level: 45Release Status: release Description:In a multi-line alias, where entries are separated by semi-colon, "source" commands are not executed in-step with all the other commands. After all the non "source" commands are executed, the "source" commands are executed in reverse order. See below for an example. Repeat-By: ubuntu@ubuntu:~$ cat script.sh#!/bin/bash(echo -n "$1 "; date +%S.%N)ubuntu@ubuntu:~$ alias foo1alias foo1='~/script.sh one; source ~/script.sh two; source ~/script.sh three; ~/script.sh four'ubuntu@ubuntu:~$ alias foo2alias foo2='~/script.sh one;source ~/script.sh two;source ~/script.sh three;~/script.sh four;'ubuntu@ubuntu:~$ foo1one 09.742581873two 09.745315889three 09.749212492four 09.761410711ubuntu@ubuntu:~$ foo2one 11.805819275four 11.819741270three 11.828260887two 11.829470548 Fix: Use a single-line alias. Or use the "&&" operator to chain commands (which changes the functionality to be short-circuit evaluations). Also verified this behavior on RHEL6 with bash 4.1.2(1). Thanks!Andrew Martin
Re: FW: multi-line alias executed out of order
Chet & Pierre: My apologies, the newlines were somehow removed by my email client. First, here's a properly formatted pastebin link: http://pastebin.com/raw.php?i=AhF89GfT And here's another attempt at a properly formatted report: 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-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall uname output: Linux ubuntu 3.11.0-12-generic #19-Ubuntu SMP Wed Oct 9 16:20:46 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.2 Patch Level: 45 Release Status: release Description: In a multi-line alias, where entries are separated by semi-colon, "source" commands are not executed in-step with all the other commands. After all the non "source" commands are executed, the "source" commands are executed in reverse order. See below for an example. Repeat-By: ubuntu@ubuntu:~$ cat script.sh #!/bin/bash (echo -n "$1 "; date +%S.%N) ubuntu@ubuntu:~$ alias foo1 alias foo1='~/script.sh one; source ~/script.sh two; source ~/script.sh three; ~/script.sh four' ubuntu@ubuntu:~$ alias foo2 alias foo2='~/script.sh one; source ~/script.sh two; source ~/script.sh three; ~/script.sh four; ' ubuntu@ubuntu:~$ foo1 one 09.742581873 two 09.745315889 three 09.749212492 four 09.761410711 ubuntu@ubuntu:~$ foo2 one 11.805819275 four 11.819741270 three 11.828260887 two 11.829470548 Fix: Use a single-line alias. Or use the "&&" operator to chain commands (which changes the functionality to be short-circuit evaluations). Also verified this behavior on RHEL6 with bash 4.1.2(1). Thanks, Andrew Martin On Tue, Dec 17, 2013 at 8:41 PM, Andrew Martin wrote: > > >> Date: Tue, 17 Dec 2013 10:14:23 -0500 >> From: chet.ra...@case.edu >> To: andrewcmar...@msn.com >> CC: bug-bash@gnu.org; b...@packages.debian.org; chet.ra...@case.edu >> Subject: Re: multi-line alias executed out of order > >> >> >> > Description:In a multi-line alias, where entries are separated by >> > semi-colon, "source" commands are not executed in-step with all the other >> > commands. After all the non "source" commands are executed, the "source" >> > commands are executed in reverse order. See below for an example. >> > Repeat-By: >> > ubuntu@ubuntu:~$ cat script.sh#!/bin/bash(echo -n "$1 "; date >> > +%S.%N)ubuntu@ubuntu:~$ alias foo1alias foo1='~/script.sh one; source >> > ~/script.sh two; source ~/script.sh three; ~/script.sh >> > four'ubuntu@ubuntu:~$ >> > alias foo2alias foo2='~/script.sh one;source ~/script.sh two;source >> > ~/script.sh three;~/script.sh four;'ubuntu@ubuntu:~$ foo1one >> > 09.742581873two >> > 09.745315889three 09.749212492four 09.761410711ubuntu@ubuntu:~$ foo2one >> > 11.805819275four 11.819741270three 11.828260887two 11.829470548 > >> > Fix: >> > Use a single-line alias. Or use the "&&" operator to chain commands >> > (which changes the functionality to be short-circuit evaluations). >> >> I can't reproduce this on Mac OS X or RHEL 5. You might also consider >> adding a few newlines into your report for readability. >> >> Chet >> -- >> ``The lyf so short, the craft so long to lerne.'' - Chaucer >> ``Ars longa, vita brevis'' - Hippocrates >> Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
bash cross with installed readline
Dear All,
When we build bash for some targets the INCLUDES variable for BUILD_CC
contains the path to target readline headers. This path points to the
target headers which not preferred for utilities which prepared for build
machine.
Also when we have installed readline on the target the configure script
avoids cross_compilation problems with AC_TRY_RUN and substitutes wrong
(very old) version of libreadline. If we sure that we installed correct
readline version we can change configure script for cross compilation
process.
Please look at attached patches. If this solution can be used for common
case then please apply these patches for the future versions of bash.
Best Regards,
Andrey K.
diff -b --unified -Nr bash-4.2-orig/Makefile.in bash-4.2/Makefile.in
--- bash-4.2-orig/Makefile.in 2010-12-01 03:22:42.0 +0300
+++ bash-4.2/Makefile.in 2014-03-16 13:07:47.973897424 +0400
@@ -142,14 +142,17 @@
BASE_CCFLAGS = $(PROFILE_FLAGS) $(SYSTEM_FLAGS) $(LOCAL_DEFS) \
$(DEFS) $(LOCAL_CFLAGS) $(INCLUDES)
+BASE_CCFLAGS_FOR_BUILD = $(PROFILE_FLAGS) $(SYSTEM_FLAGS) $(LOCAL_DEFS) $(DEFS) $(LOCAL_CFLAGS) $(INCLUDES_FOR_BUILD)
+
CCFLAGS = $(BASE_CCFLAGS) $(CPPFLAGS) $(CFLAGS)
-CCFLAGS_FOR_BUILD = $(BASE_CCFLAGS) $(CPPFLAGS_FOR_BUILD) $(CFLAGS_FOR_BUILD)
+CCFLAGS_FOR_BUILD = $(BASE_CCFLAGS_FOR_BUILD) $(CPPFLAGS_FOR_BUILD) $(CFLAGS_FOR_BUILD)
LDFLAGS = @LDFLAGS@ $(STATIC_LD) $(LOCAL_LDFLAGS) $(PROFILE_FLAGS) $(CFLAGS)
LDFLAGS_FOR_BUILD = @LDFLAGS_FOR_BUILD@ $(LOCAL_LDFLAGS) $(CFLAGS_FOR_BUILD)
INCLUDES = -I. @RL_INCLUDE@ -I$(srcdir) -I$(BASHINCDIR) -I$(LIBSRC) $(INTL_INC)
+INCLUDES_FOR_BUILD = -I. -I$(srcdir) -I$(BASHINCDIR) -I$(LIBSRC) $(INTL_INC)
# Maybe add: -Wextra
GCC_LINT_FLAGS = -O -Wall -Wshadow -Wpointer-arith -Wcast-qual -Wno-parentheses \
diff -b --unified -Nr bash-4.2-orig/builtins/Makefile.in bash-4.2/builtins/Makefile.in
--- bash-4.2-orig/builtins/Makefile.in 2010-12-21 16:37:18.0 +0300
+++ bash-4.2/builtins/Makefile.in 2014-03-16 13:07:47.973897424 +0400
@@ -86,13 +86,17 @@
MKDIRS = ${topdir}/support/mkdirs
INCLUDES = -I. -I.. @RL_INCLUDE@ -I$(topdir) -I$(BASHINCDIR) -I$(topdir)/lib -I$(srcdir) ${INTL_INC}
+INCLUDES_FOR_BUILD = -I. -I.. -I$(topdir) -I$(BASHINCDIR) -I$(topdir)/lib -I$(srcdir) ${INTL_INC}
BASE_CCFLAGS = ${PROFILE_FLAGS} $(DEFS) $(LOCAL_DEFS) $(SYSTEM_FLAGS) \
${INCLUDES} $(LOCAL_CFLAGS)
+BASE_CCFLAGS_FOR_BUILD = ${PROFILE_FLAGS} $(DEFS) $(LOCAL_DEFS) $(SYSTEM_FLAGS) \
+ ${INCLUDES_FOR_BUILD} $(LOCAL_CFLAGS)
+
CCFLAGS = $(BASE_CCFLAGS) $(CPPFLAGS) $(CFLAGS)
-CCFLAGS_FOR_BUILD = $(BASE_CCFLAGS) $(CPPFLAGS_FOR_BUILD) $(CFLAGS_FOR_BUILD)
+CCFLAGS_FOR_BUILD = $(BASE_CCFLAGS_FOR_BUILD) $(CPPFLAGS_FOR_BUILD) $(CFLAGS_FOR_BUILD)
GCC_LINT_FLAGS = -Wall -Wshadow -Wpointer-arith -Wcast-qual \
-Wcast-align -Wstrict-prototypes -Wconversion \
diff -b --unified -Nr bash-4.2-orig/aclocal.m4 bash-4.2/aclocal.m4
--- bash-4.2-orig/aclocal.m4 2010-07-05 23:36:21.0 +0400
+++ bash-4.2/aclocal.m4 2014-03-16 13:07:48.157897417 +0400
@@ -1828,7 +1828,7 @@
],
ac_cv_rl_version=`cat conftest.rlv`,
ac_cv_rl_version='0.0',
-ac_cv_rl_version='4.2')])
+ac_cv_rl_version='6.2')])
CFLAGS="$_save_CFLAGS"
LDFLAGS="$_save_LDFLAGS"
diff -b --unified -Nr bash-4.2-orig/configure bash-4.2/configure
--- bash-4.2-orig/configure 2011-02-08 01:03:22.0 +0300
+++ bash-4.2/configure 2014-03-16 13:07:48.157897417 +0400
@@ -5563,7 +5563,7 @@
$as_echo_n "(cached) " >&6
else
if test "$cross_compiling" = yes; then
- ac_cv_rl_version='4.2'
+ ac_cv_rl_version='6.2'
else
cat >conftest.$ac_ext <<_ACEOF
/* confdefs.h. */
diff -b --unified -Nr bash-4.3-orig/Makefile.in bash-4.3/Makefile.in
--- bash-4.3-orig/Makefile.in 2014-01-26 01:27:30.0 +0400
+++ bash-4.3/Makefile.in 2014-03-16 13:07:48.360897408 +0400
@@ -146,14 +146,17 @@
BASE_CCFLAGS = $(PROFILE_FLAGS) $(SYSTEM_FLAGS) $(LOCAL_DEFS) \
$(DEFS) $(LOCAL_CFLAGS) $(INCLUDES)
+BASE_CCFLAGS_FOR_BUILD = $(PROFILE_FLAGS) $(SYSTEM_FLAGS) $(LOCAL_DEFS) $(DEFS) $(LOCAL_CFLAGS) $(INCLUDES_FOR_BUILD)
+
CCFLAGS = $(BASE_CCFLAGS) $(CPPFLAGS) $(CFLAGS)
-CCFLAGS_FOR_BUILD = $(BASE_CCFLAGS) $(CPPFLAGS_FOR_BUILD) $(CFLAGS_FOR_BUILD)
+CCFLAGS_FOR_BUILD = $(BASE_CCFLAGS_FOR_BUILD) $(CPPFLAGS_FOR_BUILD) $(CFLAGS_FOR_BUILD)
LDFLAGS = @LDFLAGS@ $(STATIC_LD) $(LOCAL_LDFLAGS) $(PROFILE_FLAGS) $(CFLAGS)
LDFLAGS_FOR_BUILD = @LDFLAGS_FOR_BUILD@ $(LOCAL_LDFLAGS) $(CFLAGS_FOR_BUILD)
INCLUDES = -I. @RL_INCLUDE@ -I$(srcdir) -I$(BASHINCDIR) -I$(LIBSRC) $(INTL_INC)
+INCLUDES_FOR_BUILD = -I. -I$(srcdir) -I$(BASHINCDIR) -I$(LIBSRC) $(INTL_INC)
# Maybe add: -Wextra
GCC_LINT_FLAGS = -O -Wall -Wshadow -Wpointer-arith -Wcast-qual -Wno-parentheses \
diff -b --unified -Nr bash-4.3-orig/builtins/Makefile.in bash-4.3/builtins/Makefile.in
--- bash-4.3-orig/builtins/Makefile.in 2012-05-25 17:29:19.0 +0400
+++ bash-4.3/builtins/Makefile.in 2014-03-16 13:07:48.360897408 +0400
@@ -88,13 +88,17 @@
HELPFILES_TARGET
Re: bash cross with installed readline
Hi Mike,
Thanks a lot for quick answer. I'm sure that you in the right way. And I
hope you will test autotool scripts for both cases (system installed
readline; and inside bash src readline) for the future releases. (by the
way, the same situation we have in GCC with gmp)
I will try to use AC_TRY_COMPILE. Unfortunately I have not enough time now
but I hope I will find time slot for this in the nearest weeks.
Best Regards,
Andrey K.
On Wed, Mar 19, 2014 at 7:29 AM, Mike Frysinger wrote:
> On Sun 16 Mar 2014 13:30:55 Andrew Kosteltsev wrote:
> > When we build bash for some targets the INCLUDES variable for BUILD_CC
> > contains the path to target readline headers. This path points to the
> > target headers which not preferred for utilities which prepared for build
> > machine.
> >
> > Also when we have installed readline on the target the configure script
> > avoids cross_compilation problems with AC_TRY_RUN and substitutes wrong
> > (very old) version of libreadline. If we sure that we installed correct
> > readline version we can change configure script for cross compilation
> > process.
> >
> > Please look at attached patches. If this solution can be used for common
> > case then please apply these patches for the future versions of bash.
>
> i haven't seen the issues you describe for the first patch. maybe it's
> because i don't pass full paths to the target readline but instead let the
> toolchain find it for me. so there is never any -I flag mixing.
>
> the 2nd patch is the wrong way to approach the problem. change the
> AC_TRY_RUN
> into an AC_TRY_COMPILE test by relying on RL_VERSION_{MAJOR,MINOR} being
> defined and doing an incremental search for its value. see how autoconf
> implements its AC_CHECK_SIZEOF macro using only compile tests for the
> algorithm.
> -mike
Shell completion not honouring escaped characters
BASH_VERSION 3.1.1(1)-release Running on Fedora Core 5 (test 2) Pressing tab on a line with escape characters will ignore, and remove, the escaped characters to perform the completion. For example, pressing tab at the end of each of these lines removes the "\" and changes the meaning of the line. ls \~andy/ ls \`pwd`/ granted, the last one isn't a useful command, but does illustrate the problem. on my systems, the output is: ls ~andy/ ls /home/andy/ I've seen this on other versions of bash too (2.05b.0(1)-release and 3.00.14(1)-release). ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
locally declared arrays do not act as arrays
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I. -I./include -I./lib -O -march=pentium-m -mmmx
-mfpmath=sse -msse2 -pipe -ffast-math -funroll-loops -O3
uname output: Linux courier 2.6.11 #6 Sun May 8 23:59:20 PDT 2005 i686 unknown
unknown GNU/Linux
Machine Type: i686-pc-linux-gnu
Bash Version: 3.0
Patch Level: 16
Release Status: release
Description:
when I declare a local variable as an array it still acts as a scalar,
not as an array.
I discovered that if I seperate the local declaration from the
initialization, the variable properly acts as an array.
Repeat-By:
f() {
local B=("a" "b")
echo $B
C=("a" "b")
echo $C
}
A=("a" "b")
echo $A
f
Produces:
a
(a b)
a
Workaround:
split the declaration and initialization:
local B
B=("a" "b")
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Python and Bash
Not exactly a bug, perse. An oddity, however. I am writing some code in bash that will execute a python script, and carry on with some user input. Obivously, I called the python command through something like ( python test.py test.txt ) in order for it to be a process. However, this test.py program takes data from the serial port and saves it to a file. So, when I'm running the shell script that calls on this python script and end it with ctrl-c, it only ends the shell script, and not the python script, which continues putting serial data to a file. Now, if I kill the python script with a killall command that is within the shell script, the output file for the serial ends up being empty. Is there any command that will kill bash script-assosciated processes in a kind way (ie ctrl-c) when the overall script is ended? Thanks - A ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: NOT changing global variables
On Fri, Dec 29, 2006 at 11:43:14PM +0100, Frans de Boer wrote:
> Yes, I did expected such an answer of using a subshell, and yes I can
> get the return value, but I don need it. I need the output fed into
> another (maybe local) variable. I was under the impression that BASH was
> modeled after 'C', so I started using the functions as such. My mistake.
> I have the confirmation that it's not so strait forward as I expected.
> Never mind, I now know better, so thanks for the comment anyway.
One technique I use instead of output capturing is to use a variable
"reference". In the function allow the caller to specify a variable _name_
as a parameter. Then use eval to store the results in that variable
instead of sending it to stdout. This is similar to tcl's "upvar".
function foo() {
local data=
eval $1=\$data
}
a=1
echo $a
foo a
echo $a
If you didn't actually need a subshell to begin with then this eliminates
it. Removing extra subshells can help speed up your program, if thats
somethig that matters to you (it does to me, fwiw). Or if nothing else,
you limit the subshell's scope.
Goes without saying, that you should pick a naming convention for
variable names you intend to pass. Otherwise local function variables
may collide. "data" in place of "a" would be a bad choice in the above
example :-)
There may also be technical limitations to using eval like this. If
there are, Im eager to hear them.
-Andrew
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
RE: wrong logical evaluation of expressions involving true or falsecommands
'help test' says that an expression consisting of a single string is an alias for "-n STRING" which is "true if the string is not empty." So, [ false -a false ] and [ false ] are true because "false" is a non-empty string. [ "" ] is false. You probably just want 'true && false' without the [. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
RE: bash does not handle escape sequences for inserted paramaters to for
This will work $ eval "for i in $(echo a b\\ c); do echo \"\$i\"; done" a b c http://lists.gnu.org/archive/html/bug-bash/2007-07/msg00011.html ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
inconsistent exit status of ((count++))
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 -g -O2 uname output: Linux eccles 2.6.35-rc6 #1 SMP Fri Jul 23 11:52:29 BST 2010 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-unknown-linux-gnu Bash Version: 4.1 Patch Level: 2 Release Status: release Description: [Detailed description of the problem, suggestion, or complaint.] If I use set -e to make my scripts exit on error, the scripts fail if I use something like: count=0 ((count++)) Repeat-By: andy:~$ count=0 andy:~$ ((count++)) andy:~$ echo $? 1 andy:~$ ((count++)) andy:~$ echo $? 0 Fix: This isn't a fix but I can work around this bug if I use ((++count)) andy:~$ count=0 andy:~$ ((++count)) andy:~$ echo $? 0 andy:~$
Re: inconsistent exit status of ((count++))
On 30/07/10 19:55, Stefano Lattarini wrote: At Thursday 29 July 2010, Andrew Benton wrote: andy:~$ count=0 andy:~$ ((count++)) andy:~$ echo $? 1 andy:~$ ((count++)) andy:~$ echo $? 0 I don't think it's a bug, it's just an effect of: 1. `((EXPR))' returning a non-zero exit status iff EXPR evaluates to zero, and That makes no sense to me. Why would evaluating an expression have a non-zero exit status if there was no error? That makes the exit status no use at all for evaluating whether an error has occurred. How can I check for errors if I can't rely on the exit status? How can that not be a bug? Andy
weird behaviour of ((count++)) when using , , to change to lower case
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 -g -O2
uname output: Linux eccles 2.6.35-rc6 #1 SMP Fri Jul 23 11:52:29 BST 2010
x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-unknown-linux-gnu
Bash Version: 4.1
Patch Level: 2
Release Status: release
Description:
Incrementing a variable with ((count++)), which should access the value
in the variable and then increment it by 1 has some strange behaviour.
In some situations it seems to increment the variable before accessing
it, and in others it increments it by 2
Repeat-By:
Make an array to work with:
andy:~$ days=({Mon,Tues,Wednes,Thurs,Fri,Satur,Sun}day)
andy:~$ echo ${da...@]}
Monday Tuesday Wednesday Thursday Friday Saturday Sunday
So far, so good. Now try to access the array by stepping through it with
((count++))
andy:~$ count=0
andy:~$ echo "${days[$((count++))]}, ${days[$((count++))]},
${days[$((count++))]}"
Monday, Tuesday, Wednesday
Also good. Now try converting it to lower case with ,,
andy:~$ count=0
andy:~$ echo "${days[${count}],,}, ${days[$((count++))],,},
${days[$((count++))],,}"
monday, tuesday, thursday
What happened to wednesday?
Andy
bash-5.0_p1: wildcard expansion bug with unreadable intermediate directories
When expanding a wildcard following a partially quoted pathname, expansion fails if an intermediate directory is not readable, even when the final directory (the one in which expansion is performed) is readable. This does not occur if quotes are not used in the pathname, or if the quoted part of the pathname does not cross an unreadable directory (compare second and third expansions in the commands below). This does not occur in unpatched bash-5.0. Test case: bash-5.0$ mkdir -m700 /tmp/a /tmp/a/b bash-5.0$ touch /tmp/a/b/c bash-5.0$ echo /tmp/a/b/* "/tmp/a/"b/* "/tmp/a/b"/* /tmp/a/b/c /tmp/a/b/c bash-5.0$ chmod -r /tmp/a bash-5.0$ echo /tmp/a/b/* "/tmp/a/"b/* "/tmp/a/b"/* /tmp/a/b/c /tmp/a/b/* Note how the third expansion in the last command fails even though /tmp/a/b is readable. --Andrew Church http://achurch.org/
Re: bash-5.0_p1: wildcard expansion bug with unreadable intermediate directories
>When expanding a wildcard following a partially quoted pathname, [...] >Test case: I edited the commands in the test case when an additional thought occurred to me (the a/"b vs. a/b" distinction) but forgot to update the corresponding output lines. My apologies. Proper test case: bash-5.0$ chmod 700 /tmp/a bash-5.0$ rm -r /tmp/a bash-5.0$ mkdir -m700 /tmp/a /tmp/a/b bash-5.0$ touch /tmp/a/b/c bash-5.0$ echo /tmp/a/b/* "/tmp/a/"b/* "/tmp/a/b"/* /tmp/a/b/c /tmp/a/b/c /tmp/a/b/c bash-5.0$ chmod -r /tmp/a bash-5.0$ echo /tmp/a/b/* "/tmp/a/"b/* "/tmp/a/b"/* /tmp/a/b/c /tmp/a/b/c /tmp/a/b/* --Andrew Church http://achurch.org/
Re: Segfault after many stackframes
>This recursive function causes bash to segfault:
>
>$ re() { t=$((t+1)); if [[ $t -gt 800 ]]; then echo foo; return;
>fi; re; }; re
>Segmentation fault (core dumped)
>
>Ideally Bash ought to run out of memory before this fails. But an
>acceptable solution could also be to say 'stack overflow'.
That's exactly what bash is saying there. I'm not sure what (if
anything) POSIX specifies for stack overflow behavior, but at least on
Linux, stack overflow raises SIGSEGV:
$ echo 'int main(void) {return main();}' | cc -o foo -x c -
$ ./foo
Segmentation fault
--Andrew Church
http://achurch.org/
Re: Valgrind detects invalid read in bash. malloc assertion fails.
>> I assume this is a valgrind false positive. > >That possible. However, the assertion that causes the abort, is part of >the malloc.c version (line 934) that ships with bash. I guess that the >issue is caused by the fact that bash uses it's own malloc.c, which >seems to be incompatible with valgrind. The immediate cause of this error (which is indeed a false positive) is that Valgrind replaces calls to functions named "malloc" and "free" with its own memory management functions, but Bash's "free" (from lib/malloc/malloc.c) is renamed to "sh_xfree" by xmalloc.h. So memory allocations from Bash call Valgrind's malloc(), then eventually pass that pointer to Bash's custom free(), which naturally gets confused because the pointer wasn't returned from the custom malloc() in the same file. That said, defining an externally visible function named malloc() causes undefined behavior according to my reading of C99 7.1.3: "All identifiers with external linkage in any of the following subclauses [...] are always reserved for use as identifiers with external linkage. [...] If a program declares or defines an identifier in a context in which it is reserved (other than as allowed by 7.1.4), or defines a reserved identifier as a macro name, the behavior is undefined." So an argument could be made that Bash should rename its malloc() and realloc() similarly to free(), which would also avoid this false positive. (Strictly speaking, even the renaming of "free" to "sh_xfree" in xmalloc.h results in undefined behavior by the above rule, but that at least is resolved at compilation time, and I presume there are no real-world build environments in which that renaming causes a problem.) --Andrew Church http://achurch.org/
Re: Use high bits of the raw random number?
>> It seems that the high bits should be more random. If so, maybe the >> high 16 bits should be kept if $RANDOM must stay in 16bits? > >This seems like something you could test and verify. This aroused my curiosity, so I passed the generator's output through dieharder (https://webhome.phy.duke.edu/~rgb/General/dieharder.php). The low 16 bits do indeed have a bit of nonrandomness: rgb_minimum_distance| 3| 1|1000|0.| FAILED rgb_minimum_distance| 4| 1|1000|0.| FAILED rgb_minimum_distance| 5| 1|1000|0.| FAILED But the high 16 bits are much _less_ random: diehard_birthdays| 0| 100| 100|0.| FAILED diehard_rank_32x32| 0| 4| 100|0.| FAILED diehard_bitstream| 0| 2097152| 100|0.| FAILED diehard_opso| 0| 2097152| 100|0.| FAILED diehard_oqso| 0| 2097152| 100|0.| FAILED (and 84 other failures) XORing the two halves together seems to produce the best randomness, with no test failures reported. I've included the test results below for reference (the "Seed" in the output is from dieharder and is irrelevant -- the generator was seeded with the value 1 in all cases). --Andrew Church http://achurch.org/ $ bashrand-low16 | dieharder -a -g 200 # rseed & 65535 #=# #dieharder version 3.31.1 Copyright 2003 Robert G. Brown # #=# rng_name|rands/second| Seed | stdin_input_raw| 4.08e+07 |2254089738| #=# test_name |ntup| tsamples |psamples| p-value |Assessment #=# diehard_birthdays| 0| 100| 100|0.95827671| PASSED diehard_operm5| 0| 100| 100|0.32031682| PASSED diehard_rank_32x32| 0| 4| 100|0.14383292| PASSED diehard_rank_6x8| 0|10| 100|0.43645297| PASSED diehard_bitstream| 0| 2097152| 100|0.53672081| PASSED diehard_opso| 0| 2097152| 100|0.02073757| PASSED diehard_oqso| 0| 2097152| 100|0.06693142| PASSED diehard_dna| 0| 2097152| 100|0.12452962| PASSED diehard_count_1s_str| 0|256000| 100|0.07437349| PASSED diehard_count_1s_byt| 0|256000| 100|0.28505260| PASSED diehard_parking_lot| 0| 12000| 100|0.95056725| PASSED diehard_2dsphere| 2| 8000| 100|0.97831764| PASSED diehard_3dsphere| 3| 4000| 100|0.05092918| PASSED diehard_squeeze| 0|10| 100|0.62056331| PASSED diehard_sums| 0| 100| 100|0.13585606| PASSED diehard_runs| 0|10| 100|0.09497555| PASSED diehard_runs| 0|10| 100|0.66208887| PASSED diehard_craps| 0|20| 100|0.62090323| PASSED diehard_craps| 0|20| 100|0.90228045| PASSED marsaglia_tsang_gcd| 0| 1000| 100|0.99721756| WEAK marsaglia_tsang_gcd| 0| 1000| 100|0.04085373| PASSED sts_monobit| 1|10| 100|0.12541846| PASSED sts_runs| 2|10| 100|0.31563031| PASSED sts_serial| 1|10| 100|0.59231033| PASSED sts_serial| 2|10| 100|0.22297535| PASSED sts_serial| 3|10| 100|0.77971916| PASSED sts_serial| 3|10| 100|0.12037515| PASSED sts_serial| 4|10| 100|0.12317986| PASSED sts_serial| 4|10| 100|0.72452287| PASSED sts_serial| 5|10| 100|0.90854869| PASSED sts_serial| 5|10| 100|0.44245897| PASSED sts_serial| 6|10| 100|0.82961023| PASSED sts_serial| 6|10| 100|0.88326480| PASSED sts_serial| 7|10| 100|0.39221601| PASSED sts_serial| 7|10| 100|0.63007030| PASSED sts_serial| 8|10| 100|0.42190640| PASSED sts_serial| 8|10| 100|0.52501513| PASSED sts_serial| 9|10| 100|0.06836624| PASSED sts_serial| 9|10| 100|0.14296985| PASSED sts_serial| 10|10| 100|0.00882735| PASSED sts_serial| 10|10| 100|0.38520567| PASSED sts_serial| 11|10| 100|0.16565879| PASSED sts_serial| 11|10| 100|0.86672875| PASSED sts_serial| 12|10| 100|
Re: bash sets O_NONBLOCK on pts
>Well, it's not so uncommon, I had it a few times. Reading on internet
>it seems that other users have it but don't notice it.
The fault could be in some other program accessing the terminal. Bash
does not clear O_NONBLOCK on displaying a prompt, so if a previously
executed program sets O_NONBLOCK on stdin and then exits, that state
will remain until some other program unsets it. For example:
$ cat >foo.c
#include
int main(void) {fcntl(0, F_SETFL, O_NONBLOCK); return 0;}
^D
$ cc foo.c
$ ./a.out
$ cat
cat: -: Resource temporarily unavailable
--Andrew Church
http://achurch.org/
Re: Writing to /dev/stderr overwrites xtrace data
>I enabled xtrace to try and debug a bash script running on a validation >server. The script stored its stdout and stderr to a log file. I expected >to see trace data in the log file, but instead found a single log > statement, >a bunch of NULL bytes, and the line '+ exit 1'. This is expected behavior given the your example script. >echo "#!/usr/bin/env bash" > script.sh >echo "set -o xtrace" >> script.sh >echo "echo to_stderr > /dev/stderr" >> script.sh This command causes the shell to open a new file descriptor for /dev/stderr with the O_TRUNCATE flag, truncating the file to empty. >chmod 755 script.sh >./script.sh 2> stderr_output Since the script is run with stderr redirected to a file, /dev/stderr is a symbolic link to that file: $ (stat -c%N /dev/stderr /proc/self/fd/2) 2>/tmp/stderr_output '/dev/stderr' -> '/proc/self/fd/2' '/proc/self/fd/2' -> '/tmp/stderr_output' So the echo command in the generated script truncates the file "stderr_output" before writing "to_stderr\n", and you lose any xtrace log lines which were previously written. Bash still has an open file descriptor to stderr, which has its own seek position, so if you add another command (like "exit 1") to the generated script after the echo, the xtrace line generated by that command will be written at that position in the file, with the intervening space filled by null bytes. The solution is to use ">&2" rather than explicitly referencing /dev/stderr. --Andrew Church http://achurch.org/
Re: set -e ignored in subshell if part of command list
>"The -e setting shall be ignored when executing the compound list following
>the while, until, if, or elif reserved word, a pipeline beginning with the
>! reserved word, or any command of an AND-OR list other than the last."
>
>(from
>https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_25_03)
>
>The subshell inherits this state (being part of an and-or list) from its
>parent.
Is that really the intent of the requirement, though? The same section
states: "This requirement applies to the shell environment and each
subshell environment separately", which I read to mean that the rules
should be evaluated without consideration of any parent or subshell
environment other than the one in which the -e option is being applied.
And the example:
set -e; (false; echo one) | cat; echo two
shows rule 1 ("The failure of any individual command in a multi-command
pipeline shall not cause the shell to exit") not being applied within
the subshell, even though the subshell as a whole is an "individual
command in a multi-command pipeline". I don't see any suggestion that
the case of an AND-OR list in rule 2 should be treated differently, and
absent an explicit requirement one way or the other, I think the
expected behavior here would be that the behavior of the subshell is
independent of the subshell's context in the parent shell.
--Andrew Church
http://achurch.org/
Re: Backspace echoed incorrectly with TERM=garbage
>But I thought of 'strace'. I attached that to the Bash process and
>clearly saw it sending only space characters, no backspaces:
>
>pselect6(1, [0], NULL, NULL, NULL, {[], 8}) = 1 (in [0])
>read(0, "q", 1) = 1
>write(2, " ", 1)= 1
I can reproduce this behavior, using bash 4.4(23) and readline 7.0(5):
read(0, "\177", 1) = 1
write(2, " ", 1)= 1
I also have ncurses-6.2, with readline linking directly to libtinfo.
If I link readline against ncurses-5.9 (forcing -lncurses), the problem
goes away:
read(0, "\177", 1) = 1
write(2, "\10 \10", 3) = 3
So the problem may be either in ncurses itself or in readline's
interaction with ncurses/libtinfo.
--Andrew Church
http://achurch.org/
Bash parameter transforamtion on empty array triggers unset variable.
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-musl
Compiler: gcc
Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security
uname output: Linux 28e237a5e16f 5.5.7-200.fc31.x86_64 #1 SMP Fri Feb 28
17:18:37 UTC 2020 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-musl
Bash Version: 5.1
Patch Level: 0
Release Status: alpha
Description:
I do not know if this is related to bash 5.1 erroneously being
"a little aggressive about skipping over empty strings" mentioned
in "Declaring arrays with empty string in one line is bugged", but using
parameter transformation on an empty array, throws an error if "set -u" is
turned on. This was not how bash 4.4 and 5.0 worked. This bug makes it
impossible to check if an empty variable is an array using parameter
transformation while "set -u" is turned on
Repeat-By:
# Indirection
docker run -it --rm bash:5.1-alpha bash -uc 'foo(){ echo "${!1@a}";
}; bar=(); foo bar'
# Empty array
docker run -it --rm bash:5.1-alpha bash -uc 'bar=(); echo "${bar@a}"'
# Declared unset array
docker run -it --rm bash:5.1-alpha bash -uc 'declare -a bar; echo
"${bar@a}"'
# Empty associative array
docker run -it --rm bash:5.1-alpha bash -uc 'declare -A Bar=();
echo "${Bar@a}"'
# Declared unset associative array
docker run -it --rm bash:5.1-alpha bash -uc 'declare -A Bar; echo
"${Bar@a}"'
# I also tested on bash:devel-20200805, with the same results
Fix:
# All five of the above examples work in bash 4.4 and 5.0, and I
would expect the same behavior in bash 5.1
# Expected behavior that is already there in 5.1 alpha
docker run -it --rm bash:5.1-alpha bash -uc 'bar=(); echo
"${bar[@]}' # succeeds, but this is already consistent with bash 4.4 and
5.0. So this is expected to succeed.
docker run -it --rm bash:5.1-alpha bash -uc 'bar=(); echo
"${bar[@]+set}' # echos nothing, but this is already consistent with bash
3.2 and 5.0. So this is expected behavior
docker run -it --rm bash:5.1-alpha bash -uc 'bar=(); echo "${bar}'
# fails, but this is already consistent with bash 4.4 and 5.0. So this is
expected to fail, there is no 0th element to the array.
docker run -it --rm bash:5.1-alpha bash -uc 'bar=(); echo
"${bar+set}' # echos nothing, but this is already consistent with bash 3.2
and 5.0. So this is expected behavior
Thanks
Re: Bash parameter transforamtion on empty array triggers unset variable.
Ah, I see the confusion.
The issue you pointed out, "@Q breaks set -o nounset" refers to quote
parameter expansion, as does the line in CHANGES-5.1, 1.q, which makes
sense to call this a bug that was allowed in bash 4.4 and 5.0.
I should have specified, the focus of this issue is the "@a" expansion. It
makes sense that @Q/E/P/A expansion should not work on unset variables with
nounset enabled. However, @a is uniquely different, in that it does not
have to do with the value of the variable, but rather the variable type. My
"set -eu" compatible library uses the @a expansion (for bash 4.4 and newer)
because it had previously worked on unset values with set -u enabled, which
was a very useful feature.
Here are 3 specific details I would like to address:
1. @a expansion should work on unset variables with "set -u" in bash 5.1.
It seems like the correct thing to do. Only @a expansion. This has been a
very useful feature in bash 4.4 and 5.0.
Should fail: (set -eu; declare -a x; echo "${x@Q}")
Should not fail: (set -eu; declare -a x; echo "${x@a}")
2. With "set -u", the following works in bash 4.4 or newer (and makes sense
that it works): (set -eu; x=(); echo "${x[@]}")
Here x is not unset, it is set to an empty array. This expansion make sense
with nounset turned on because x is not unset, it is set to ()
However, this fails: (set -eu; x=(); echo "${x@a}")
This is an inconsistent behavior, and it seems to me the ${x@a} should
definitely work here, with nounset turns on
3. The same as #2, but for associative arrays
Works: (set -eu; declare -A x=(); echo "${x[@]}")
Does not work, but should: (set -eu; declare -A x=(); echo "${x@a}")
Thanks
On Tue, Aug 11, 2020 at 9:51 AM Chet Ramey wrote:
> On 8/10/20 5:52 PM, Andrew Neff wrote:
>
> > Bash Version: 5.1
> > Patch Level: 0
> > Release Status: alpha
> >
> > Description:
> > I do not know if this is related to bash 5.1 erroneously being
> > "a little aggressive about skipping over empty strings" mentioned
> > in "Declaring arrays with empty string in one line is bugged", but using
> > parameter transformation on an empty array, throws an error if "set -u"
> is
> > turned on. This was not how bash 4.4 and 5.0 worked. This bug makes it
> > impossible to check if an empty variable is an array using parameter
> > transformation while "set -u" is turned on
>
> This was a bug in bash-5.0 (and 4.4) and was fixed in early March 2019 as
> the result of
>
> https://lists.gnu.org/archive/html/bug-bash/2019-03/msg00010.html
>
> It's in CHANGES.
>
> There are some other changes in how bash displays attributes of unset
> variables when `nounset' is not enabled, but unset variables used in word
> expansions should trigger an error -- with the usual @/* exceptions -- when
> set -u is enabled.
>
> --
> ``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/
>
bind command dies on bad syntax
Configuration Information [Automatically generated, do not change]: Machine: i586 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i586' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i586-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../. -I.././include -I.././lib -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall uname output: Linux sc-physb05 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt11-1+deb8u5 (2015-10-09) i686 GNU/Linux Machine Type: i586-pc-linux-gnu Bash Version: 4.3 Patch Level: 30 Release Status: release Description: When I put an extra space in the bind command, it fails silently and corrupts the keyboard map. Lower-case h no longer works. Repeat-By: bind Control-a: forward-search-history
improper bashrc sourcing with closed stdin
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
-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'
uname output: Linux localhost 4.4.1-2-ARCH #1 SMP PREEMPT Wed Feb 3 13:12:33
UTC 2016 x86_64 GNU/Linux
Machine Type: x86_64-unknown-linux-gnu
Bash Version: 4.3
Patch Level: 42
Release Status: release
Description:
If run non-interactively with stdin closed and SHLVL=0, bash will
source ~/.bashrc, due to run_startup_files() thinking that bash is
being run by rshd.
Repeat-By:
#include
#include
void main(void) {
close(0);
setenv("SHLVL", "0", 1);
execl("/bin/bash", "/bin/bash", "-c", "echo foo", NULL);
}
Fix:
It looks like isnetconn needs to be modified to not count an fd
that returns EBADF as a socket:
diff --git a/lib/sh/netconn.c b/lib/sh/netconn.c
index 36e5bf5..f4ffe6c 100644
--- a/lib/sh/netconn.c
+++ b/lib/sh/netconn.c
@@ -52,7 +52,7 @@ isnetconn (fd)
l = sizeof(sa);
rv = getpeername(fd, &sa, &l);
/* Posix.2 says getpeername can return these errors. */
- return ((rv < 0 && (errno == ENOTSOCK || errno == ENOTCONN || errno ==
EINVAL)) ? 0 : 1);
+ return ((rv < 0 && (errno == ENOTSOCK || errno == ENOTCONN || errno ==
EINVAL || errno == EBADF)) ? 0 : 1);
#else /* !HAVE_GETPEERNAME || SVR4_2 || __BEOS__ */
# if defined (SVR4) || defined (SVR4_2)
/* Sockets on SVR4 and SVR4.2 are character special (streams) devices. */
bash 4.4: `configure --enable-static-link --without-gnu-malloc` fails with `No rule to make target 'install-'`
When I try to configure and make install bash 4.4 as follows: $ configure --enable-static-link --without-gnu-malloc $ make install I get: ( cd examples/loadables && make DESTDIR= install ) make[1]: Entering directory '/tmp/tmp.I41FEP4JeE/build/examples/loadables' make[1]: *** No rule to make target 'install-', needed by 'install'. Stop. If I: $ cd examples/loadables $ make install I get: make[1]: *** No rule to make target 'install-', needed by 'install'. Stop. When I inspect the Makefile in examples/loadables/Makefile I see: install:install-$(SHOBJ_STATUS) I assume what is causing this is that $(SHOBJ_STATUS) is empty, and neither set to "supported" nor "unsupported". It isn't clear which is the correct value given my configure options, or what is causing SHOBJ_STATUS to be empty at this point in the build. Any ideas? Thanks, Andrew.
Re: bash 4.4: `configure --enable-static-link --without-gnu-malloc` fails with `No rule to make target 'install-'`
On Mon, Oct 3, 2016 at 10:57 AM, Chet Ramey wrote: > On 10/3/16 10:01 AM, Chet Ramey wrote: > > On 10/2/16 6:54 PM, Andrew Tomazos wrote: > >> When I try to configure and make install bash 4.4 as follows: > >> > >> $ configure --enable-static-link --without-gnu-malloc > >> $ make install > > > > What happens if you run `make install SHOBJ_STATUS=unsupported'? Does > > that at least complete successfully? Then I can see why it's not > > defaulting to `unsupported'. > > Try this patch (and rebuild configure using `autoconf') to force the > default to unsupported if we're not going to use dynamic loading. > > I have tested your patch and it works successfully. (Last night I worked around by hacking the Makefile, see the patch at the end of: http://stackoverflow.com/q/39822816/1131467 ) Let me know if you need anything else from me.
arithmetic problem, incorrect return code with ((var++)) when var is 0 before operation
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-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I../. -I.././include -I.././lib
-Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -Wall
uname output: Linux andrewm-Satellite-P50-A 4.4.0-72-generic #93-Ubuntu
SMP Fri Mar 31 14:07:41 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.3
Patch Level: 42
Release Status: release
Description:
The return code from ((i++)) operation is different when i has an
initial value of 0.
This problem was discovered when running run a bash script with "set
-ue" and having "((i++))" as the last command in a loop.
Repeat-By:
The following script will quit with an error after the first iteration
due to the return code errantly being 1.
#!/bin/bash
set -eu
i=0
for a in a b c
do
echo "${a}"
((i++))
done
NB: If i starts as 1, the script works as expected.
Also, using ((i+=1)) works fine, but I prefer the ((i++)) format.
Proof outside a loop:
$ c=0;((c++));echo $?
1
$ c=1;((c++));echo $?
0
doc-strings of the 'command' built-in, as output by help
When running 'help command' in the shell, the output contains: > -vprint a description of COMMAND similar to the `type' builtin > -Vprint a more verbose description of each COMMAND This seems to be opposite to the actual behaviour of 'command', in which '-V' (capital V) produces output similar to 'type'. The text within the Bash man-page appears to be correct. Other info: - version number and release status of Bash: 5.2.32(1)-release (x86_64-pc-linux-gnu) - The machine and OS that it is running on: Debian trixie (testing) container running under LXD on ChromeOS Best, Andrew -- Andrew D. Davis, PhD PGP Key <https://www.openpgp.org/about>: 0xC1665F6A
Re: doc-strings of the 'command' built-in, as output by help
On Mon, Nov 25, 2024 at 9:04 PM Martin D Kealey
wrote:
>
> For both ‘command -v’ and ‘command -V’, there are no combinations of
> options for ‘type’ that will produce the same output in all cases.
>
For executables, aliases, functions, built-ins, and keywords, the output of
`command -V` (capital V) is identical to the output of `type` (with no
flags). To wit:
foo() { echo hi; }
alias bar=foo
for c in foo bar bash echo for
do
a=$( command -V "$c" )
b=$( type "$c" )
[[ $a == $b ]] && echo same || echo nope
done
#same
#same
#same
#same
#same
To be clear, I have no problem with the behaviour of 'command' itself. My
report was only meant to file a bug against the doc-strings output by 'help
command'. Maybe I could suggest a starting point for a fix, using the
language from the standard linked earlier, and the output of 'help type':
> -vFor each COMMAND, print a string to indicate how it would be
interpreted by the shell. The command word is printed for shell functions,
built-ins, and keywords, while a pathname is printed for executables found
in PATH. Aliases are printed with their definition.
>
> -VFor each COMMAND, print a more verbose description of how it would
be interpreted if used as a command name, similar to the 'type' built-in.
- Andrew
bash-source closes file descriptor before reading from it on Darwin
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: darwin12.4.0 Compiler: cc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='darwin12.4.0' -DCONF_MACHTYPE='i386-apple-darwin12.4.0' -DCONF_VENDOR='apple' -DLOCALEDIR='/usr/local/Cellar/bash/4.2.45/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -DMACOSX -I. -I. -I./include -I./lib -I./lib/intl -I/private/tmp/bash-NnFr/bash-4.2/lib/intl -g -O2 uname output: Darwin Andrews-MacBook-Air.local 12.4.0 Darwin Kernel Version 12.4.0: Wed May 1 17:57:12 PDT 2013; root:xnu-2050.24.15~1/RELEASE_X86_64 x86_64 Machine Type: i386-apple-darwin12.4.0 Bash Version: 4.2 Patch Level: 45 Release Status: release Description: When using source with process substitution, where the command writes to stdout, source closes the file descriptor created by the process substitution before reading from it. AFAIK this only occurs on Darwin. This impacts bash-completion used by npm and node-tabtab. https://github.com/isaacs/npm/blob/master/lib/completion.js#L163 Repeat-By: Create a script or executable that writes another script to stdout. Execute that command like so... source <(my_command) ... then check if the script written to stdout was actually sourced.
Re: Bash 2.05a isn't calling gawk as expected
On Tue, Nov 06, 2007 at 04:30:20PM -0500, [EMAIL PROTECTED] wrote:
> #!/bin/sh
>
> blockflag=/ihome/tables/modemhog.txt
> pageflag=/ihome/tables/modemhog.page
>
> [ -s $blockflag ] && exit
>
> for i in /home/*
> do
> [ -d $i ] || continue
> cd $i
>
> [ -f session_log ] || continue
>
> tail session_log |
> gawk -v Username=`basename $i` -v TodayDate=`date '+%b %e'` \
> -v CurrentYear=`date '+%Y'` -v BlockFlag=$blockflag \
> '$0 ~ /[Uu]ser/ && $0 !~ Username && $0 ~ TodayDate \
> && $0 ~ CurrentYear \
> {print Username, $0 >> BlockFlag}'
Two comments:
1. I think you need to say "cd .." here to return to the top-level
directory so that your next call to "cd" has a chance to succeed.
2. You should enclose the -v arguments to gawk in quotes. Like this:
gawk -v "Username=`basename $i`" -v "TodayDate=`date '+%b %e'`" ...
Otherwise, any spaces in those values will confuse gawk.
For example:
bash-3.1$ gawk -v "TodayDate=`date '+%b %e'`" 'BEGIN {print TodayDate}'
Nov 7
bash-3.1$ gawk -v TodayDate=`date '+%b %e'` 'BEGIN {print TodayDate}'
gawk: cmd. line:1: fatal: cannot open file `BEGIN {print TodayDate}' for
reading (No such file or directory)
Regards,
Andy
Re: Unfortunate error message for invalid executable
I’ll give it a shot. A. > On May 28, 2022, at 4:35 PM, Dale R. Worley wrote: > > AA via Bug reports for the GNU Bourne Again SHell > writes: >> I.e., something like "I'm not sure what's going on, but your path >> definitely exists, yet the kernel says otherwise." >> >> ... something like fprintf(STDERR,"No such file or directory while >> attempting to execute %s (it exists, but cannot be executed)",path); > > Historically, the way to get something like this to happen is to design > and code the modification that does it. That has the advantage that you > have to bite the bullet and instead of just describing the general idea, > decide on a concrete implementation. That sounds obvious, but there is > a long history of ideas in software that *sound good* but for which > there is no implementation that sucks less than the problem the idea > seeks to solve. > > Dale
Re: Unfortunate error message for invalid executable
Awesome (I made no claims of expertise about the details of the call semantics). I agree any multi-call scenario would among other things not be atomic. Though, I’m not sure that’s what you mean by hoodwinked. That last suggestion is exactly one I also made (simply improve the error text) and I completely agree would suffice if there isn’t a technical solution to disambiguate the actual error condition. My nezt step was going to be to find the source, and check where the string is generated or looked ip. A. > On May 29, 2022, at 4:34 AM, Martin D Kealey wrote: > > > > >> On Sun, 29 May 2022, 06:56 AA via Bug reports for the GNU Bourne Again >> SHell, wrote: >> Maybe the concern is that any additional calls (such as checking for path >> existence) may have unintended consequences [but that] seems unlikely. >> >> Therefore, IMHO it is very hard to argue with the fact that the file passed >> to the kernel does in fact exist > > > Actually it's quite easy to argue with that: a race condition between when > execve fails and when we subsequently check whether the file exists means we > could be hoodwinked into reporting the wrong error message in both directions. > > Either use fexecve (where it exists) to be CERTAIN that the file exists > before invoking it, or simply adjust the wording of the error message to make > the ambiguity clear. > > Then again, "file (or its interpreter) does not exist" would cover both cases > without needing to check separately whether the file exists. > > -Martin
caller returns wrong line number in command substitution
Machine: x86_64
OS: linux-musl
Compiler: gcc
Compilation CFLAGS: -g -O2
uname output: Linux cfa1574b05c7 5.10.102.1-microsoft-standard-WSL2 #1 SMP Wed
Mar 2 00:30:59 UTC 2022 x86_64 GNU/Linux
uname output: Linux 3beae0f31cdf 5.18.18-100.fc35.x86_64 #1 SMP PREEMPT_DYNAMIC
Wed Aug 17 16:09:22 UTC 2022 x86_64 Linux
Machine Type: x86_64-pc-linux-musl
Docker: docker run -it --rm bash:5.2
Description:
Using the "caller" command on a line of bash code in a process substitution
has been incorrect from bash 3.2 through 5.1, but I could write my code in such
a way to work around it. Some of these workarounds no longer function in bash
5.2. I saw that you made some changes to this code [see below], however, I
think they introduced another regression to how caller calculates the line
offset. In the following tests, caller should always return the last line in a
multi-line bash call, but that is not the case now in a process substitution in
bash 5.2 (test 5)
[quote]
c. Rewrote the command substitution parsing code to call the parser
recursively and rebuild the command string from the parsed command. This allows
better syntax checking and catches errors much earlier. Along with this, if
command substitution parsing completes with here-documents remaining to be
read, the shell prints a warning message and reads the here-document bodies
from the current input stream
Repeat-By:
Here's a small script to repeat the problem:
#!/usr/bin/env bash
function foobar()
{
caller >&2
}
foobar "test0
...
bar"
true <(foobar "test1
...
bar")
true <(
foobar "test2
...
bar")
true <(\
foobar "test3
...
bar")
read -rd '' foo < <(foobar "test4
...
bar") || :
read -rd '' foo < <(
foobar "test5
...
bar") || :
read -rd '' foo < <(\
foobar "test6
...
bar")
read -rd '' foo < \
<(foobar "test7
...
bar")
Results:
Test Ans 5.1 5.2
08 8 8
111 13 13
215 18 17
319 21 21
422 22 22
526 26 25
630 29 29
734 33 33
Summary:
Test 0: no command substitution, it works.
Test 1: the answer is off by the number of lines. So 1 line is right, 2 lines
if off by one line, 3 lines (as show) is off by 2. If it was 10 lines, the
answer would be off by 9.
Test 2: Same offset as Test 1. On bash 3.2-5.1 off by one additional line
Test 3: Same as test 1
Test 4: Actually right
Test 5: Off by -1 lines in bash 5.2, right on bash 3.2-5.1
Test 6: Always off by -1 lines
Test 7: Same as Test 6
Fix/Workarounds:
Only the Test0 and Test4 consistently give the right answer. However for
readability and other reasons, I don't always want those syntaxes.
Re: caller returns wrong line number in command substitution
Oops, my mistake. Got some terms mixed up a little there. Yes, every time I command substitution, I meant process substitution. So that release note for "Rewrote the command substitution" most likely nothing to do with this. From: Robert Elz Sent: Tuesday, October 18, 2022 7:09 PM To: Andrew Neff Cc: bug-bash@gnu.org Subject: Re: caller returns wrong line number in command substitution There are no command substitutions in any of your examples. A command substitution is what you get with $( ) (or if you really like obsolete syntax for some reason, ``). What you're showing is process substitution. This has nothing to do with whether or not there is an issue here that's worth fixing however - but bash's management of line numbers has always been "close enough" rather than "accurate". kre
Exit trap changes return value of subshell for uncaught trap signals
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
uname output: Linux 5.10.102.1-microsoft-standard-WSL2 #1 SMP Wed Mar 2
00:30:59 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
uname output: Linux 17d50c74abf4 5.10.102.1-microsoft-standard-WSL2 #1 SMP Wed
Mar 2 00:30:59 UTC 2022 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu
Environment Bugged: docker run -it --rm bash:5.1
Environment Working: docker run -it --rm bash:5.0
Bash Version: 5.1
Patch Level: 12
Release Status: release
Description:
I discovered an inconsistent bug starting in bash 5.1.12. Setting the
EXIT trap in the grandparent of a subshell that exits via an unset trap signal
causes different return values. If the EXIT trap is unset, the subshell returns
128+signal number (e.g. 138 , for SIGUSR1 (10)). However when the EXIT trap is
set in the grandparent, the subshell returns 0 instead.
Repeat-By:
Run this code in bash 5.1.12 or newer. You’ll see “Error: 138” both
before and after the EXIT signal is set on the older bashes, but not on 5.1.12
or newer.
#!/usr/bin/env bash
set -eu
child_signal()
(
trap "echo you will not see this" USR1
(
kill -USR1 "${BASHPID}"
# echo "Uncomment this to mysteriously fix"
) || echo "Error: ${rv=${?}}"
[ "${rv-0}" != "0" ]
echo
)
echo "No exit trap"
child_signal
echo "Exit trap set"
trap 'echo atexiting...' EXIT
child_signal
echo "The end"
Observed Erroneous Result:
No exit trap
User defined signal 1
Error: 138
Exit trap set
atexiting...
Expected Result (e.g., as in 5.1.11):
No exit trap
User defined signal 1
Error: 138
Exit trap set
User defined signal 1
Error: 138
The end
atexiting...
Fix:
The bug started in the 5.1.12 patch, and it does not happen in 5.1.11.
The bug was still present in the 2022-10-15 devel branch. I am only able to
manifest it with the EXIT signal. I could not reproduce it with other signals
(e.g. “set -T” + the RETURN signal)
One workaround: uncomment the “Uncomment this to mysteriously fix” line
and the bug disappears.
