Hi Eric, thanks for the links.
On Wednesday 28 September 2011, Eric Blake wrote:
> On 09/28/2011 08:34 AM, Stefano Lattarini wrote:
> > Some Korn shells, when a child process die due to signal number
> > n, can leave in $? an exit status of 256+n instead of the more
> > standard 128+n. Apparently, both behaviours are allowed by
> > POSIX,
>
> Indeed. Here's some further reading:
>
> http://austingroupbugs.net/view.php?id=51
>
Very useful: I've added a reference to it in the comments of
tap-driver.sh; see attached patch.
> http://austingroupbugs.net/view.php?id=347
>
This does not seem relevant for the issue under discussion to me. Maybe
wrong link? Or am I missing something?
> [SNIP]
>
> > so be prepared to handle them both.
>
> Yes, portability does demand we handle both. Also, would you mind
> preparing an autoconf patch to mention this?
>
Patch coming up soonish (hopefully this evening, otherwise in a couple
of days).
Regards,
Stefano
From 5014b1c294a4b8982ab3c7c78e2272fdcdff468d Mon Sep 17 00:00:00 2001
Message-Id: <5014b1c294a4b8982ab3c7c78e2272fdcdff468d.1317235712.git.stefano.lattar...@gmail.com>
From: Stefano Lattarini <stefano.lattar...@gmail.com>
Date: Wed, 28 Sep 2011 20:48:13 +0200
Subject: [PATCH] tap/awk: improve comments about Korn shell signal handling issues
* lib/tap-driver.sh: Link an Austin Group discussion about how
shells are allowed, and even encouraged, to set the special
variable `$?' to values greater than 256 to report termination
of a child by a signal. Improve and extend comments about our
workarounds for unusual korn shell signals' propagation.
Thanks to Eric Blake for the pointers.
---
ChangeLog | 10 ++++++++++
lib/tap-driver.sh | 18 +++++++++++-------
2 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index c28f9e4..7a78db6 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,15 @@
2011-09-28 Stefano Lattarini <stefano.lattar...@gmail.com>
+ tap/awk: improve comments about Korn shell signal handling issues
+ * lib/tap-driver.sh: Link an Austin Group discussion about how
+ shells are allowed, and even encouraged, to set the special
+ variable `$?' to values greater than 256 to report termination
+ of a child by a signal. Improve and extend comments about our
+ workarounds for unusual korn shell signals' propagation.
+ Thanks to Eric Blake for the pointers.
+
+2011-09-28 Stefano Lattarini <stefano.lattar...@gmail.com>
+
maintcheck: fix usage of `cd' instead of `$(am__cd)'
* lib/am/inst-vars.am (am__uninstall_files_from_dir): Use
`$(am__cd)', not plain `cd'.
diff --git a/lib/tap-driver.sh b/lib/tap-driver.sh
index e9f1037..c911991 100755
--- a/lib/tap-driver.sh
+++ b/lib/tap-driver.sh
@@ -117,14 +117,17 @@ fi
{
(
- # Ignore common signals (in this subshell only!) to avoid potential
+ # Ignore common signals (in this subshell only!), to avoid potential
# problems with Korn shells. Some Korn shells are known to propagate
# to themselves signals that have killed a child process they were
- # waiting for (this is done at least for SIGINT -- and usually only
- # for it in truth); this would cause a premature exit in this subshell,
- # so that the awk script would never seen the exit status it expects
- # on its last input line (and which is displayed below by the last
- # `echo $?' command), and would thus die reporting an internal error.
+ # waiting for; this is done at least for SIGINT (and usually only for
+ # it, in truth). Without the `trap' below, such a behaviour could
+ # cause a premature exit in the current subshell, e.g., in case the
+ # test command it runs gets terminated by a SIGINT. Thus, the awk
+ # script we are piping into would never seen the exit status it
+ # expects on its last input line (which is displayed below by the
+ # last `echo $?' statement), and would thus die reporting an internal
+ # error.
# For more information, see the Autoconf manual and the threads:
# <http://lists.gnu.org/archive/html/bug-autoconf/2011-09/msg00004.html>
# <http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2009-February/004121.html>
@@ -458,7 +461,8 @@ function get_test_exit_message(status)
# shells, when a child process die due to signal number n, can leave
# in $? an exit status of 256+n instead of the more standard 128+n.
# Apparently, both behaviours are allowed by POSIX (2008), so be
- # prepared to handle them both.
+ # prepared to handle them both. See also Austing Group report ID
+ # 0000051 <http://www.austingroupbugs.net/view.php?id=51>
exit_details = sprintf(" (terminated by signal %d?)", status - 256)
else
# Never seen in practice.
--
1.7.2.3
