Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: localtraps

On Mon, Apr 25, 2005 at 04:32:02PM +0000, Bart Schaefer wrote:
> On Apr 25,  1:35am, Vincent Stemen wrote:
> } Subject: localtraps
> } 
> } I don't seem to be able to get the localtraps option to work.
> Try it where the outer function is NOT a trap for the same signal
> that you're trapping inside the function.
> I suspect that changing the trap of the same signal that is trapped
> is confusing the trap code, because low-level signal handling already
> requires that the signal handler restore itself before exiting, so in 
> effect you're restoring multiple different traps, and the order in
> which function exit and trap unwinding are processed is mixed up.

Thanks for the response.

Yes, You are correct.  I tested trapping a different signal in the
signal trap function and the localtraps option did indeed work.

I got the same result on
zsh 4.2.0 (i386-unknown-freebsd5.2.1)
zsh 4.0.7 (i386-redhat-linux-gnu)

(Except I had to re-write my test function to not run any additional
utilities such as sleep in order to properly test it on Linux because
of Linux's dumb signal handling.  It does not pass signals on to the
parent process like BSD does.)

On both, if I try to change the trap for the same signal in the trap
handler function with localtraps on, it ignores the new trap.

However, As I mentioned earlier, I get a different behavior on
zsh 4.2.1 (i386--netbsdelf)

It resets the signal trap, rather than ignoring it, but ignores the
localtraps option so that the new trap is still in effect after
exiting the function.

It seems to me that either behavior should be considered a bug in

This renders the localtraps option not useful to me much of the time
because I often need to temporarily disable or modify the function of
the same signal while I am in the signal handler processing it.

Is this an architectural problem with zsh that would be difficult to

To make it easier for anybody that wants to test it, here is my
re-written and improved test script that generates it's own signals.


    setopt LOCAL_TRAPS

    trap sigterm2 TERM
    echo "sigterm1(): sending SIGTERM"
    kill -s TERM $$

    echo "sigterm2()"

trap sigterm1 TERM

echo "main: sending SIGTERM"
kill -s TERM $$
echo "main: sending SIGTERM"
kill -s TERM $$


On the versions I mentioned above on Linux and FreeBSD this will
go into an endless loop printing
"sigterm1(): sending SIGTERM"
because the trap statement  in sigterm1() is ignored, unless you
comment out "setopt LOCAL_TRAPS".

Vincent Stemen
Avoid the VeriSign/Network Solutions domain registration trap!
Read how Network Solutions (NSI) was involved in stealing our domain name.

Messages sorted by: Reverse Date, Date, Thread, Author