bug#5995: [PATCH] Fix exit status of signal handlers in shell scripts

[Jim Meyering]

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)/address@hidden'\''; (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.