Re: [PATCH] Fix exit status of signal handlers in shell scripts

On Mon, Feb 01, 2010 at 08:58:19AM +0100, Jim Meyering wrote: > Bruno Haible wrote: > > Jim Meyering wrote: > >> Imagine that the first 10 tests pass, then each of the remaining ones is > >> killed via e.g., SIGHUP. ... > >> a naive search for "FAIL:" in the build output would find nothing. > > > >

Re: [PATCH] Fix exit status of signal handlers in shell scripts

Bruno Haible wrote: > Jim Meyering wrote: >> Imagine that the first 10 tests pass, then each of the remaining ones is >> killed via e.g., SIGHUP. ... >> a naive search for "FAIL:" in the build output would find nothing. > > Yes, and it should be this way, IMO. Each time a user sees a "FAIL:", he >

Re: [PATCH] Fix exit status of signal handlers in shell scripts

Hi Bruno, thanks for the additional information. * Bruno Haible wrote on Sun, Jan 31, 2010 at 12:32:06PM CET: > Ralf Wildenhues asked: > > What are the "other cases" you mention, where no process was terminated > > by the signal, but the signal delivered somewhere nonethess? > > When I run >

Re: [PATCH] Fix exit status of signal handlers in shell scripts

* Dmitry V. Levin wrote on Sun, Jan 31, 2010 at 01:04:01PM CET: > On Sun, Jan 31, 2010 at 08:05:20AM +0100, Ralf Wildenhues wrote: > > Can you please explain whose fault this is? Is that a kernel issue, a > > shell issue, or expected behavior given a POSIX system? > > It is expected behaviour. >

Re: [PATCH] Fix exit status of signal handlers in shell scripts

On Sun, Jan 31, 2010 at 08:05:20AM +0100, Ralf Wildenhues wrote: > * Dmitry V. Levin wrote on Sat, Jan 30, 2010 at 08:12:01PM CET: > > There is a comment about shell signal handlers in gnulib-tool saying that > > "The value of $? is 128 + signal number and is set before the > > trap-registered comm

Re: [PATCH] Fix exit status of signal handlers in shell scripts

Jim Meyering wrote: > Imagine that the first 10 tests pass, then each of the remaining ones is > killed via e.g., SIGHUP. ... > a naive search for "FAIL:" in the build output would find nothing. Yes, and it should be this way, IMO. Each time a user sees a "FAIL:", he should be encouraged to invest

Re: [PATCH] Fix exit status of signal handlers in shell scripts

Ralf Wildenhues asked: > What system and shell (version?) were your tests done on? I could reproduce Dmitry's tests, with 'sleep 1' instead of 'sleep 0.01'. $ for i in `seq 0 9`; do sh -c 'trap "exit \$?" TERM; while /bin/true; do /bin/false; done' & pid=$! && sleep 1 && kill -TERM -$pid && wait

Re: [PATCH] Fix exit status of signal handlers in shell scripts

Dmitry V. Levin wrote: > On Sun, Jan 31, 2010 at 01:04:09AM +0100, Bruno Haible wrote: ... >> For the tests, I am inclined to provide the exit >> code '77' (= SKIP), rather than '1' (= FAIL): If a test is terminated >> by Ctrl-C, it has neither passed nor failed. > > Yes, it makes sense. Actually,

Re: [PATCH] Fix exit status of signal handlers in shell scripts

Hello Dmitry, * Dmitry V. Levin wrote on Sat, Jan 30, 2010 at 08:12:01PM CET: > There is a comment about shell signal handlers in gnulib-tool saying that > "The value of $? is 128 + signal number and is set before the > trap-registered command is run". Unfortunately, this comment is wrong, > and

Re: [PATCH] Fix exit status of signal handlers in shell scripts

Dmitry V. Levin wrote: > This would break the "If removal fails" statement. > Let's pass exit code to this function as an argument: > > remove_tmp_() > { > __st=$1 > [...] > trap 'remove_tmp_ $?' 0 Yes, you're right. Here's an updated proposed patch: 2010-01-30 Bruno Haible

Re: [PATCH] Fix exit status of signal handlers in shell scripts

