Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: localtraps
- X-seq: zsh-users 8757
- From: Vincent Stemen <zsh@xxxxxxxxxxx>
- To: zsh-users@xxxxxxxxxx
- Subject: Re: localtraps
- Date: Mon, 25 Apr 2005 19:50:59 -0500
- In-reply-to: <1050425163202.ZM25027@xxxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-users-help@xxxxxxxxxx; run by ezmlm
- References: <20050425063521.GA17598@xxxxxxxxxxxxxxxxx> <1050425163202.ZM25027@xxxxxxxxxxxxxxxxxxxxxxx>
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)
and
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
zsh.
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
fix?
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.
#---------------------------------------------
#!/bin/zsh
sigterm1()
{
setopt LOCAL_TRAPS
trap sigterm2 TERM
echo "sigterm1(): sending SIGTERM"
kill -s TERM $$
}
sigterm2()
{
echo "sigterm2()"
}
trap sigterm1 TERM
echo
echo "main: sending SIGTERM"
kill -s TERM $$
echo "main: sending SIGTERM"
kill -s TERM $$
echo
#---------------------------------------------
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.
http://www.InetAddresses.net
Messages sorted by:
Reverse Date,
Date,
Thread,
Author