shell: remove duplicate sigint1.tests (another copies are in signals/)

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

shell/ash_test/ash-misc/sigint1.right

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

shell/ash_test/ash-misc/sigint1.tests

@@ -1,41 +0,0 @@
-# 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-misc/sigint1.right

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

shell/hush_test/hush-misc/sigint1.tests

@@ -1,41 +0,0 @@
-# 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