GNU bug report logs - #5995
[PATCH] Fix exit status of signal handlers in shell scripts

Previous Next

Full log

View this message in rfc822 format

From: Jim Meyering <jim <at> meyering.net>
To: bug-coreutils <at> gnu.org
Subject: bug#5995: [PATCH] Fix exit status of signal handlers in shell scripts
Date: Wed, 21 Apr 2010 16:04:29 +0200

Dmitry V. Levin wrote:
> On Sat, Jan 30, 2010 at 11:52:31PM +0300, Dmitry V. Levin wrote:
>> On Sat, Jan 30, 2010 at 12:28:50PM -0700, Eric Blake wrote:
>> > According to Dmitry V. Levin on 1/30/2010 12:18 PM:
>> > > The value of `$?' on entrance to signal handlers in shell scripts
>> > > cannot be relied upon, so set the exit code explicitly to
>> > > 128 + SIGTERM == 143.
>> > > * src/Makefile.am (sc_tight_scope): Use `exit 143' in signal handler.
>> >
>> > I'm not sure I like the direction this is headed in.  Exiting with 143
>> > when a trap is known to be caused by SIGTERM might be okay, but it would
>> > be even better to reraise the signal and make the shell also exit by
>> > SIGTERM (in case the caller can distinguish between exit by signal and
>> > normal exit by status > 128).  But blindly giving status 143 for other
>> > signals, like SIGHUP, is just wrong.  If you are going to munge trap
>> > handlers to account for races, then you need one trap handler per signal
>> > with an appropriate exit status for each.
>>
>> One trap handler per signal is overkill in most cases.
>> I think that any non-zero exit status would be sufficient.
>
> I just want to remind you that the undefined behaviour still hasn't been
> fixed.  Please make a decision what kind of fix seems to be more suitable.

Thanks for the reminder.
I'd prefer a solution like the one used in automake:

http://git.savannah.gnu.org/cgit/automake.git/commit/?id=dbfabdfc6521979

    +am__trap='rm -f '\''$(abs_builddir)/$@-t'\''; (exit $$st); exit $$st'; \
    +trap "st=129; $$am__trap" 1; trap "st=130; $$am__trap" 2;      \
    +trap "st=141; $$am__trap" 13; trap "st=143; $$am__trap" 15; \

since it preserves signals, rather than mapping all to one,
which would inevitably produce misleading results some of the time.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.