bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ralf Wildenhues
Subject: Re: [PATCH] Fix exit status of signal handlers in shell scripts
Date: Sun, 31 Jan 2010 08:05:20 +0100
User-agent: Mutt/1.5.20 (2009-10-28)

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 it seems to be a widespread misunderstanding.
> 
> The GNU Autoconf manual says that "it is widely admitted that when
> entering the trap `$?' should be set to the exit status of the last
> command run before the trap."
> 
> In case of signal handler, the exit status of the last command run
> before the trap might be 128 + signal number, this usually happens when
> the last command before the trap was a process terminated by signal.  In
> other cases, the value of $? may be arbitrary.  Sometimes it's quite
> hard to guess this value due to race conditions.  Here is an example of
> such race condition where the value of $? takes one of 3 different
> values: 0, 1 and 143:

Can you please explain whose fault this is?  Is that a kernel issue, a
shell issue, or expected behavior given a POSIX system?  What system and
shell (version?) were your tests done on?  What are the "other cases"
you mention, where no process was terminated by the signal, but the
signal delivered somewhere nonethess?

Sounds like a race condition to me, and we should document it in
autoconf.texi after we have understood the underlying issue.

Thanks,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]