Strange bash behavior
Hi,
I'm not sure what is going on, but the bash test suite was getting
stopped (as if SIGSTOP was received) in the middle. Trying to find
minimal set of conditions it came to this:
- my ~/.bashrc has to contain 'cd /' (any dir works)
- the tests have to first execute run-execscript, namely it has to
execute exec6.sub, namely the line ${THIS_SH} -i ./exec8.sub
- the file exec8.sub is reported as not found (I presume because of the
'cd /' in .bashrc)
- the tests then have to run read-test, exactly in read2.sub when
'read -t 2 a < /dev/tty' was executed whole thing was stopped
When I removed the 'cd' command from my ~/.bashrc, all worked fine.
I then tried to make minimal reproducible case and came to this (this
time there is no 'cd /' in my ~/.bashrc needed):
$ bash -c 'bash -i i; bash -i i'
bash -c 'bash -i i; bash -i i'
bash: i: No such file or directory
[1]+ Stopped bash -c 'bash -i i; bash -i i'
I would not go as far as thinking it's a bug, but it's very suspicious
behavior to me. Also I'm not 100% sure that both problems are identical.
I am able to reproduce on Solaris 10 and 11 and on my OpenSuse Linux.
This covers bash version 3.2.52(1), 4.1.17(1) and 4.2.53(1). I have also
reproduced on latest 4.4.5 which I was doing testing on.
At that moment I decided to seek help here :)
Thanks!
--
Vlad
problem with redir test
Hi,
during testing of latest bash on Solaris I found strange behavior. We
run the tests with clear environment (env -). It seems to be caused by
undefined SHELL variable. The test reported
150,151c150,151
< ./redir11.sub: line 26: echo: write error: Bad file number
< ./redir11.sub: line 27: echo: write error: Bad file number
---
> ./redir11.sub: line 26: $(a=4 foo): Bad file number
> ./redir11.sub: line 27: $(a=4 foo): Bad file number
As a workaround I am using the attached patch although I don't feel that
it looks like a proper fix. Maybe it's a thing worth investigating? Can
you reproduce the issue?
Thank you
--
Vlad
When SHELL is unset the test fails with
150,151c150,151
< ./redir11.sub: line 26: echo: write error: Bad file number
< ./redir11.sub: line 27: echo: write error: Bad file number
---
> ./redir11.sub: line 26: $(a=4 foo): Bad file number
> ./redir11.sub: line 27: $(a=4 foo): Bad file number
--- tests/redir.tests 2016-12-01 11:20:04.910983199 +
+++ tests/redir.tests 2016-12-01 11:19:34.114069067 +
@@ -1,7 +1,7 @@
: ${TMPDIR:=/tmp}
export LC_ALL=C
-export LANG=C
+export LANG=C; export SHELL=
# catch-all for remaining untested redirection stuff
set +o posix
Testsuite problem when HOME is not defined
In spirit similar problem to the previous one, when the tests are
executed with $HOME undefined, I was getting this error:
26d25
< ./comsub-posix.tests: line 103: cd: HOME not set
28d26
< ./comsub-posix.tests: line 106: cd: HOME not set
I am attaching the patch I am using for workaround, maybe it's worth
adding something similar officially?
Thank you
--
Vlad
If $HOME is not set (running from cron perhaps), the tests will output:
26d25
< ./comsub-posix.tests: line 103: cd: HOME not set
28d26
< ./comsub-posix.tests: line 106: cd: HOME not set
--- tests/comsub-posix.tests2016-11-29 03:41:57.414081235 +
+++ tests/comsub-posix.tests2016-11-29 03:36:30.425718528 +
@@ -1,4 +1,5 @@
-
+HOME=${HOME:-/}
+export HOME
# works right
echo ab$(echo mnop)yz
# works right
bash tests failing when compiled with --enable-xpg-echo-default=yes
Hi,
On Solaris bash is compiled with --enable-xpg-echo-default=yes (and
--enable-usg-echo-default=yes if that makes difference). I have no idea
why, but since it was shipped like this for a long time, I am afraid of
changing that :)
Because of this setting the tests are failing. I am attaching a patch we
are using for workaround to show where the problems are seen. I used
'echo -E' when investigating, but "printf '%s\n'" seems to be more
appropriate. If there is interest I'm more than happy to rework the
attached patch.
Thanks!
--
Vlad
solaris is compiled with --enable-xpg-echo-default=yes which makes some
tests fail. Should we use printf '%s\n' "..." instead?
--- tests/comsub2.sub 2016-11-28 01:04:23.177652643 -0800
+++ tests/comsub2.sub 2016-11-28 01:01:49.330747645 -0800
@@ -4,5 +4,5 @@ echo "$qpath"
# it's crazy that all three of these produce the same result
echo ${qpath//\\/}
-echo ${qpath//"`echo \\`"/}
-echo ${qpath//`echo ""`/}
+echo ${qpath//"`echo -E \\`"/}
+echo ${qpath//`echo -E ""`/}
--- tests/exp5.sub 2016-11-28 02:38:32.148794257 -0800
+++ tests/exp5.sub 2016-11-28 02:33:12.133199473 -0800
@@ -1,18 +1,18 @@
# expansions involving patterns
var='[hello'
-echo "${var//[/}"
+echo -E "${var//[/}"
red='\[\e[0;31m\]'
-echo "${red//\\[\\e/}"
+echo -E "${red//\\[\\e/}"
foo="${red//\\[\\e/}"
# foo == [0;31m\]
-echo "${foo//[0;31m\\/}"
+echo -E "${foo//[0;31m\\/}"
-echo "${var//[]/}"
-echo "${red//[]/}"
+echo -E "${var//[]/}"
+echo -E "${red//[]/}"
v=hello
foo='[:alpha:]'
--- tests/exp8.sub 2016-11-28 03:44:56.875686938 -0800
+++ tests/exp8.sub 2016-11-28 03:39:21.761054928 -0800
@@ -10,11 +10,11 @@ declare -p var | sed -n l
recho ${var@Q}
recho ${var@P}
-echo ${var@A}
+echo -E ${var@A}
unset array
array=( [$'x\001y\177z']=foo ) # should be error
-echo ${array[@]@A}
+echo -E ${array[@]@A}
unset array
declare -a array=([0]=$'x\001y\177z')
@@ -23,9 +23,9 @@ declare -p array
unset array
array=( "$var" )
recho ${array[@]}
-echo ${array[@]@A}
+echo -E ${array[@]@A}
unset array
declare -A array
array=( [$'x\001y\177z']=$'a\242b\002c' )
-echo ${array[@]@A}
+echo -E ${array[@]@A}
--- tests/heredoc3.sub 2016-11-28 03:58:47.587299575 -0800
+++ tests/heredoc3.sub 2016-11-28 03:55:11.935894965 -0800
@@ -69,7 +69,7 @@ cat <\END'
+echo -E end 'hello\END'
# this has to be last -- results in a syntax error
# doesn't currently parse because EOF is not on a line by itself -- should it?
--- tests/quote1.sub2016-11-28 04:11:46.210688369 -0800
+++ tests/quote1.sub2016-11-28 04:08:49.101872596 -0800
@@ -14,7 +14,7 @@ echo "'${test//"'"/}'"
echo "'${test//"'"/"'\\''"}'"
-echo "'${test//"'"/\'\\'\'}'"
+echo -E "'${test//"'"/\'\\'\'}'"
#echo "'${test//'/}'" # hangs waiting for '
#echo "'${test//"'"/'\\''}'" # hangs waiting for '
Various improvements to tests/run-all
Hi,
I am attaching patch against tests/run-all with the hope that the
changes can be accepted upstream. The patch should be self explanatory.
For completeness here are the errors I saw before I erased SHELLOPTS
variable
run-redir
warning: the text of a system error message may vary between systems and
warning: produce diff output.
warning: if the text of an error message concerning `redir1.*' not being
warning: found or messages concerning bad file descriptors produce diff
warning: output, please do not consider it a test failure
142,143c142
< ./redir10.sub: line 17: syntax error near unexpected token `<'
< ./redir10.sub: line 17: ` done 3< <(echo x)'
---
>
148c147
< after: 7
---
> after: 42
156c155
< after: 7
---
> after: 42
161,162c160
< ./redir12.sub: line 2: syntax error near unexpected token `('
< ./redir12.sub: line 2: `cat <(exit 123) >/dev/null'
---
> 123
...
run-varenv
35c35
< declare -rx
SHELLOPTS="braceexpand:hashall:interactive-comments:physical"
---
> declare -r
> SHELLOPTS="braceexpand:hashall:interactive-comments:physical"
72c72
< declare -irx outside1="1"
---
> declare -ir outside1="1"
77c77
< declare -irx myvar="1"
---
> declare -ir myvar="1"
Thank you
--
Vlad
# There are three problems fixed
# a) our build system exports SHELLOPTS which makes testing fail
#We could have set "unexport SHELLOPTS" in our Makefile, but maybe this
#will be accepted by community?
# b) Test for a /tmp/xx leftover from running the giant bash
#test harness. This can happen in the test harness run is
#interrupted with ^C.
#Without this test, the test harness will start failing
#for no real reason.
# c) This script runs all the tests via 'sh '. The problem is that 'sh'
#might not necesarily be bash. And might produce errors
--- tests/run-all 2016-11-28 00:46:51.812583704 -0800
+++ tests/run-all 2016-11-28 00:45:20.302845042 -0800
@@ -17,7 +17,7 @@ export PATH
# unset BASH_ENV only if it is set
[ "${BASH_ENV+set}" = "set" ] && unset BASH_ENV
# ditto for SHELLOPTS
-#[ "${SHELLOPTS+set}" = "set" ] && unset SHELLOPTS
+[ "${SHELLOPTS+set}" = "set" ] && unset SHELLOPTS
: ${THIS_SH:=../bash}
export THIS_SH
@@ -26,6 +26,11 @@ ${THIS_SH} ./version
rm -f ${BASH_TSTOUT}
+if [ -f /tmp/xx ] ; then
+echo "someone left a /tmp/xx around. I can't test."
+exit 1
+fi
+
echo Any output from any test, unless otherwise noted, indicates a possible
anomaly
for x in run-*
@@ -33,7 +38,7 @@ do
case $x in
$0|run-minimal|run-gprof) ;;
*.orig|*~) ;;
- *) echo $x ; sh $x ; rm -f ${BASH_TSTOUT} ;;
+ *) echo $x ; ${THIS_SH} $x ; rm -f ${BASH_TSTOUT} ;;
esac
done
Re: Various improvements to tests/run-all
On 12/1/16 3:21 PM, Vladimir Marek wrote: > Hi, > > I am attaching patch against tests/run-all with the hope that the > changes can be accepted upstream. The patch should be self explanatory. > For completeness here are the errors I saw before I erased SHELLOPTS > variable I can see doing this. From the error messages in your message, it seems like you enable posix mode via SHELLOPTS. The tests definitely don't expect to be run in posix mode. As for your other suggestions, bash-4.4 doesn't use /tmp/xx; that's a remnant from previous versions. bash-4.4 sets, exports, and uses $BASH_TSTOUT. Also, sh is just used to run each test harness (e.g., run-redir). All of those scripts run the actual test scripts using $THIS_SH, so there's no real gain to using $THIS_SH there. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Strange bash behavior
On 12/1/16 2:28 PM, Vladimir Marek wrote:
> Hi,
>
> I'm not sure what is going on, but the bash test suite was getting
> stopped (as if SIGSTOP was received) in the middle. Trying to find
> minimal set of conditions it came to this:
>
> - my ~/.bashrc has to contain 'cd /' (any dir works)
> - the tests have to first execute run-execscript, namely it has to
>execute exec6.sub, namely the line ${THIS_SH} -i ./exec8.sub
> - the file exec8.sub is reported as not found (I presume because of the
>'cd /' in .bashrc)
Yes, though the line that runs exec8.sub is actually in execscript, and
exec6.sub doesn't matter at all. Changing ./ to ${PWD}/ should fix it.
> - the tests then have to run read-test, exactly in read2.sub when
> 'read -t 2 a < /dev/tty' was executed whole thing was stopped
This is strange, since the presence or absence or a controlling terminal
doesn't have anything to do with whether or not there's a cd in a startup
script that's not run by a non-interactive shell (that is, since the read
script isn't run by an interactive shell, your .bashrc isn't run). Very
strange.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: problem with redir test
On 12/1/16 2:35 PM, Vladimir Marek wrote: > Hi, > > during testing of latest bash on Solaris I found strange behavior. We > run the tests with clear environment (env -). It seems to be caused by > undefined SHELL variable. The test reported > > 150,151c150,151 > < ./redir11.sub: line 26: echo: write error: Bad file number > < ./redir11.sub: line 27: echo: write error: Bad file number > --- >> ./redir11.sub: line 26: $(a=4 foo): Bad file number >> ./redir11.sub: line 27: $(a=4 foo): Bad file number I can't reproduce this. The key is that redir11.sub inherits file descriptor 3 as an fd open for read on /etc/passwd, and echo gets a write error when trying to write to it. This might also be affected by SHELLOPTS setting posix mode, but I can't reproduce it even when setting SHELLOPTS=posix in the environment. It's also hard to see why starting bash without SHELL in the environment sould make such a difference, since bash sets SHELL to the current user's login shell, as found via getpwent. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Strange bash behavior
On Fri, Dec 2, 2016 at 6:28 AM, Vladimir Marek
wrote:
> Hi,
>
> I'm not sure what is going on, but the bash test suite was getting
> stopped (as if SIGSTOP was received) in the middle. Trying to find
> minimal set of conditions it came to this:
>
> - my ~/.bashrc has to contain 'cd /' (any dir works)
> - the tests have to first execute run-execscript, namely it has to
>execute exec6.sub, namely the line ${THIS_SH} -i ./exec8.sub
> - the file exec8.sub is reported as not found (I presume because of the
>'cd /' in .bashrc)
> - the tests then have to run read-test, exactly in read2.sub when
> 'read -t 2 a < /dev/tty' was executed whole thing was stopped
>
> When I removed the 'cd' command from my ~/.bashrc, all worked fine.
>
> I then tried to make minimal reproducible case and came to this (this
> time there is no 'cd /' in my ~/.bashrc needed):
>
> $ bash -c 'bash -i i; bash -i i'
> bash -c 'bash -i i; bash -i i'
> bash: i: No such file or directory
>
> [1]+ Stopped bash -c 'bash -i i; bash -i i'
>
I can reproduce this with bash 4.4.5 on Debian 8.5.
foo@deb64:~$ bash -c 'bash -i 1; bash -i 2'
bash: 1: No such file or directory
[1]+ Stopped bash -c 'bash -i 1; bash -i 2'
foo@deb64:~$ echo $?
149
It was stopped by SIGTTIN. According to gdb backtrace it was killed by the
second "bash -i".
4099 while ((terminal_pgrp = tcgetpgrp (shell_tty)) != -1)
4100 {
4101 if (shell_pgrp != terminal_pgrp)
4102 {
4103 SigHandler *ottin;
4104
4105 ottin = set_signal_handler (SIGTTIN, SIG_DFL);
4106 kill (0, SIGTTIN);
4107 set_signal_handler (SIGTTIN, ottin);
4108 continue;
4109 }
4110 break;
4111 }
The problem is tcgetpgrp() still returns the pgrp of the first "bash -i"
when the second "bash -i" is running. This can be shown with following
example:
foo@deb64:~$ bash -c 'bash -i 1; sleep '
bash: 1: No such file or directory<-- CTRL-C does not work here
root@deb64:~# ps t pts/10 j
PPIDPID PGIDSID TTY TPGID STAT UID TIME COMMAND
96886 96887 96887 96887 pts/1097073 Ss1001 0:00 -bash
96887 97072 97072 96887 pts/1097073 S 1001 0:00 bash -c
bash -i 1; sleep
97072 97074 97072 96887 pts/1097073 S 1001 0:00 sleep
Here the TPGID 97073 must be the first "bash -i" which has already exited.
Seems like for some reason the "bash -c" does not set the foreground pgrp
to the second "bash -i".
(Still learning the APUE book. Hope my analysis makes sense. :)
