From: Jeff King <peff@peff.net>
To: git@vger.kernel.org
Subject: [PATCH 3/7] t: translate SIGINT to an exit
Date: Fri, 13 Mar 2015 00:48:48 -0400 [thread overview]
Message-ID: <20150313044848.GC18532@peff.net> (raw)
In-Reply-To: <20150313044101.GA18476@peff.net>
Right now if a test script receives SIGINT (e.g., because a
test was hanging and the user hit ^C), the shell exits
immediately. This can be annoying if the test script did any
global setup, like starting apache or git-daemon, as it will
not have an opportunity to clean up after itself. A
subsequent run of the test won't be able to start its own
daemon, and will either fail or skip the tests.
Instead, let's trap SIGINT to make sure we do a clean
shutdown, and just chain it to a normal exit (which will
trigger any cleanup).
Signed-off-by: Jeff King <peff@peff.net>
---
Possibly we should catch other signals here, too, but SIGINT is the one
that has been biting me over the years (I would sometimes have a stray
apache process hanging around, and I only recently figured out what
caused it).
I think "trap ... INT" is the most portable way to say this. I would
have thought numbers were more portable, but they are actually an XSI
add-on. Likewise, "SIGINT" is allowed in POSIX but not required. "INT"
is part of POSIX.
This is the cleanest way I could come up with to implement this. We
could also just include "INT" on the same line as the die, but:
1. Then every script which sets a handler (like lib-httpd.sh) would
need to be modified to munge the INT trap, too.
2. It double-calls die, then. We die from the INT handler, which
triggers the EXIT handler. I guess we could clear the handler
inside die() if we needed to.
So I'd rather go this route, unless there turns out to be a weird
portability problem.
t/test-lib.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index c096778..f4ba3ff 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -299,6 +299,7 @@ die () {
GIT_EXIT_OK=
trap 'die' EXIT
+trap 'exit $?' INT
# The user-facing functions are loaded from a separate file so that
# test_perf subshells can have them too
--
2.3.2.472.geadab3c
next prev parent reply other threads:[~2015-03-13 4:49 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-13 4:41 [PATCH 0/7] fix transfer.hiderefs with smart http Jeff King
2015-03-13 4:42 ` [PATCH 1/7] upload-pack: fix transfer.hiderefs over smart-http Jeff King
2015-03-13 6:21 ` Junio C Hamano
2015-03-13 4:42 ` [PATCH 2/7] upload-pack: do not check NULL return of lookup_unknown_object Jeff King
2015-03-13 4:48 ` Jeff King [this message]
2015-03-13 4:50 ` [PATCH 4/7] t: redirect stderr GIT_TRACE to descriptor 4 Jeff King
2015-03-13 4:51 ` [PATCH 5/7] t: pass GIT_TRACE through Apache Jeff King
2015-03-13 4:53 ` [PATCH 6/7] t5541: move run_with_cmdline_limit to test-lib.sh Jeff King
2015-03-13 6:45 ` Eric Sunshine
2015-03-13 4:57 ` [PATCH 7/7] t5551: make EXPENSIVE test cheaper Jeff King
2015-03-13 4:59 ` [PATCH 0/7] fix transfer.hiderefs with smart http Jeff King
2015-03-13 5:21 ` Duy Nguyen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150313044848.GC18532@peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).