In a script, when you kill a process, you get a terminal style message...
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 shell 4.4.0-109-generic #132-Ubuntu SMP Tue Jan 9 19:52:39
UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.3
Patch Level: 48
Release Status: release
Description:
This is actually a list of 3 issues that I've been saving up for some
time.
The first one (which is referenced in the Subject line above) is the
most
vexing, but all 3 are interesting.
1) In a script, when you kill a process, you get a terminal style message
about the process being killed. See below for further description.
2) "shopt -s nullglob" breaks filename tab completion. I found that tab
completion
no longer works after I do that "shopt" command.
3) Using Escape v to edit a command line in vi mode works, but leaves the
keyboard in a funny state. Specifically, it leaves you at the next bash
prompt, but
in "vi mode" - i.e, hitting k displays the previous line in the history rather
than
entering a 'k'. The user effect is that the keyboard appears to be "stuck"
until you
hit ^C to reset things.
Repeat-By:
(First, do: ln -sv /bin/sleep MySleep)
This is the script to demonstrate problem #1 in my list:
#!/bin/bash
{
./MySleep 32767
} &
echo "BASH_VERSION = $BASH_VERSION"
sleep 3
killall -v MySleep
sleep 1
Here is a run of this script:
$ ./testBashBug
BASH_VERSION = 4.3.48(1)-release
Killed MySleep(7000) with signal 15
./testBashBug: line 4: 7000 Terminated ./MySleep 32767
$
My point is that the "Terminated" message is pretty pointless when the
kill is from within a script. It may worry a user unnecessarily.
Note that the setup has to be as above - where you run a {} list in the
background,
then kill a process running within that {} group.
popd with garbage parameter removes entry from dirs but doesn't cd.
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 -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall uname output: Linux shell 3.13.0-111-generic #158-Ubuntu SMP Wed Feb 22 16:12:03 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.3 Patch Level: 11 Release Status: release Description: popd with garbage parameter removes entry from dirs but doesn't cd. Example: popd lsdfjlskfj Repeat-By: cd /some/directory pushd /tmp dirs popd skdfhksjdfhkjsdf pwd;dirs Fix: I assume it should generate an error message for the garbage parameter and not change the contents of the directory stack.
Multiline commands do not survive history -w/-r
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 shell 4.4.0-79-generic #100-Ubuntu SMP Wed May 17 19:58:14
UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.3
Patch Level: 48
Release Status: release
Description:
Multiline commands (i.e., a command with embedded newlines) do not
survive
intact when written out to the history file and then reloaded.
Repeat-By:
See attached script file:
Recording to file 'typescript' at: Sun Jun 11 18:51:27 2017.
~s to stop recording, ~r to resume
spawn bash
gazelle@shell:~$ HISTFILE=/tmp/zzz
gazelle@shell:~$ history -c;history -r;history
gazelle@shell:~$ gawk 'BEGIN {
> print "hello, world"
> }'
hello, world
gazelle@shell:~$ history
1 gawk 'BEGIN {
print "hello, world"
}'
2 history
gazelle@shell:~$ !1
gawk 'BEGIN {
print "hello, world"
}'
hello, world
gazelle@shell:~$ history -w
gazelle@shell:~$ history -c;history -r;history
1 gawk 'BEGIN {
2 print "hello, world"
3 }'
4 history
5 gawk 'BEGIN {
6 print "hello, world"
7 }'
8 history -w
gazelle@shell:~$ !5
gawk 'BEGIN {
> ^C
gazelle@shell:~$ exit
Fix:
I think there needs to be some kind of "magic character" in the history
file
that represents a newline - which would be handled by the -w and -r
options
of the history command.
Why does 'connect' take so long (sometimes) and can't be interrupted?
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='/.../local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2 -Wno-parentheses -Wno-format-security uname output: Linux shell 4.4.0-79-generic #100-Ubuntu SMP Wed May 17 19:58:14 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-unknown-linux-gnu Bash Version: 4.4 Patch Level: 0 Release Status: release Description: This is a little complicated and I can't give you full details on how to replicate it, since I don't fully understand it myself. But under certain circumstances, the following line takes a very long time to execute: exec 5<>/dev/tcp/localhost/12345 My objections are twofold: a) That it takes so long - it should either succeed or file (almost) immediately. b) When it is running, it is uninterruptable. None of ^C, ^\, or ^Z, nor any signal sent to the bash process (other than SIGKILL) will cause it to exit. Effectively, the only escape is to SIGKILL the bash process, which causes the entire shell to be killed. More details below. Repeat-By: I am using a bash script to communicate with a program that I wrote (in C) using TCPIP. The C program listens on port 12345 (for example) and the bash script connects to it, using the command line shown above. The actual lines in my script are now as follows: printf "Elapsed time for this 'exec' ...\t";tme=$(date +%s) exec 5<>/dev/tcp/localhost/12345 echo "$(($(date +%s) - $tme)) seconds." Normally, for almost all possible inputs (to the C program), this executes immediately (says "0 seconds" elapsed). But, for one particular input, it takes a very long time - in my most recent test, it was 116 seconds (!). This problem is 100% repeatable (with the given specific input to the C program). Note, however, that it does eventually connect. As far as I can tell, it does always eventually connect. Needless to say, when I first hit this problem, I assumed it had hung, and when I tried to kill it, I ran into the problems described above. Also note: In testing this, I found that if I do hit ^C while it is hung, then wait long enough, eventually it does exit as shown below: Elapsed time for this 'exec' ...^C^C^C^Cbash: connect: Connection refused bash: /dev/tcp/localhost/12345: Connection refused Fix: Well, I'd like to know why it (sometimes) takes so long. Amd it would be nice if you could interrupt it when it does hang. Or, alternatively, set a timelimit for the connect().
"realpath" loadable (in the examples/loadables dir) infinite loops
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/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2 -Wno-parentheses -Wno-format-security uname output: Linux shell 4.4.0-79-generic #100-Ubuntu SMP Wed May 17 19:58:14 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-unknown-linux-gnu Bash Version: 4.4 Patch Level: 0 Release Status: release Description: Command "realpath --help" causes infinite loop. Repeat-By: enable -f /usr/local/lib/bash/realpath realpath realpath --help causes infinite loop of: realpath: usage: realpath [-csv] pathname [pathname...] realpath: usage: realpath [-csv] pathname [pathname...] realpath: usage: realpath [-csv] pathname [pathname...] realpath: usage: realpath [-csv] pathname [pathname...] realpath: usage: realpath [-csv] pathname [pathname...] realpath: usage: realpath [-csv] pathname [pathname...] until the shell is killed by signal 9 from another terminal.
