GNU bug report logs -
#5995
[PATCH] Fix exit status of signal handlers in shell scripts
Previous Next
Reported by: "Dmitry V. Levin" <ldv <at> altlinux.org>
Date: Wed, 21 Apr 2010 12:35:02 UTC
Severity: normal
Tags: patch
Done: Jim Meyering <jim <at> meyering.net>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
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.
--
ldv
[Message part 2 (application/pgp-signature, inline)]
This bug report was last modified 15 years and 26 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.