"printf -v foo bar" sets $? to 1
Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security uname output: Linux bomb20 5.4.0-80-generic #90-Ubuntu SMP Fri Jul 9 22:49:44 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.1 Patch Level: 4 Release Status: maint Description: The builtin "printf" command with the "-v" option works correctly, but it reports failure by setting $? to 1. The problem was introduced by this commit; I've confirmed that it doesn't occur with its immediate predecessor. commit a30f513fc4cd507e74de6f0d0006b289a017a0d0 Author: Chet Ramey Date: 2021-05-13 14:49:18 -0400 more changes to handle @ and * as associative array keys Repeat-By: if printf -v foo bar ; then echo OK ; else echo FAILED ; fi
cd with multiple arguments?
I'm not sure whether this is a bug (the documentation doesn't address this case), but it's at least mildly annoying. If you invoke the "cd" commands with extra arguments after the directory name, all the extra arguments are silently ignored. I noticed this when I accidentally typed a '/' when I meant to type ';' in a long command: ( cd /some/dir / execute some command ) rather than the intended: ( cd /some/dir ; execute some command ) and didn't get an error or warning message -- and of course the command wasn't executed. $ echo $BASH_VERSION 3.2.48(1)-release $ uname -a Linux kvetch 2.6.28-19-generic #64-Ubuntu SMP Wed Aug 18 20:55:57 UTC 2010 i686 GNU/Linux $ cat /etc/*release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=9.04 DISTRIB_CODENAME=jaunty DISTRIB_DESCRIPTION="Ubuntu 9.04" $ cd /tmp and all following arguments are silently ignored $ pwd /tmp $ dirs /tmp $ 3.2.48 is the version installed by Ubuntu. I see the same issue with bash version 4.1.0(1)-release (compiled from source on the same system). (For what it's worth, tcsh and ksh both give error messages.) -- Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"
Re: cd with multiple arguments?
Keith Thompson writes:
> I'm not sure whether this is a bug (the documentation doesn't address
> this case), but it's at least mildly annoying.
>
> If you invoke the "cd" commands with extra arguments after the directory
> name, all the extra arguments are silently ignored.
[description snipped]
"pushd", "popd", and "pwd" also silently ignore extra arguments.
("dirs" doesn't; it prints an error message.)
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Re: "gitk &" closes parent bash upon exit
"Illia Bobyr" writes: [...] > When I do "gitk &" upon gitk exit the parent bash process > terminates as well. > When I do "(gitk &)" it works fine. There does not seem to be any > crash dumps. But sometimes bash outputs "Logout" before it exits just > as if I would press ^D on prompt. I have tried putting "gitk &" call > into a script and adding traps for all possible signals but none seemed > to be fired. > You do not have to be in a directory that is a Git repository. I wonder how "set -o ignoreeof" in the parent shell would affect the behavior. -- Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"
Re: "gitk &" closes parent bash upon exit
Keith Thompson writes: > "Illia Bobyr" writes: > [...] >> When I do "gitk &" upon gitk exit the parent bash process >> terminates as well. >> When I do "(gitk &)" it works fine. There does not seem to be any >> crash dumps. But sometimes bash outputs "Logout" before it exits just >> as if I would press ^D on prompt. I have tried putting "gitk &" call >> into a script and adding traps for all possible signals but none seemed >> to be fired. >> You do not have to be in a directory that is a Git repository. > > I wonder how "set -o ignoreeof" in the parent shell would affect > the behavior. I don't see this behavior, either with or without "set -o ignoreeof". I see a pop-up error message: "Cannot find a git repository here"; when I click "OK" the message vanishes, gitk terminates, and the parent bash shell is undisturbed. Same thing whether bash is running under rxvt, xterm, or a Windows command window. $ cygcheck -c -d cygwin gitk bash Cygwin Package Information Package Version bash 3.2.49-23 cygwin 1.7.5-1 gitk 1.7.0.4-2 -- Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"
Documentation patch: Add "$" to description of special parameters
of commands
(@pxref{Shell Scripts}), @code{$0} is set to the name of that file.
@@ -1480,7 +1480,7 @@ then @code{$0} is set to the first argument
after the string to be
executed, if one is present. Otherwise, it is set
to the filename used to invoke Bash, as given by argument zero.
-@item _
+@item $_
(An underscore.)
At shell startup, set to the absolute pathname used to invoke the
shell or shell script being executed as passed in the environment
AND HERE
--
Keith Thompson
bash-special-parameters.patch
Description: Binary data
mapfile doesn't accept input from a pipe
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 bomb20 4.8.0-46-generic #49-Ubuntu SMP Fri Mar 31
13:57:14 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-unknown-linux-gnu
Bash Version: 4.4
Patch Level: 12
Release Status: maint
Description:
The "mapfile" command works correctly if stdin is redirected
from a file, but not if it's from a pipe.
Demonstrated with several versions including the latest
bash-snap-20170626
Repeat-By:
This script demonstrates the problem:
__CUT_HERE__
#!/bin/bash
printf 'one\ntwo\nthree\n' > /tmp/input.txt
mapfile REDIRECT < /tmp/input.txt
cat /tmp/input.txt | mapfile PIPE
echo "\$REDIRECT has ${#REDIRECT[@]} elements"
echo "\$PIPE has ${#PIPE[@]} elements"
if [ ${#REDIRECT[@]} -eq 3 ] && [ ${#PIPE[@]} -eq 3 ] ; then
echo PASS
exit 0
else
echo FAIL
exit 1
fi
__AND_HERE__
Typo in bash manual: "QUANTUMP"
In the documentation for the "mapfile" builtin command: '-C' Evaluate CALLBACK each time QUANTUMP lines are read. The '-c' option specifies QUANTUM. "QUANTUMP" should be "QUANTUM". In the latest sources cloned from git://git.savannah.gnu.org/bash.git, this occurs in: bash/doc/bash.info bash/doc/bashref.info
Re: mapfile doesn't accept input from a pipe
On Thu, Jun 29, 2017 at 6:56 AM, Eduardo A. Bustamante López wrote: > On Wed, Jun 28, 2017 at 07:08:27PM -0700, Keith Thompson wrote: > [...] >> mapfile REDIRECT < /tmp/input.txt >> cat /tmp/input.txt | mapfile PIPE > > The `mapfile PIPE' is a piece of a pipeline, and as such, it runs in a > subshell (different process). > > See: http://mywiki.wooledge.org/BashFAQ/024 OK, that makes sense, and of course the same thing applies to "read". I suggest that it would be worthwhile to mention this issue in the documentation. The fact that it's a FAQ suggests that people are likely to run into it.
"jobs" doesn't consistently expand function arguments
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
-fdebug-prefix-map=/build/bash-vEMnMR/bash-4.4.18=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall
-Wno-parentheses -Wno-format-security
uname output: Linux bomb20 4.15.0-24-generic #26-Ubuntu SMP Wed Jun 13
08:44:47 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.4
Patch Level: 19
Release Status: release
Description:
The "jobs" command doesn't consistently expand function arguments
Repeat-By:
For example:
/bin/bash --login --noprofile
bash-4.4$ nap() { sleep "$@" ; }
bash-4.4$ nap 1234
^Z
[1]+ Stopped sleep "$@"
bash-4.4$ bg
[1]+ sleep "$@" &
bash-4.4$ nap 2345 &
[2] 9666
bash-4.4$ jobs
[1]- Running sleep "$@" &
[2]+ Running nap 2345 &
bash-4.4$
The problem is the '"$@"' in the "jobs" output, which doesn't provide
any useful information.
This is on Ubuntu 18.04 LTS.
I've see the same problem with bash 5.0-alpha (built from source).
I'd prefer to see "sleep 1234" in the output of "jobs", though
"nap 1234" would also be ok.
A small documentation suggestion
Bash 5.0 adds $EPOCHSECONDS and $EPOCHREALTIME.
The latter expands, each time it's referenced, to the number of
seconds since the epoch with microsecond precision.
Experiment shows that the expansion always has exactly 6 digits after
the decimal point. For example, if you typed "echo $EPOCHREALTIME"
at just the right moment, it might print "1546925845.00", not
"1546925845.0" or "1546925845".
I suggest documenting this behavior. It would be nice to be able to
depend on the exact format, for example that ${EPOCHREALTIME/*./}
is always exactly 6 digits long.
(The number of digits before the decimal point won't change until 2286;
I'm not too worried about that.)
Proposed patch for doc/bashref.texi (please tweak this if needed):
diff --git doc/bashref.texi doc/bashref.texi
index d33cd571..6381c61a 100644
--- doc/bashref.texi
+++ doc/bashref.texi
@@ -5911,6 +5911,7 @@ Similar to @code{BASH_ENV}; used when the shell
is invoked in
@item EPOCHREALTIME
Each time this parameter is referenced, it expands to the number of seconds
since the Unix Epoch as a floating point value with micro-second granularity
+as if formatted using a @samp{"%.6f"} @code{printf} format
(see the documentation for the C library function @var{time} for the
definition of Epoch).
Assignments to @env{EPOCHREALTIME} are ignored.
@@ -5918,7 +5919,7 @@ If @env{EPOCHREALTIME} is unset, it loses its
special properties, even if
it is subsequently reset.
@item EPOCHSECONDS
-Each time this parameter is referenced, it expands to the number of seconds
+Each time this parameter is referenced, it expands to the integer
number of seconds
since the Unix Epoch (see the documentation for the C library function
@var{time} for the definition of Epoch).
Assignments to @env{EPOCHSECONDS} are ignored.
-- Keith Thompson
Re: A small documentation suggestion
Yes, you can do that, and it would be a good workaround *if*
$EPOCHREALTIME didn't already have 6 digits after the decimal point,
including any trailing zeros.
The point is that you don't have to, and I'm suggesting that the
documentation should make that clear so users can rely on it.
${EPOCHREALTIME: -6}
On Tue, Jan 8, 2019 at 2:13 AM Andreas Schwab wrote:
>
> On Jan 07 2019, Keith Thompson wrote:
>
> > I suggest documenting this behavior. It would be nice to be able to
> > depend on the exact format, for example that ${EPOCHREALTIME/*./}
> > is always exactly 6 digits long.
>
> ms=${EPOCHREALTIME/*./}00
> ms=${ms:0:6}
>
> Andreas.
>
> --
> Andreas Schwab, SUSE Labs, sch...@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."
builtin echo vs /bin/echo appears to affect variable scope
From: kst To: bug-bash@gnu.org Subject: echo vs /bin/echo appears to affect variable scope 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 bomb20 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.0 Patch Level: 16 Release Status: release Description: The original test case was a small script in this answer on Stack Overflow: https://stackoverflow.com/a/60480960/827263 I've narrowed it down to two scripts that differ only in using "echo" vs. "/bin/echo". With the built-in "echo", $i is correctly incremented. With the external "/bin/echo", $i appears to be 0 on each iteration. Moving the "((i++))" into a separate command also works around the bug. Repeat-By: (/o/bin/bash is a symlink to bash 5.0.16 on my system.) bad.bash: ``` #!/o/bin/bash rm -f BASH_BUG_TEST* i=0 printf '%s\n' should-be-0 should-be-1 should-be-2 | \ while read word ; do /bin/echo hello \ > BASH_BUG_TEST_$((i++))_$word done ls -1 BASH_BUG_TEST* rm -f BASH_BUG_TEST* ``` Output of bad.bash: ``` BASH_BUG_TEST_0_should-be-0 BASH_BUG_TEST_0_should-be-1 BASH_BUG_TEST_0_should-be-2 ``` good.bash: ``` #!/o/bin/bash rm -f BASH_BUG_TEST* i=0 printf '%s\n' should-be-0 should-be-1 should-be-2 | \ while read word ; do echo hello \ > BASH_BUG_TEST_$((i++))_$word done ls -1 BASH_BUG_TEST* rm -f BASH_BUG_TEST* ``` Output of good.bash: ``` BASH_BUG_TEST_0_should-be-0 BASH_BUG_TEST_1_should-be-1 BASH_BUG_TEST_2_should-be-2 ```
Seg fault on "echo ~nosuchuser"
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -Wno-parentheses -Wno-format-security uname output: Linux bomb20 5.4.0-31-generic #35-Ubuntu SMP Thu May 7 20:20:34 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.0 Patch Level: 16 Release Status: release Description: bash crashes with a segmentation fault on the command: echo ~nosuchuser (This assumes there is no user named "nosuchuser". If there is, pick a different name). It's likely this isn't a bug in bash itself, but I haven't been able to figure out what's going on. I see this problem on copies of bash 5.0.16 and 5.0.17 built from sourced on Ubuntu 20.04 LTS. It does *not* occur with the /bin/bash GNU bash, version 5.0.16(1)-release (x86_64-pc-linux-gnu) provided by the distribution. I haven't verified how far back this goes. I built another copy of bash 5.0.16 from source with "CFLAGS=-g". When I reproduce the seg fault under gdb, I got the following traceback: [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x7777eddb in ?? () from /lib/x86_64-linux-gnu/libnss_systemd.so.2 (gdb) where #0 0x7777eddb in ?? () from /lib/x86_64-linux-gnu/libnss_systemd.so.2 #1 0x777721c8 in ?? () from /lib/x86_64-linux-gnu/libnss_systemd.so.2 #2 0x77773009 in ?? () from /lib/x86_64-linux-gnu/libnss_systemd.so.2 #3 0x777883e7 in _nss_systemd_getpwnam_r () from /lib/x86_64-linux-gnu/libnss_systemd.so.2 #4 0x77e53f03 in __getpwnam_r (name=name@entry=0x55722368 "nosuchuser", resbuf=resbuf@entry=0x77f5e140 , buffer=0x55777808 "systemd-coredump", buflen=buflen@entry=1024, result=result@entry=0x7fffddb0) at ../nss/getXXbyYY_r.c:315 #5 0x77e537ec in getpwnam (name=0x55722368 "nosuchuser") at ../nss/getXXbyYY.c:134 #6 0x55663dc9 in tilde_expand_word (filename=0x5571dba8 "~nosuchuser") at ./tilde.c:386 #7 0x55663a73 in tilde_expand (string=0x5571d493 "") at ./tilde.c:234 #8 0x55598456 in bash_tilde_expand (s=0x5571d488 "~nosuchuser", assign_p=0) at general.c:1196 #9 0x555d773c in expand_word_internal (word=0x5571ffe8, quoted=0, isexp=0, contains_dollar_at=0x7fffe018, expanded_something=0x7fffe014) at subst.c:9963 #10 0x555daccd in shell_expand_word_list (tlist=0x5571d4e8, eflags=31) at subst.c:11339 #11 0x555db047 in expand_word_list_internal (list=0x55722448, eflags=31) at subst.c:11463 #12 0x555da09f in expand_words (list=0x55722448) at subst.c:10983 #13 0x555a5692 in execute_simple_command (simple_command=0x557225c8, pipe_in=-1, pipe_out=-1, async=0, fds_to_close=0x5571fd88) at execute_cmd.c:4323 #14 0x5559ee36 in execute_command_internal (command=0x55721288, asynchronous=0, pipe_in=-1, pipe_out=-1, fds_to_close=0x5571fd88) at execute_cmd.c:842 #15 0x5559e3bf in execute_command (command=0x55721288) at execute_cmd.c:394 #16 0x55586e21 in reader_loop () at eval.c:175 #17 0x555846cf in main (argc=1, argv=0x7fffe498, env=0x7fffe4a8) at shell.c:805 If I understand this correctly, it died in getpwnam(). The call appears to be valid; it should simply return a null pointer. Other tests indicate that getpwnam() works correctly. (Dereferencing the null pointer could of course cause a seg fault, but the application doesn't get a chance to do that.) Repeat-By: Given that there is no user account called "nosuchuser", either: echo ~nosuchuser or bash -c 'echo ~nosuchuser'
Re: Seg fault on "echo ~nosuchuser"
On Fri, May 29, 2020 at 11:40 AM Chet Ramey wrote: > > On 5/28/20 6:12 PM, Keith Thompson wrote: > > Configuration Information [Automatically generated, do not change]: > > Machine: x86_64 > > OS: linux-gnu > > Compiler: gcc > > Compilation CFLAGS: -g -Wno-parentheses -Wno-format-security > > uname output: Linux bomb20 5.4.0-31-generic #35-Ubuntu SMP Thu May 7 > > 20:20:34 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux > > Machine Type: x86_64-pc-linux-gnu > > > > Bash Version: 5.0 > > Patch Level: 16 > > Release Status: release > > > > Description: > > bash crashes with a segmentation fault on the command: > > echo ~nosuchuser > > (This assumes there is no user named "nosuchuser". If there > > is, pick a different name). > > > > It's likely this isn't a bug in bash itself, but I haven't > > been able to figure out what's going on. > > > > I see this problem on copies of bash 5.0.16 and 5.0.17 built from > > sourced on Ubuntu 20.04 LTS. It does *not* occur with the /bin/bash > > GNU bash, version 5.0.16(1)-release (x86_64-pc-linux-gnu) > > provided by the distribution. I haven't verified how far > > back this goes. > > Can you try this with the current devel branch head from savannah? I > have a suspicion about what's going on. > > http://git.savannah.gnu.org/cgit/bash.git/snapshot/bash-devel.tar.gz This did not reproduce the bug. $ ./bash --version GNU bash, version 5.1.0(1)-alpha (x86_64-pc-linux-gnu) Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. $ ./bash -c 'echo ~nosuchuser' ~nosuchuser $
Re: Seg fault on "echo ~nosuchuser"
On Mon, Jun 1, 2020 at 6:05 AM Chet Ramey wrote: > On 5/29/20 2:50 PM, Keith Thompson wrote: > > >> Can you try this with the current devel branch head from savannah? I > >> have a suspicion about what's going on. > >> > >> http://git.savannah.gnu.org/cgit/bash.git/snapshot/bash-devel.tar.gz > > > > This did not reproduce the bug. > > > > $ ./bash --version > > GNU bash, version 5.1.0(1)-alpha (x86_64-pc-linux-gnu) > > Copyright (C) 2020 Free Software Foundation, Inc. > > License GPLv3+: GNU GPL version 3 or later < > http://gnu.org/licenses/gpl.html> > > > > This is free software; you are free to change and redistribute it. > > There is NO WARRANTY, to the extent permitted by law. > > $ ./bash -c 'echo ~nosuchuser' > > ~nosuchuser > > $ > > OK, that's half of it. > > If you have a chance, can you verify that the problem exists with the > bash-20200520 push? > > > http://git.savannah.gnu.org/cgit/bash.git/snapshot/bash-ce1a3c07c4e17ed176edccd75892dfcf8242de60.tar.gz > > Confirmed, the problem does exist with that version.
Re: Seg fault on "echo ~nosuchuser"
On Mon, Jun 1, 2020 at 12:12 PM Chet Ramey wrote: > > On 6/1/20 3:04 PM, Keith Thompson wrote: > > > OK, that's half of it. > > > > If you have a chance, can you verify that the problem exists with the > > bash-20200520 push? > > > > > > http://git.savannah.gnu.org/cgit/bash.git/snapshot/bash-ce1a3c07c4e17ed176edccd75892dfcf8242de60.tar.gz > > > > > > Confirmed, the problem does exist with that version. > > I finally found a case where 16-byte alignment for memory returned by > malloc() is required. But it's only on Linux systems that use systemd. > I bet it's trying to marshal arguments for IPC and uses instructions > that require 16-byte alignment. > > Thanks for your help verifying this. > > Chet You probably already know this, but I tested this with the last few versions on the devel branch. The problem occurs on versions up to and including commit ce1a3c07c4e17ed176edccd75892dfcf8242de60 "bash-20200520 snapshot". The problem does not occur on commit 37adc8b99d4c15dcb9e6582aa19a2ef61afb592f "bash-20200527 snapshot". Yes, my system uses systemd. Glad I could help.
Incorrect "jobs" output after "trap ... ERR" command
I've discovered a bash bug that causes the "jobs" command to produce
incorrect output after an ERR trap has been defined and triggered.
I've seen it with bash 4.3.11(1)-release on Linux Mint 17 and bash
4.3.30(1)-release on Debian 6.
I have *not* seen it with 3.2.25(1)-release on CentOS 5.10.
The demonstration is interactive; you have to interrupt the "cat" command
by typing Control-C, and you have
to run the "jobs" command before the "sleep" commands expire.
$ bash --norc
bash-4.3$ echo $BASH_VERSION
4.3.11(1)-release
bash-4.3$ show_error() { echo ERROR ; }
bash-4.3$ trap show_error ERR
bash-4.3$ cat
^C
ERROR
bash-4.3$ sleep 60 &
[1] 32225
bash-4.3$ : && cat
^C
bash-4.3$ sleep 70 &
[2] 32229
bash-4.3$ jobs
[1]- Running sleep 60 &
[2]+ Running cat &
bash-4.3$ exit
$
Once the bug is triggered, "jobs" shows the command name for the command
("cat" in this case)
that triggered the problem rather than the actual name of the command.
Note also that the show_error() function was invoked when I interrupted the
"cat" command the first
time, but not the second time.
The original version of the "trap" command was:
show_error() { printf "\e[1mExit $?\e[m\n" ; }
trap show_error ERR
intended to mimic tcsh's $printexitvalue setting.
--
Keith Thompson
Bug in !! expansion, bash 4.4-beta
I'm running bash 4.4 beta, built from source (bash-4.4-beta.tar.gz) on Linux Mint 17.2. !! history expansion works correctly in simple cases, but not when part of a $(...) expansion. This problem does not occur with bash 4.3.11 The last error message shown occurred when I typed Esc Ctrl-E (shell-expand-line) after typing "echo $(!!". $ bash --norc bash-4.4$ echo $BASH_VERSION 4.4.0(1)-beta bash-4.4$ echo hello hello bash-4.4$ !! echo hello hello bash-4.4$ echo hello hello bash-4.4$ echo $(!!) bash: !!: command not found bash-4.4$ echo hello hello bash-4.4$ echo $(!!TRACE: pid 3822: xparse_dolparen:17: ep[-1] != RPAREN (33), ep = `' TRACE: pid 3822: xparse_dolparen:17: base[8] != RPAREN (33), base = `echo $(!!' -- Keith Thompson
Bug in bash 4.4-beta: suspending and restarting "man" program
I'm running bash 4.4-beta, built from bash-4.4-beta.tar.gz, on two different x86_64 systems, one running Debian 6.0.10 and another running Linux Mint 17.3. On both systems, if I run "man rm" (for example) I can read the "rm(1)" man page using "less" (my $MANPAGER is set to "less -s -r"). If I then type Ctrl-Z, the "man" and "pager" processes are suspended and the screen is restored its previous state. On the Debian system, I don't get a new shell prompt (this is the bug). The terminal continues to accept and echo input, but it's otherwise stuck. Ctrl-C and Ctrl-Z are echoed as "^C" and "^Z", but are otherwise ignored. I can recover by killing the "man" process from another window. On the Linux Mint system, this problem does not occur. Typing Ctrl-Z gives me a new shell prompt, and the "man rm" process shows up in the "jobs" listing. The problem does not occur on Debian 6 using /bin/bash (version 4.1.5). I don't see the problem when I invoke "less" or "vi" directly. I've seen the problem when I'm in an editor (vim) invoked from "git commit". So apparently it has something to do with a full-screen program invoked by some other program. Let me know if I can provide more information (Debian 6 is fairly old, so you might not have a running copy). -- Keith Thompson
Re: Bug in bash 4.4-beta: suspending and restarting "man" program
I've found another symptom of the problem. It has something to do with the handling of the TSTP signal (normally sent by typing Ctrl-Z). Running bash 4.4-beta, I type the "cat" command. While "cat" is running, I type Ctrl-Z. Normally this should suspend the "cat" process and give me a shell prompt, but nothing visible happens. Normally I can achieve the same effect by running "kill -TSTP PID", where PID is the process id of the "cat" process, from another terminal. This also does nothing. I *can* suspend the "cat" process by typing "kill -STOP PID" from another terminal. After doing that, I can restore it by typing "fg" at the bash prompt (but Ctrl-Z still doesn't work). This problem occurs with bash 4.4-beta on Debian 6.0.10. It does not occur with bash 4.4-beta on Linux Mint 17.2, or with bash 4.3.30 on Debian 6.0.10. On Wed, Oct 28, 2015 at 7:02 PM, Keith Thompson wrote: > I'm running bash 4.4-beta, built from bash-4.4-beta.tar.gz, on two > different x86_64 systems, one running Debian 6.0.10 and another running > Linux Mint 17.3. > > On both systems, if I run "man rm" (for example) I can read the "rm(1)" > man page using "less" (my $MANPAGER is set to "less -s -r"). If I then > type Ctrl-Z, the "man" and "pager" processes are suspended and the screen > is restored its previous state. > > On the Debian system, I don't get a new shell prompt (this is the > bug). The terminal continues to accept and echo input, but it's otherwise > stuck. Ctrl-C and Ctrl-Z are echoed as "^C" and "^Z", but are otherwise > ignored. I can recover by killing the "man" process from another window. > > On the Linux Mint system, this problem does not occur. Typing Ctrl-Z > gives me a new shell prompt, and the "man rm" process shows up in the > "jobs" listing. > > The problem does not occur on Debian 6 using /bin/bash (version 4.1.5). > > I don't see the problem when I invoke "less" or "vi" directly. I've > seen the problem when I'm in an editor (vim) invoked from "git commit". > So apparently it has something to do with a full-screen program invoked > by some other program. > > Let me know if I can provide more information (Debian 6 is fairly old, so > you might not have a running copy). > > -- > Keith Thompson > -- Keith Thompson
Re: Bug in bash 4.4-beta: suspending and restarting "man" program
"stty -a" on both systems prints: speed 38400 baud; rows 57; columns 237; line = 0; intr = ^C; quit = ^\; erase = ^H; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -ixon -ixoff -iuclc -ixany imaxbel -iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke (The Debian 6.0.10 version had "ignpar", but changing it to match the Linux Mint 17.2 system didn't change the behavior.) readline is included in bash-4.4-beta.tar.gz, so they're both using the same version. On both systems, I built bash using: ./configure --prefix=... make make install One possibly relevant observation: the output of "ldd" on the executables differs. On Debian 6.0.10, it's: $ ldd /usr/local/bin/bash linux-vdso.so.1 => (0x7ffe2e775000) *libncurses.so.5 => /lib/libncurses.so.5 (0x7f730c0ae000)* libdl.so.2 => /lib/libdl.so.2 (0x7f730beaa000) libc.so.6 => /lib/libc.so.6 (0x7f730bb4) /lib64/ld-linux-x86-64.so.2 (0x7f730c318000) On Linux Mint 17.2, it's: $ ldd /usr/local/bin/bash linux-vdso.so.1 => (0x7ffddfd8b000) *libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7fd51ce92000)* libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fd51cc8e000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fd51c8c8000) /lib64/ld-linux-x86-64.so.2 (0x7fd51d0e3000) But I see the same difference on /bin/bash (4.1.5 on the Debian system, 4.3.11 on the Linux Mint system). On Thu, Oct 29, 2015 at 5:31 PM, Mike Frysinger wrote: > what does `stty -a` show on the two systems ? > > what version of readline are you using on both ? > -mike > -- Keith Thompson
Re: Bug in bash 4.4-beta: suspending and restarting "man" program
I just tried it on a two VMs running Debian 6 and 7, respectively. The problem did not occur. It also doesn't occur on the original Debian 6 system if I run it as "bash --norc". (Sorry, I should have tried that in the first place.) So the problem has something to do with my own setup scripts. I'll investigate further and get back to you. On Fri, Oct 30, 2015 at 3:55 AM, Chet Ramey wrote: > On 10/28/15 10:02 PM, Keith Thompson wrote: > > I'm running bash 4.4-beta, built from bash-4.4-beta.tar.gz, on two > > different x86_64 systems, one running Debian 6.0.10 and another running > > Linux Mint 17.3. > > > > On both systems, if I run "man rm" (for example) I can read the "rm(1)" > > man page using "less" (my $MANPAGER is set to "less -s -r"). If I then > > type Ctrl-Z, the "man" and "pager" processes are suspended and the screen > > is restored its previous state. > > > > On the Debian system, I don't get a new shell prompt (this is the > > bug). The terminal continues to accept and echo input, but it's otherwise > > stuck. Ctrl-C and Ctrl-Z are echoed as "^C" and "^Z", but are otherwise > > ignored. I can recover by killing the "man" process from another window. > > I don't have a Debian 6 system, but I can't reproduce this on Debian 7. > > Chet > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, ITS, CWRUc...@case.edu > http://cnswww.cns.cwru.edu/~chet/ > -- Keith Thompson
Re: Bug in bash 4.4-beta: suspending and restarting "man" program
Whatever the problem is, it seems to be subtle. I can't *reliably* reproduce it on the original Debian 6 system. I saw the problem in a shell that had been running for a couple of weeks, with several thousand commands executed. Replacing the shell process with "exec bash -l" (using the same version of bash) did not fix the problem, but starting a new shell seems to have fixed it, at least for now. For a while, I had two running login shells, one that had the problem and one that didn't. Comparing the output of "set" and "shopt" from both shells didn't show any differences that could explain this. My best guess at this point is that some internal data structure was corrupted as a result of *something* that I did. I wish I could be more specific. I'll keep an eye on it, and let you know if I can come up with something more concrete. Any suggestions on more data I can gather if this happens again? I can try attaching strace and sending a copy of the log. On Fri, Oct 30, 2015 at 2:31 PM, Keith Thompson wrote: > I just tried it on a two VMs running Debian 6 and 7, respectively. > The problem did not occur. > > It also doesn't occur on the original Debian 6 system if I run it as "bash > --norc". > (Sorry, I should have tried that in the first place.) > > So the problem has something to do with my own setup scripts. > I'll investigate further and get back to you. > > On Fri, Oct 30, 2015 at 3:55 AM, Chet Ramey wrote: > >> On 10/28/15 10:02 PM, Keith Thompson wrote: >> > I'm running bash 4.4-beta, built from bash-4.4-beta.tar.gz, on two >> > different x86_64 systems, one running Debian 6.0.10 and another running >> > Linux Mint 17.3. >> > >> > On both systems, if I run "man rm" (for example) I can read the "rm(1)" >> > man page using "less" (my $MANPAGER is set to "less -s -r"). If I then >> > type Ctrl-Z, the "man" and "pager" processes are suspended and the >> screen >> > is restored its previous state. >> > >> > On the Debian system, I don't get a new shell prompt (this is the >> > bug). The terminal continues to accept and echo input, but it's >> otherwise >> > stuck. Ctrl-C and Ctrl-Z are echoed as "^C" and "^Z", but are otherwise >> > ignored. I can recover by killing the "man" process from another >> window. >> >> I don't have a Debian 6 system, but I can't reproduce this on Debian 7. >> >> Chet >> >> -- >> ``The lyf so short, the craft so long to lerne.'' - Chaucer >> ``Ars longa, vita brevis'' - Hippocrates >> Chet Ramey, ITS, CWRUc...@case.edu >> http://cnswww.cns.cwru.edu/~chet/ >> > > > > -- > Keith Thompson > -- Keith Thompson
Re: Bug in bash 4.4-beta: suspending and restarting "man" program
$ trap
trap -- 'show_error' ERR
$ type show_error
show_error is a function
show_error ()
{
printf "\e[1mExit $?\e[m\n" 1>&2
}
$
On Sat, Oct 31, 2015 at 12:00 AM, Andreas Schwab
wrote:
> Keith Thompson writes:
>
> > For a while, I had two running login shells, one that had the problem
> > and one that didn't. Comparing the output of "set" and "shopt" from
> > both shells didn't show any differences that could explain this.
>
> What's the output of trap?
>
> Andreas.
>
> --
> Andreas Schwab, sch...@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
>
--
Keith Thompson
shell-expand-line drops quotation marks
The shell-expand-line command (bound to Escape-Ctrl-E) incorrectly removes
quotation marks from
the command line, often resulting in a command that differs from what the
user intended to type.
I've seem this problem with all recent versions of bash, particularly
4.3.11 (preinstalled on
Linux Mint 17.2) and 4.4-beta (built from source on the same system).
Here's a demonstration:
$ /bin/bash --norc
bash-4.3$ uname -a
Linux bomb20 3.16.0-38-generic #52~14.04.1-Ubuntu SMP Fri May 8 09:43:57
UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
bash-4.3$ echo $BASH_VERSION
4.3.11(1)-release
bash-4.3$ bind -p | grep shell-expand-line
"\e\C-e": shell-expand-line
bash-4.3$ echol() { for word in "$@" ; do echo "$word" ; done ; }
bash-4.3$ echo foo bar
foo bar
bash-4.3$ echol 'string with spaces' !* *# Here I typed just the
command you see; it worked.*
echol 'string with spaces' foo bar
string with spaces
foo
bar
bash-4.3$ echo foo bar
foo bar
bash-4.3$ echol string with spaces foo bar *# Here I typed the same
command, then Escape-Ctrl-E*
string
with
spaces
foo
bar
bash-4.3$
I often type Escape-Ctrl-E to expand a history substitution in place
before typing Enter, but it has the side effect of stripping quotes from
what I've already typed.
--
Keith Thompson
Re: shell-expand-line drops quotation marks
Thanks, I didn't know about history-expand-line. Is there some case where shell-expand-line would actually be useful? If I've typed *"foo bar"*, I can't think of any case where I'd *want* it to be replaced by *foo bar*, which has a very different meaning. Of course the obvious answer is not to use it, but I'm wondering why it's there. I might just rearrange my key bindings so shell-expand-line is never invoked (Escape-^ is just a little bit too awkward to type, and my fingers are trained to type Escape-Ctrl-E). I guess I won't suggest any change to bash, since it breaking existing documented behavior is A Bad Thing. (BTW, I've been using different fonts and *bold* for emphasis. Let me know if that's a problem and you'd prefer just plain text on this list.) On Wed, Nov 4, 2015 at 6:45 AM, Pádraig Brady wrote: > On 04/11/15 13:47, Chet Ramey wrote: > > On 11/3/15 7:44 PM, Keith Thompson wrote: > >> The shell-expand-line command (bound to Escape-Ctrl-E) incorrectly > removes > >> quotation marks from > >> the command line, often resulting in a command that differs from what > the > >> user intended to type. > > > > This is the documented behavior. shell-expand-line performs all of the > > shell word expansions, including quote removal. > > How useful is that though when the expansion gives a different meaning? > > >> I often type Escape-Ctrl-E to expand a history substitution in place > >> before typing Enter, but it has the side effect of stripping quotes from > >> what I've already typed. > > > > If you want to perform history expansion, try M-^ (history-expand-line). > > Yes this is useful. I've set it up to happen automatically with > this in my .inputrc > > $if Bash > # do history expansion when space entered > Space: magic-space > $endif > > cheers, > Pádraig. > -- Keith Thompson
Re: shell-expand-line drops quotation marks
And today I learned that there's an "undo" command! (It's bound to Ctrl-X Ctrl-U and to Ctrl-_ by default.) Thanks, that's incredibly useful. I still can't think of a case where I'd want quote removal, which changes the meaning of the line, but I don't have to use it. On Fri, Nov 6, 2015 at 5:12 AM, Chet Ramey wrote: > On 11/4/15 1:48 PM, Keith Thompson wrote: > > Thanks, I didn't know about history-expand-line. > > > > Is there some case where shell-expand-line would actually be useful? > > If I've typed *"foo bar"*, I can't think of any case where I'd *want* > > it to be replaced by *foo bar*, which has a very different meaning. > > Of course the obvious answer is not to use it, but I'm wondering why > > it's there. > > Sure, when you want to expand aliases or variables in the command before > executing it. It's only the quote removal that you -- in this case -- > don't want. You can also undo the word expansions after viewing them, > restoring the quoted strings. > > There are separate bindable commands for history expansion, alias > expansion, and history-and-alias expansion. If you don't want the > rest of the word expansions, you can easily rebind the commands. > > Chet > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, ITS, CWRUc...@case.edu > http://cnswww.cns.cwru.edu/~chet/ > -- Keith Thompson
Re: Bug in bash 4.4-beta: suspending and restarting "man" program
I have some more information on this. In the latest test,
the problem occurs when I run bash under rxvt, but not when I run it under
xterm.
Using strace, I've found a difference in a call to rt_sigaction(). It calls
rt_sigaction(SIGTSTP, {SIG_DFL, ...})
under xterm (which works correctly), but
rt_sigaction(SIGTSTP, {SIG_IGN, ...})
under rxvt (where it doesn't).
I've been playing with rxvt and urxvt lately, which might explain why I've
seen the problem. Apparently there's some
difference between xterm and rxvt in the way they invoke the shell.
Details at:
https://gist.github.com/Keith-S-Thompson/c842663ace93c23fabd7
On Sat, Oct 31, 2015 at 12:45 PM, Keith Thompson
wrote:
> $ trap
> trap -- 'show_error' ERR
> $ type show_error
> show_error is a function
> show_error ()
> {
> printf "\e[1mExit $?\e[m\n" 1>&2
> }
> $
>
>
> On Sat, Oct 31, 2015 at 12:00 AM, Andreas Schwab
> wrote:
>
>> Keith Thompson writes:
>>
>> > For a while, I had two running login shells, one that had the problem
>> > and one that didn't. Comparing the output of "set" and "shopt" from
>> > both shells didn't show any differences that could explain this.
>>
>> What's the output of trap?
>>
>> Andreas.
>>
>> --
>> Andreas Schwab, sch...@linux-m68k.org
>> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
>> "And now for something completely different."
>>
>
>
>
> --
> Keith Thompson
>
--
Keith Thompson
Re: Bug in bash 4.4-beta: suspending and restarting "man" program
But there's still a mystery here. Why does it behave differently under rxvt
vs. xterm,
and why does that difference show up in bash 4.4-beta but not in 4.3.30?
(Both versions of bash are built from source on the same system.)
Running bash 4.3.30 under either xterm 261 or rxvt v2.6.4, I get:
bash-4.3$ trap
trap -- '' SIGTSTP
trap -- '' SIGTTIN
trap -- '' SIGTTOU
and Ctrl-Z works correctly.
Running bash-4.4-beta under xterm, I get
bash-4.4$ trap
trap -- '' SIGTTOU
and Ctrl-Z works correctly. Running bash-4.4-beta under rxvt, I get:
bash-4.4$ trap
trap -- '' SIGTSTP
trap -- '' SIGTTIN
trap -- '' SIGTTOU
and Ctrl-Z *doesn't* work.
The issue for me personally is that I'd like to run bash 4.4-beta, which
corrects
some bugs I've run into, under urxvt, which has better font support than
xterm.
Is there a workaround, a way to re-enable correct Ctrl-Z handling?
On Tue, Nov 10, 2015 at 7:33 AM, Chet Ramey wrote:
> On 11/9/15 5:55 PM, Keith Thompson wrote:
> > I have some more information on this. In the latest test,
> > the problem occurs when I run bash under rxvt, but not when I run it
> under
> > xterm.
> >
> > Using strace, I've found a difference in a call to rt_sigaction(). It
> calls
> >
> > rt_sigaction(SIGTSTP, {SIG_DFL, ...})
> >
> > under xterm (which works correctly), but
> >
> > rt_sigaction(SIGTSTP, {SIG_IGN, ...})
> >
> > under rxvt (where it doesn't).
>
> This can happen if SIGTSTP is ignored when the shell is invoked. When
> bash restores the original signal dispositions in child processes, it
> restores SIG_IGN.
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, ITS, CWRUc...@case.edu
> http://cnswww.cns.cwru.edu/~chet/
>
--
Keith Thompson
Re: Bug in bash 4.4-beta: suspending and restarting "man" program
On Tue, Nov 10, 2015 at 11:35 AM, Chet Ramey wrote: > > > It seems like you need to figure out why rxvt starts the shell with > SIGTSTP ignored. It doesn't seem like anything that the system /bin/sh > or the bash version you're running does, since xterm doesn't exhibit > this behavior. > > The difference between bash-4.3 and bash-4.4 is a bug fix: if the shell > is started with SIGTSTP ignored (any signal, really), it's supposed to > pass that setting on to the children it invokes. bash-4.3 didn't do that > in this case, and bash-4.4 does. > > And I think I've found it. In rxvt 2.6.4, src/command.c: /* * mimick login's behavior by disabling the job control signals * a shell that wants them can turn them back on */ #ifdef SIGTSTP signal(SIGTSTP, SIG_IGN); signal(SIGTTIN, SIG_IGN); signal(SIGTTOU, SIG_IGN); #endif /* SIGTSTP */ The latest release, rxvt 2.7.10, has the same code in src/init.c. rxvt-unicode (urxvt) has the same code in src/init.C. Would you consider this a bug in rxvt? It's obviously intentional, but I don't understand signal handling well enough to know whether it's reasonable. The comment implies that it's the shell's responsibility to re-enable the signals -- which bash did prior to 4.4-beta, but no longer does. There's certainly a bug *somewhere*, since anyone using bash 4.4-beta or later under rxvt or urxvt won't be able to use Ctrl-Z. If it's rxvt that's buggy, I'll contact the rxvt and urxvt maintainers (and I'll probably recompile my own version with those lines commented out). -- Keith Thompson
Re: Bug in bash 4.4-beta: suspending and restarting "man" program
On Tue, Nov 10, 2015 at 12:56 PM, Chet Ramey wrote: > On 11/10/15 3:17 PM, Keith Thompson wrote: > > On Tue, Nov 10, 2015 at 11:35 AM, Chet Ramey > <mailto:chet.ra...@case.edu>> wrote: > > > > > > > > It seems like you need to figure out why rxvt starts the shell with > > SIGTSTP ignored. It doesn't seem like anything that the system > /bin/sh > > or the bash version you're running does, since xterm doesn't exhibit > > this behavior. > > > > The difference between bash-4.3 and bash-4.4 is a bug fix: if the > shell > > is started with SIGTSTP ignored (any signal, really), it's supposed > to > > pass that setting on to the children it invokes. bash-4.3 didn't do > that > > in this case, and bash-4.4 does. > > > > > > And I think I've found it. In rxvt 2.6.4, src/command.c: > > > > /* > > * mimick login's behavior by disabling the job control signals > > * a shell that wants them can turn them back on > > */ > > #ifdef SIGTSTP > > signal(SIGTSTP, SIG_IGN); > > signal(SIGTTIN, SIG_IGN); > > signal(SIGTTOU, SIG_IGN); > > #endif /* SIGTSTP */ > > > > The latest release, rxvt 2.7.10, has the same code in src/init.c. > > rxvt-unicode (urxvt) has the same code in src/init.C. > > Does it do this only when it's starting a login shell? Or all interactive > shells? > It looks like it does it for all interactive shells. For all 4 combinations (rxvt vs. rxvt -ls, xterm --norc vs. xterm --norc --login), Ctrl-Z doesn't work. > See, the problem is not the behavior of the shell rxvt starts. It's that > shells are supposed to restore the original signal dispositions when they > create processes. A shell that has SIGTSTP ignored when it starts is > permitted to change the disposition to whatever it wants (though the user > can't set a trap on it), but is supposed to restore the original signal > handler (SIG_IGN in this case) in child processes it forks to run other > programs. > > > Would you consider this a bug in rxvt? It's obviously intentional, but I > > don't understand signal handling well enough to know whether it's > reasonable. > > The comment implies that it's the shell's responsibility to re-enable the > > signals -- which bash did prior to 4.4-beta, but no longer does. > > That's not quite it, see above. > > > There's certainly a bug *somewhere*, since anyone using bash 4.4-beta or > later > > under rxvt or urxvt won't be able to use Ctrl-Z. If it's rxvt that's > > buggy, I'll > > contact the rxvt and urxvt maintainers (and I'll probably recompile my > own > > version with those lines commented out). > > You might ask them to reconsider that decision. What's the concern, that > a non-job-control shell will suspend itself when someone hits ^Z? > > I can make bash blow away the original signal dispositions and pretend they > were SIG_DFL when an interactive shell starts, if there is no alternative. > > Thanks, I'll pass this information on to the rxvt and urxvt maintainers. -- Keith Thompson
Re: Bug in bash 4.4-beta: suspending and restarting "man" program
On Tue, Nov 10, 2015 at 1:57 PM, Andreas Schwab wrote: > Chet Ramey writes: > > > I can make bash blow away the original signal dispositions and pretend > they > > were SIG_DFL when an interactive shell starts, if there is no > alternative. > > Given that login(1) has the same behaviour there is probably no > alternative. > > Hmm. I just tried bash 4.4-beta on a Linux console (Ctrl-Alt-F1), and Ctrl-Z works correctly. I verified that the shell's parent process was "login". Perhaps (at least the Debian version of) login(1) *doesn't* do that. -- Keith Thompson
Re: Bug in bash 4.4-beta: suspending and restarting "man" program
On Tue, Nov 10, 2015 at 2:42 PM, Keith Thompson wrote: > On Tue, Nov 10, 2015 at 1:57 PM, Andreas Schwab > wrote: > >> Chet Ramey writes: >> >> > I can make bash blow away the original signal dispositions and pretend >> they >> > were SIG_DFL when an interactive shell starts, if there is no >> alternative. >> >> Given that login(1) has the same behaviour there is probably no >> alternative. >> >> Hmm. I just tried bash 4.4-beta on a Linux console (Ctrl-Alt-F1), and > Ctrl-Z works correctly. > I verified that the shell's parent process was "login". > Perhaps (at least the Debian version of) login(1) *doesn't* do that. > > I'm going to hold off on contacting the rxvt and urxvt developers for now. If you decide to modify bash to blow away the original signal dispositions, there's no point in reporting this as a bug in rxvt. Does that make sense? -- Keith Thompson
Re: Bug in bash 4.4-beta: suspending and restarting "man" program
On Wed, Nov 11, 2015 at 11:55 AM, Chet Ramey wrote: > On 11/10/15 10:03 PM, Keith Thompson wrote: > > On Tue, Nov 10, 2015 at 2:42 PM, Keith Thompson < > keithsthomp...@gmail.com > > <mailto:keithsthomp...@gmail.com>> wrote: > > > > On Tue, Nov 10, 2015 at 1:57 PM, Andreas Schwab < > sch...@linux-m68k.org > > <mailto:sch...@linux-m68k.org>> wrote: > > > > Chet Ramey mailto:chet.ra...@case.edu>> > writes: > > > > > I can make bash blow away the original signal dispositions and > pretend they > > > were SIG_DFL when an interactive shell starts, if there is no > alternative. > > > > Given that login(1) has the same behaviour there is probably no > > alternative. > > > > Hmm. I just tried bash 4.4-beta on a Linux console (Ctrl-Alt-F1), and > > Ctrl-Z works correctly. > > I verified that the shell's parent process was "login". > > Perhaps (at least the Debian version of) login(1) *doesn't* do that. > > > > I'm going to hold off on contacting the rxvt and urxvt developers > > for now. If you decide to modify bash to blow away the original signal > > dispositions, there's no point in reporting this as a bug in rxvt. > > > > Does that make sense? > > Yeah, that's fine. I will modify bash to set the original signal > dispositions to SIG_DFL in interactive shells. > Does that mean reverting default_tty_job_signals() in jobs.h to the version in bash 4.3.30: set_signal_handler (SIGTSTP, SIG_DFL); set_signal_handler (SIGTTIN, SIG_DFL); set_signal_handler (SIGTTOU, SIG_DFL); or is there more to it than that? (I'd like to try out the change myself.) -- Keith Thompson
Re: Bug in bash 4.4-beta: suspending and restarting "man" program
On Wed, Nov 11, 2015 at 3:16 PM, Keith Thompson wrote: > On Wed, Nov 11, 2015 at 11:55 AM, Chet Ramey wrote: > >> On 11/10/15 10:03 PM, Keith Thompson wrote: >> > On Tue, Nov 10, 2015 at 2:42 PM, Keith Thompson < >> keithsthomp...@gmail.com >> > <mailto:keithsthomp...@gmail.com>> wrote: >> > >> > On Tue, Nov 10, 2015 at 1:57 PM, Andreas Schwab < >> sch...@linux-m68k.org >> > <mailto:sch...@linux-m68k.org>> wrote: >> > >> > Chet Ramey mailto:chet.ra...@case.edu>> >> writes: >> > >> > > I can make bash blow away the original signal dispositions >> and pretend they >> > > were SIG_DFL when an interactive shell starts, if there is no >> alternative. >> > >> > Given that login(1) has the same behaviour there is probably no >> > alternative. >> > >> > Hmm. I just tried bash 4.4-beta on a Linux console (Ctrl-Alt-F1), >> and >> > Ctrl-Z works correctly. >> > I verified that the shell's parent process was "login". >> > Perhaps (at least the Debian version of) login(1) *doesn't* do that. >> > >> > I'm going to hold off on contacting the rxvt and urxvt developers >> > for now. If you decide to modify bash to blow away the original signal >> > dispositions, there's no point in reporting this as a bug in rxvt. >> > >> > Does that make sense? >> >> Yeah, that's fine. I will modify bash to set the original signal >> dispositions to SIG_DFL in interactive shells. >> > > Does that mean reverting default_tty_job_signals() in jobs.h to the > version in bash 4.3.30: > > set_signal_handler (SIGTSTP, SIG_DFL); > set_signal_handler (SIGTTIN, SIG_DFL); > set_signal_handler (SIGTTOU, SIG_DFL); > > or is there more to it than that? (I'd like to try out the change myself.) > > To answer my own question, I changed default_tty_job_signals() as described in jobs.c and nojobs.c, and commented out default_tty_job_signals() and all calls to it. It seems to work (Ctrl-Z works when I run the shell under rxvt). -- Keith Thompson
bash 4.4-beta chokes on "ulimit --help"
First off, I'm aware (now) that the ulimit command doesn't accept a "--help" option. That's not the issue (though I wouldn't mind if it did). My OS: Linux Mint 17.3 on x86_64. I built both versions 4.3.30 and 4.4-beta from source with default options with gcc 4.8.4. $ uname -a Linux bomb20 3.16.0-38-generic #52~14.04.1-Ubuntu SMP Fri May 8 09:43:57 UTC 2015 x86_64 GNU/Linux $ /_opt/apps/bash-4.3.30/bin/bash -c 'echo $BASH_VERSION ; ulimit --help' 4.3.30(1)-release /_opt/apps/bash-4.3.30/bin/bash: line 0: ulimit: --: invalid option ulimit: usage: ulimit [-SHabcdefilmnpqrstuvxT] [limit] $ /_opt/apps/bash-4.4-beta/bin/bash -c 'echo $BASH_VERSION ; ulimit --help' 4.4.0(1)-beta /_opt/apps/bash-4.4-beta/bin/bash: xrealloc: ./ulimit.def:382: cannot allocate 4294967296 bytes (8590045184 bytes allocated) $ -- Keith Thompson
Completion with -W fails if words contain ':'
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -Werror=implicit-function-declaration
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -flto=auto
-ffat-lto-objects -fstack-protector-strong -fstack-clash-protection
-Wformat -Werror=format-security -fcf-protection -Wall
uname output: Linux sal 6.11.0-9-generic #9-Ubuntu SMP PREEMPT_DYNAMIC
Mon Oct 14 13:19:59 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.2
Patch Level: 32
Release Status: release
Description:
If the wordlist given to `complete -W` includes words
containing the ':' character, completion misbehaves.
The problem seems to occur if two or more words in the wordlist
share a common prefix ending with ':'. The problem does not
occur with other characters; I've tried '/' and '_'.
Repeat-By:
Execute the following commands:
say() { echo "$@" ; }
complete -W "abc:abc abc:xyz" say
Type "say " at the prompt, then type repeatedly.
Each character appends "abc:" to the argument.
It should append "abc:" the first time, then offer a choice
between "abc:abc" and "abc:xyz".
Re: Completion with -W fails if words contain ':'
OK, that explains the problem, and I have a workaround.
(Background: I have a personal tool that uses "foo:bar" syntax for
some of its arguments. I've modified the tool to use "foo/bar
instead.)
Escaping the colons with backslashes doesn't seem to work:
$ echo $BASH_VERSION
5.2.32(1)-release
$ echo $COMP_WORDBREAKS
"'@><=;|&(:
$ say() { echo "$@" ; }
$ complete -r
$ complete -W "abc\:abc abc\:xyz" say
$ complete
complete -W 'abc\:abc abc\:xyz' say
$ say abc:abc:abc:abc:abc: # hitting TAB multiple times
abc:abc:abc:abc:abc:
$
On Mon, Dec 2, 2024 at 11:51 AM Chet Ramey wrote:
>
> On 12/2/24 12:52 AM, Keith Thompson wrote:
>
> > Bash Version: 5.2
> > Patch Level: 32
> > Release Status: release
> >
> > Description:
> > If the wordlist given to `complete -W` includes words
> > containing the ':' character, completion misbehaves.
> >
> > The problem seems to occur if two or more words in the wordlist
> > share a common prefix ending with ':'. The problem does not
> > occur with other characters; I've tried '/' and '_'.
>
> This is from the (obsolete) FAQ (doc/FAQ):
>
> E13) Why does filename completion misbehave if a colon appears in the
> filename?
>
> Filename completion (and word completion in general) may appear to behave
> improperly if there is a colon in the word to be completed.
>
> The colon is special to readline's word completion code: it is one of the
> characters that breaks words for the completer. Readline uses these
> characters
> in sort of the same way that bash uses $IFS: they break or separate the words
> the completion code hands to the application-specific or default word
> completion functions. The original intent was to make it easy to edit
> colon-separated lists (such as $PATH in bash) in various applications using
> readline for input.
>
> This is complicated by the fact that some versions of the popular
> `bash-completion' programmable completion package have problems with the
> default completion behavior in the presence of colons.
>
> The current set of completion word break characters is available in bash as
> the value of the COMP_WORDBREAKS variable. Removing `:' from that value is
> enough to make the colon not special to completion:
>
> COMP_WORDBREAKS=${COMP_WORDBREAKS//:}
>
> You can also quote the colon with a backslash to achieve the same result
> temporarily.
>
> --
> ``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/
Re: Completion with -W fails if words contain ':'
On Tue, Dec 3, 2024 at 10:20 AM Chet Ramey wrote:
>
> On 12/2/24 7:29 PM, Keith Thompson wrote:
> > OK, that explains the problem, and I have a workaround.
> >
> > (Background: I have a personal tool that uses "foo:bar" syntax for
> > some of its arguments. I've modified the tool to use "foo/bar
> > instead.)
>
> An easier workaround might have been removing `:' from COMP_WORDBREAKS.
Sure, but that would affect all completions. I only want to change how
completions
work for my one custom command.
> > Escaping the colons with backslashes doesn't seem to work:
>
> You have to quote the colons on the command line so readline breaks the
> words it sends to programmable completion like you want. That's what this
> FAQ text (which predates programmable completion) means:
When you wrote "on the command line", I thought you were referring to
the command line with the complete" command. If you meant escaping
colons on the command line with the "say" command, that's not useful
to me (and I haven't been able to get it to work anyway).
Can you clarify with an example? So far, I haven't found a solution
that's easier than just changing the syntax of my command to use '/'
rather than ':' (which I've done).
> >> The colon is special to readline's word completion code: it is one of the
> >> characters that breaks words for the completer. Readline uses these
> characters
> >> in sort of the same way that bash uses $IFS: they break or separate the
> words
> >> the completion code hands to the application-specific or default word
> >> completion functions.
>
> >
> > $ echo $BASH_VERSION
> > 5.2.32(1)-release
> > $ echo $COMP_WORDBREAKS
> > "'@><=;|&(:
> > $ say() { echo "$@" ; }
> > $ complete -r
> > $ complete -W "abc\:abc abc\:xyz" say
>
> You don't need to quote the colons here, but it doesn't end up hurting
> anything.
>
> > $ complete
> > complete -W 'abc\:abc abc\:xyz' say
> > $ say abc:abc:abc:abc:abc: # hitting TAB multiple times
>
> You haven't quoted the colons here. If you don't, readline will break
> the word at the colon and send the empty string to programmable
> completion.
>
> You can use the `-o filenames' option to complete to have programmable
> completion (and readline) quote the matches appropriately for you. If
> you don't want the full filename treatment, bash-5.3 will have the
> `-o fullquote' option to just do quoting without any of the other
> filename actions (appending a slash, etc.).
It looks like "-o filenames" is pretty close to what I want. I'd
rather not have the backslashes appear when I type , but I
can live with that.
Thanks.
Tilde is expanded in $PATH, inconsistent behavior
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -Werror=implicit-function-declaration
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -flto=auto
-ffat-lto-objects -fstack-protector-strong -fstack-clash-protection
-Wformat -Werror=format-security -fcf-protection -Wall
uname output: Linux sal 6.11.0-13-generic #14-Ubuntu SMP
PREEMPT_DYNAMIC Sat Nov 30 23:51:51 UTC 2024 x86_64 x86_64 x86_64
GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.2
Patch Level: 32
Release Status: release
Description:
A literal '~' or other tilde-prefix at the beginning of an
element of $PATH is expanded when a command is executed
from the bash prompt. This is undocumented and inconsistent with
the behavior of other commands that can execute commands.
This expansion doesn't happen when bash is invoked as "/bin/sh"
(which is a symlink to bash on some systems).
The "Tilde Expansion" section of the bash manual does talk about
using '~' when setting $PATH, but that applies only when setting
it, not when using a $PATH containing literal '~' characters.
A user who doesn't realize that, for example, "$HOME/bin" is
expanded in double quotes but "~/bin" is not might end up with
a $PATH setting that allows direct execution of some commands
from the bash prompt, but those same commands can't be found by
other tools.
I haven't run into this issue myself. This bug report is the
result of a recent discussion in comp.unix.shell.
Repeat-By:
Run this script:
```
#!/bin/bash
verbosely() {
echo "\$ $*"
"$@" || echo exit $?
}
export PATH='~/bin:/usr/bin:/bin'
echo "PATH=$PATH"
echo "HOME=$HOME"
verbosely type fnord
verbosely fnord # This works (and arguably shouldn't)
cat >run-fnord.c <
int main(void) { system("fnord"); }
EOF
verbosely cat run-fnord.c
verbosely gcc run-fnord.c -o run-fnord
verbosely ./run-fnord # This doesn't work
```
The output on my system is:
```
PATH=~/bin:/usr/bin:/bin
HOME=/home/kst
$ type fnord
fnord is /home/kst/bin/fnord
$ fnord
This is fnord
$ cat run-fnord.c
#include
int main(void) { system("fnord"); }
$ gcc run-fnord.c -o run-fnord
$ ./run-fnord
sh: 1: fnord: not found
```
Fix:
I haven't looked at the source code that implements this.
I suggest documenting this feature in the next release and marking
it as obsolescent, and then removing it in a later release.
There could be existing code that depends on it -- which I
suppose argues against removing it at all. The documentation
should at least mention that the expansion occurs and discuss
this inconsistent treatment of $PATH by bash vs. other tools.
Re: Tilde is expanded in $PATH, inconsistent behavior
On Fri 2025-01-24 11:45:22 EST, Chet Ramey wrote: > On 1/23/25 9:15 PM, Keith Thompson wrote: > > > But I don't see anything in the "Tilde Expansion" section that > > documents the behavior of a literal '~' in $PATH. > > It remains undocumented. Then I suggest that the phrase "as described above under Tilde Expansion" should be deleted (or that the feature should be documented). > > I suggest it would be better to document the behavior, since I imagine > > it's fairly easy to run into it accidentally. For example, something like > > > > PATH="~/bin:$PATH" > > > > will trigger the behavior. > > What do you think a user expects when they do something like this? How > many instances of this do you think exist out there? If you're going to > use something nonsensical like that, my guess is more people want the bash > behavior than not, as bad an idea as it is. First, let me acknowledge that this has not caused any problems for me. Feel free to consider that when prioritizing this. If I type PATH="$HOME/bin:$PATH" then I know that $HOME will be expanded to my home directory. $HOME and ~ are equivalent in many contexts. If I hadn't crawled down this particular rabbit hole, I might have (incorrectly but IMHO not unreasonably) assumed that PATH="~/bin:$PATH" would do exactly the same thing, with ~ expanding to my home directory. In fact, it instead puts a literal '~' character into my $PATH -- which will appear to work when I execute commands interactively, but fails when I execute a command from the bash prompt that then tries to invoke a command that happens to be under "$HOME/bin". I can also imagine someone seeing existing code that depends on this feature and trying to read the bash documentation to figure out what the heck is going on. Perhaps removing this behavior is not feasible, but I'm suggesting that it should be (briefly) documented with a warning against using it.
Re: Tilde is expanded in $PATH, inconsistent behavior
On Thu, Jan 23, 2025 at 5:31 PM Lawrence Velázquez wrote: > > On Thu, Jan 23, 2025, at 6:37 PM, Keith Thompson wrote: > > Description: > > A literal '~' or other tilde-prefix at the beginning of an > > element of $PATH is expanded when a command is executed > > from the bash prompt. This is undocumented and inconsistent with > > the behavior of other commands that can execute commands. > > > > This expansion doesn't happen when bash is invoked as "/bin/sh" > > (which is a symlink to bash on some systems). > > The texinfo documentation mentions it as something that is disabled > in POSIX mode: > > 19. Literal tildes that appear as the first character in > elements of the `PATH' variable are not expanded as > described above under Tilde Expansion. > > https://www.gnu.org/software/bash/manual/html_node/Bash-POSIX-Mode.html That explains why /bin/sh (which is what C's system() function uses, as in my sample code) doesn't exhibit the behavior, even if /bin/sh is a symlink to bash. But I don't see anything in the "Tilde Expansion" section that documents the behavior of a literal '~' in $PATH. I suggest it would be better to document the behavior, since I imagine it's fairly easy to run into it accidentally. For example, something like PATH="~/bin:$PATH" will trigger the behavior. > > There could be existing code that depends on it -- which I > > suppose argues against removing it at all. The documentation > > should at least mention that the expansion occurs and discuss > > this inconsistent treatment of $PATH by bash vs. other tools. > > Perhaps this is another $[...] situation -- keeping the feature > around for compatibility, but leaving it undocumented to discourage > users from learning about and using it. $[...] appears to behave like $((...)). Is it equivalent? It's less likely that someone could write that accidentally. But the fact that it's undocumented could cause problems for anyone who sees it in an existing script and needs to figure out what it does. Perhaps this was already debated, but my preference would be to document it with a note discouraging its use.
