On 09/28/2011 08:34 AM, Stefano Lattarini wrote:
Some Korn shells, when a child process die due to signal number n, can leave in $? an exit status of 256+n instead of the more standard 128+n. Apparently, both behaviours are allowed by POSIX,
Indeed. Here's some further reading: http://austingroupbugs.net/view.php?id=51 http://austingroupbugs.net/view.php?id=347 which includes: "Implementations are encouraged to choose exit values greater than 256 to indicate programs that terminate by a signal so that the exit status cannot be confused with an exit status generated by a normal termination." add "However, the use of exit values greater than 256 poses a problem for the shell's own exit status. Historically this was the exit status of the last command invoked by the shell, but if the last command was terminated by a signal and was assigned an exit status greater than 256 by the shell, this value would be truncated to eight bits in the shell's exit status. Likewise truncation would occur with use of exit $? or ret=$? .... exit $ret in shell scripts. To avoid this truncation, shells which assign exit statuses greater than 256 are required to propagate the wait status of the last command to the shell's own wait status (by sending itself the same signal), and to handle exit values greater than 256 passed to the exit builtin by mimicking the wait status that would give rise to assignment of that exit status in the shell. Note that this requirement does not apply to signals that do not cause termination, such as SIGCHLD, since the shell can never actually assign a corresponding exit status greater than 256, and the requirement is worded in terms of this assignment."
so be prepared to handle them both.
Yes, portability does demand we handle both. Also, would you mind preparing an autoconf patch to mention this?
-- Eric Blake ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org