hush testsuite: add many tests from ash testsuite

Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>

shell/ash_test/ash-quoting/dollar_repl_slash_bash1.tests

@@ -1,5 +1,5 @@
 # The bug here was triggered by:
-# * performin pathname expansion because we see [
+# * performing pathname expansion because we see [
 # * replace operator did not escape \ in replace string
 
 IP=192.168.0.1

shell/hush_test/hush-invert/invert.right

@@ -0,0 +1,10 @@
+1
+1
+1
+0
+0
+1
+0
+1
+0
+1

shell/hush_test/hush-invert/invert.tests

@@ -0,0 +1,19 @@
+# tests of return value inversion
+# placeholder for future expansion
+
+# user subshells (...) did this wrong in bash versions before 2.04
+
+! ( echo hello | grep h >/dev/null 2>&1 ); echo $?
+! echo hello | grep h >/dev/null 2>&1 ; echo $?
+
+! true ; echo $?
+! false; echo $?
+
+! (false) ; echo $?
+! (true); echo $?
+
+! true | false ; echo $?
+! false | true ; echo $?
+
+! (true | false) ; echo $?
+! (false | true) ; echo $?

shell/hush_test/hush-misc/heredoc4.right

@@ -0,0 +1 @@
+'$'

shell/hush_test/hush-misc/heredoc4.tests

@@ -0,0 +1,3 @@
+cat <<EOF
+'$'
+EOF

shell/hush_test/hush-misc/last_amp.right

@@ -0,0 +1,2 @@
+3
+End

shell/hush_test/hush-misc/last_amp.tests

@@ -0,0 +1,8 @@
+$THIS_SH -c 'echo 3&'
+d=`date`
+while test "`date`" = "$d"; do true; done
+d1=`date`
+$THIS_SH -c 'sleep 1&'
+d2=`date`
+test "$d1" = "$d2" || echo BAD
+echo End

shell/hush_test/hush-misc/local1.right

@@ -0,0 +1,4 @@
+A1:'A'
+A2:''
+A3:''
+A4:'A'

shell/hush_test/hush-misc/local1.tests

@@ -0,0 +1,11 @@
+a=A
+f() {
+	local a
+	# the above line unsets $a
+	echo "A2:'$a'"
+	unset a
+	echo "A3:'$a'"
+}
+echo "A1:'$a'"
+f
+echo "A4:'$a'"

shell/hush_test/hush-misc/nulltick1.right

@@ -0,0 +1,3 @@
+Test 1
+Test 2
+Done

shell/hush_test/hush-misc/nulltick1.tests

@@ -0,0 +1,3 @@
+echo Test ` ` 1
+echo Test `</dev/null` 2
+echo Done

shell/hush_test/hush-quoting/dollar_repl_slash_bash1.right

