hush testsuite: add many tests from ash testsuite

Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
This commit is contained in:
Denys Vlasenko
2016-10-02 17:39:31 +02:00
parent 888527ccee
commit 5d6b8729ed
34 changed files with 254 additions and 3 deletions

View File

@@ -0,0 +1 @@
Ok

View File

@@ -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

View File

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

View File

@@ -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

View File

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

View File

@@ -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"

View File

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

View File

@@ -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"

View File

@@ -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

View File

@@ -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"

View File

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

View File

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

View File

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

View File

@@ -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