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.