@@ -0,0 +1,10 @@
+192\.168\.0\.1
+192\.168\.0\.1[
+192\.168\.0\.1[
+192\\.168\\.0\\.1[
+192\.168\.0\.1[
+192\.168\.0\.1
+192\.168\.0\.1[
+192\.168\.0\.1[
+192\\.168\\.0\\.1[
+192\.168\.0\.1[

shell/hush_test/hush-quoting/dollar_repl_slash_bash1.tests

@@ -0,0 +1,21 @@
+# The bug here was triggered by:
+# * performing pathname expansion because we see [
+# * replace operator did not escape \ in replace string
+
+IP=192.168.0.1
+
+rm -f '192.168.0.1['
+echo "${IP//./\\.}"
+echo "${IP//./\\.}"'[' # bug was here
+echo "${IP//./\\.}["   # bug was here
+echo "${IP//./\\\\.}[" # bug was here
+echo "192\.168\.0\.1["
+
+echo >'192.168.0.1['
+echo "${IP//./\\.}"
+echo "${IP//./\\.}"'[' # bug was here
+echo "${IP//./\\.}["   # bug was here
+echo "${IP//./\\\\.}[" # bug was here
+echo "192\.168\.0\.1["
+
+rm -f '192.168.0.1['

shell/hush_test/hush-read/read_r.tests

@@ -1,2 +1,4 @@
-echo -e 'test\\\nbest' | (read reply; echo "$reply")
-echo -e 'test\\\nbest' | (read -r reply; echo "$reply")
+echo 'test\
+best' | (read reply; echo "$reply")
+echo 'test\
+best' | (read -r reply; echo "$reply")

shell/hush_test/hush-signals/reap1.right

@@ -0,0 +1 @@
+Ok

shell/hush_test/hush-signals/reap1.tests

@@ -0,0 +1,14 @@
+#!/bin/sh
+
+# Must not find us alive
+{ sleep 2; kill -9 $$; } 2>/dev/null &
+
+sleep 1 &
+PID=$!
+
+# We must exit the loop in one second.
+# We had bug 5304: builtins never waited for exited children
+while kill -0 $PID >/dev/null 2>&1; do
+    true
+done
+echo Ok

shell/hush_test/hush-signals/sigint1.right

@@ -0,0 +1 @@
+Sending SIGINT to main shell PID

shell/hush_test/hush-signals/sigint1.tests

@@ -0,0 +1,41 @@
+# What should happen if non-interactive shell gets SIGINT?
+
+(sleep 1; echo Sending SIGINT to main shell PID; exec kill -INT $$) &
+
+# We create a child which exits with 0 even on SIGINT
+# (The complex command is necessary only if SIGINT is generated by ^C,
+# in this testcase even bare "sleep 2" would do because
+# in the testcase we don't send SIGINT *to the child*...)
+$THIS_SH -c 'trap "exit 0" SIGINT; sleep 2'
+
+# In one second, we (main shell) get SIGINT here.
+# The question is whether we should, or should not, exit.
+
+# bash will not stop here. It will execute next command(s).
+
+# The rationale for this is described here:
+# http://www.cons.org/cracauer/sigint.html
+#
+# Basically, bash will not exit on SIGINT immediately if it waits
+# for a child. It will wait for the child to exit.
+# If child exits NOT by dying on SIGINT, then bash will not exit.
+#
+# The idea is that the following script:
+# | emacs file.txt
+# | more cmds
+# User may use ^C to interrupt editor's ops like search. But then
+# emacs exits normally. User expects that script doesn't stop.
+#
+# This is a nice idea, but detecting "did process really exit
+# with SIGINT?" is racy. Consider:
+# | bash -c 'while true; do /bin/true; done'
+# When ^C is pressed while bash waits for /bin/true to exit,
+# it may happen that /bin/true exits with exitcode 0 before
+# ^C is delivered to it as SIGINT. bash will see SIGINT, then
+# it will see that child exited with 0, and bash will NOT EXIT.
+
+# Therefore we do not implement bash behavior.
+# I'd say that emacs need to put itself into a separate pgrp
+# to isolate shell from getting stray SIGINTs from ^C.
+
+echo Next command after SIGINT was executed

shell/hush_test/hush-signals/signal2.right

@@ -0,0 +1,3 @@
+child sleeps
+child exits as expected
+parent exits

shell/hush_test/hush-signals/signal2.tests

@@ -0,0 +1,18 @@
+#!/bin/sh
+
+$THIS_SH -c '
+cleanup() {
+    echo "child exits as expected"
+    exit
+}
+trap cleanup HUP
+echo "child sleeps"
+sleep 1
+echo "BAD exit from child!"
+' &
+
+child=$!
+sleep 0.1 # let child install handler first
+kill -HUP $child
+wait
+echo "parent exits"

shell/hush_test/hush-signals/signal3.right

@@ -0,0 +1,4 @@
+child sleeps
+child got HUP
+child exits
+parent exits

shell/hush_test/hush-signals/signal3.tests

@@ -0,0 +1,17 @@
+#!/bin/sh
+
+$THIS_SH -c '
+hup() {
+    echo "child got HUP"
+}
+trap hup HUP
+echo "child sleeps"
+sleep 1
+echo "child exits"
+' &
+
+child=$!
+sleep 0.1 # let child install handler first
+kill -HUP $child
+wait
+echo "parent exits"

shell/hush_test/hush-signals/signal5.right

@@ -0,0 +1,12 @@
+Sleeping
+Sleeping
+Waiting
+2 sec passed, sending USR1 to parent
+USR1 received
+Wait exit code: 138
+Waiting
+3 sec passed, sending USR1 to parent
+USR1 received
+Wait exit code: 138
+Waiting
+Wait returned 0

shell/hush_test/hush-signals/signal5.tests

@@ -0,0 +1,14 @@
+trap "echo USR1 received" USR1
+stub() {
+    echo "Sleeping"
+    sleep $1
+    echo "$1 sec passed, sending USR1 to parent"
+    kill -USR1 $$
+}
+stub 3 &
+stub 2 &
+sleep 1
+until { echo "Waiting"; wait; } do
+    echo "Wait exit code: $?"
+done
+echo "Wait returned 0"

shell/hush_test/hush-signals/signal6.right

@@ -0,0 +1,2 @@
+got TERM
+Done: 0

shell/hush_test/hush-signals/signal6.tests

@@ -0,0 +1,2 @@
+{ trap "echo got TERM" TERM; sleep 3; }& sleep 1; kill $!; wait
+echo Done: $?

shell/hush_test/hush-signals/sigquit_exec.right

@@ -0,0 +1,2 @@
+SigIgn:	0000000000000000
+SigIgn:	0000000000000000

shell/hush_test/hush-signals/sigquit_exec.tests

@@ -0,0 +1,4 @@
+# Should show no masked signals in both cases.
+# We had a bug where SIGQUIT was masked on exec.
+grep SigIgn: /proc/self/status
+exec grep SigIgn: /proc/self/status

shell/hush_test/hush-standalone/noexec_gets_no_env.right

@@ -0,0 +1,4 @@
+VAR7=VAL
+0
+VAR8=VAL
+0

shell/hush_test/hush-standalone/noexec_gets_no_env.tests

@@ -0,0 +1,5 @@
+export VAR7=VAL
+env | grep ^VAR7=
+echo $?
+VAR8=VAL env | grep ^VAR8=
+echo $?

shell/hush_test/hush-standalone/nofork_trashes_getopt.right

@@ -0,0 +1 @@
+0

shell/hush_test/hush-standalone/nofork_trashes_getopt.tests

@@ -0,0 +1,6 @@
+# In this test, rm is NOFORK and it modifies getopt internal state
+rm -f non_existent_file
+# Subsequent hexdump is run as NOEXEC, and thus still uses this state
+hexdump </dev/null
+# Did hexdump segfault etc?
+echo $?

shell/hush_test/hush-standalone/var_standalone1.right

@@ -0,0 +1 @@
+Done: 1

shell/hush_test/hush-standalone/var_standalone1.tests

@@ -0,0 +1,2 @@
+VAR=42 $THIS_SH -c 'unset VAR; env | grep ^VAR'
+echo Done: $?