On 2006-01-26 23:34:31 -0700, Bob Proulx wrote:
Vincent Lefevre wrote:
An EXIT trap is executed when the process is killed, e.g. by the
SIGTERM signal, which breaks traditional sh compatibility
A lot of POSIX required behavior breaks traditional Bourne sh
compatibility.
I know, but if it is not a POSIX requirement, it is annoying to
break the Bourne sh compatibility.
and, IMHO, is not POSIX-compliant (see the explanations in the
script below). Other shells, such as dash, ksh and zsh are not
affected by this problem.
ksh handles this the same way as bash. Perhaps you tested with pdksh?
OK, here are my latest tests:
# Results on Linux/x86 (Debian):
# Shell Version pterm executed?
# ---
# bash3.1.5(1)yes
# sh (bash) yes
# dash0.5.3 no
# ksh93 1993-12-28 yes
# mkshR25 no
# pdksh 5.2.14 no
# zsh 4.3.0-dev-2 no
#
# Under other systems:
# OS / Shell pterm executed?
# ---
# SunOS 5.7 yes (/usr/xpg4/bin/sh)
# OSF1 4.0yes (/usr/bin/posix/sh)
# FreeBSD 5.4 (=dash) no
# NetBSD 3.0 (=dash) no
# HP-UX B.11.11 yes
Note: I know that dash is not POSIX yet.
With the following script, sh trapexitbug (under Linux) and
bash trapexitbug cause the EXIT trap to be executed.
It has been a long time POSIX shell requirement that the EXIT trap is
executed upon shell exit regardless of why that shell exited. This is
intentional.
Does anyone has some *clear* reference about that? After re-reading
some parts of POSIX, it appears that it is not clear. POSIX says that
the exit utility causes the trap on EXIT to be executed before the
shell terminates (except when the exit utility is invoked in that trap
itself). But it doesn't seem to say more.
Also concerning the regardless of why that shell exited, the EXIT
trap cannot be called if the shell terminates due to a SIGKILL. From
this point of view, what you said cannot be completely correct.
# http://www.opengroup.org/onlinepubs/009695399/basedefs/signal.h.html
# says:
# SIGTERM T Termination signal.
# and for T:
# Abnormal termination of the process. The process is terminated
# with all the consequences of _exit() except that the status made
# available to wait() and waitpid() indicates abnormal termination
# by the specified signal.
#
# http://www.opengroup.org/onlinepubs/009695399/functions/_exit.html says:
# The _Exit() [CX] and _exit() functions shall not call functions
# registered with atexit() nor any registered signal handlers.
That is the default action. But once you set an EXIT trap you change
the default action to the one specified in the trap. So those
requirements no longer apply.
This is the default action for SIGTERM. But concerning _exit,
I haven't seen that it was a default action. Could you give
more details or do you have a precise reference?
A last point: If POSIX allows the current behavior, when should
the signal be taken into account? I give an example below to make
my question clearer:
pterm()
{
trap 0
echo pterm: $foo
}
trap pterm 0
echo PID = $$
while true; do read foo; printf %s\n $foo; done
Currently, the TERM signal interrupts the read built-in.
But what if $foo was being modified when the signal occurs?
--
Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/
100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