On Sun, Jan 31, 2010 at 01:51:59AM +0100, Bruno Haible wrote: > Additionally, another proposed change prompted by Dmitry's patch. > > The Autoconf manual > > says: > "the state of ‘$?’ is not reliable when entering a sh

Re: [PATCH] Fix exit status of signal handlers in shell scripts

Dmitry V. Levin wrote: > > -trap 'rm -fr $tmpfiles' 1 2 3 15 > > +trap 'rm -fr $tmpfiles; exit 77' 1 2 3 15 > > According to "Limitations of Builtins" chapter in the autoconf > manual, plain "exit 77" is not portable; it has to be written > as "(exit 77); exit 77". Plain "exit 77" is not portable

Re: [PATCH] Fix exit status of signal handlers in shell scripts

On Sun, Jan 31, 2010 at 01:41:33AM +0100, Bruno Haible wrote: [...] > TMP_BASE=update-copyright.test > -trap 'rm -f $TMP_BASE*' 0 1 2 3 15 > +trap 'status=$?; rm -f $TMP_BASE*; exit $status' 0 > +trap 'rm -f $TMP_BASE*; (exit 77); exit 77' 1 2 3 15 The signal trap is a bit redundant, it could be

Re: [PATCH] Fix exit status of signal handlers in shell scripts

Additionally, another proposed change prompted by Dmitry's patch. The Autoconf manual says: "the state of ‘$?’ is not reliable when entering a shell function. This has the effect that using a function as the first co

Re: [PATCH] Fix exit status of signal handlers in shell scripts

Hi Jim, > I'll propose patches for gnulib-tool and most of the tests, and leave > bootstrap, tests/test-vc-list-files*.sh, tests/test-update-copyright.sh > to Jim. Here's a proposed patch for some of these: 2010-01-30 Bruno Haible Don't use $? in a trap handler for a signal.

Re: [PATCH] Fix exit status of signal handlers in shell scripts

On Sun, Jan 31, 2010 at 01:22:34AM +0100, Bruno Haible wrote: > Here is part 2 of the proposed fixes. [...] > -trap 'rm -fr $tmpfiles' 1 2 3 15 > +trap 'rm -fr $tmpfiles; exit 77' 1 2 3 15 According to "Limitations of Builtins" chapter in the autoconf manual, plain "exit 77" is not portable; it ha

Re: [PATCH] Fix exit status of signal handlers in shell scripts

On Sun, Jan 31, 2010 at 01:04:09AM +0100, Bruno Haible wrote: [...] > > Proposed patch is attached. > > Sorry, but I don't understand why you chose 143 as exit code, making it look > like the process died from SIGTERM when in fact in may have been SIGINT. > There seem to be two conventions for the

Re: [PATCH] Fix exit status of signal handlers in shell scripts

Here is part 2 of the proposed fixes. 2010-01-30 Bruno Haible Don't continue executing a test after catching a fatal signal. * tests/test-atexit.sh (trap 1-15): After removing the temporary files, exit with code 77. * tests/test-binary-io.sh (trap 1-15): Likewi

Re: [PATCH] Fix exit status of signal handlers in shell scripts

Here's part 1 of the fixes, as I would like to see it. Opinions? 2010-01-30 Bruno Haible Don't use $? in a trap handler for a signal. * gnulib-tool (trap 1-15): Exit with exit status 1. * MODULES.html.sh (trap 1-15): Likewise. Reported by Dmitry V. Levin . ---

Re: [PATCH] Fix exit status of signal handlers in shell scripts

Hi Dmitry, The 'trap' issue is complicated enough that, before answering your mail, I'd like to point out my understanding of the issue. Sources: - POSIX - Autoconf manual

[PATCH] Fix exit status of signal handlers in shell scripts

in/true; do /bin/false; done' Proposed patch is attached. It doesn't fix multiple trap bugs in the test suite, though: $ grep -r '\From ad41213f91021fcb15c91d236ec2395da76ae121 Mon Sep 17 00:00:00 2001 From: Dmitry V. Levin Date: Sat, 30 Jan 2010 15:07:14 + Subject: [PATCH] Fix