Re: a kill -TERM causes the EXIT trap to be executed

[Vincent Lefevre]

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?
#   -----------------------------------
#   bash    3.1.5(1)    yes
#   sh      (bash)      yes
#   dash    0.5.3       no
#   ksh93   1993-12-28  yes
#   mksh    R25         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.0            yes (/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 <vincent@vinc17.org> - 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