Re: localtraps

[Vincent Stemen <zsh@xxxxxxxxxxx>]

On Wed, Apr 27, 2005 at 02:09:31PM +0000, Bart Schaefer wrote:
> On Apr 27, 10:54am, Peter Stephenson wrote:
> }
> } OK, this one's fairly straightforward: starttrapscope() and
> } endtrapscope() don't run inside traps.
> 
> This works much better now, though there's still this extra newline
> being printed just before INNER on each alternate interrupt:
> ...
> 
> Plus the prompt not reprinted until accept-line or send-break, but that
> probably isn't a bug.
> 
> } Are we reasonably confident the other problems are specific to the
> } NetBSD style of signal handling?
> 
> I'm not confident of that, no.  Let's wait and see what Vincent has to
> say after this patch is applied.

Sorry about being a bit slow about getting back to you on this.
Thanks Bart for letting me know this thread was moved to zsh-workers.

I checked out zsh-4.2.5 from CVS and then updated to the
zsh-4_2-patches branch.

It still does not work correctly but the behavior has changed.
In the results below, I will refer to zsh-4.2.1 as "oldz" and the
patched 4.2.5 as "newz".

#======== <test script> ==========
sigterm1()
{
#   setopt LOCAL_TRAPS

    trap sigterm2 TERM
    echo "sigterm1(): sending SIGTERM"
    kill -s TERM $$
#   trap sigterm1 TERM
    sleep 1
}

sigterm2()
{
    echo "sigterm2()"
}

trap sigterm1 TERM

echo
echo "main: sending SIGTERM"
kill -s TERM $$
echo "main: sending SIGTERM"
kill -s TERM $$
#======== </test script> ==========

** Uncomment "setopt LOCAL_TRAPS"

<oldz>
main: sending SIGTERM
sigterm1(): sending SIGTERM
sigterm2()
main: sending SIGTERM
sigterm2()
</oldz>

As we already know, localtraps is ignored.

<newz>
main: sending SIGTERM
sigterm1(): sending SIGTERM
sigterm1(): sending SIGTERM
sigterm1(): sending SIGTERM
sigterm1(): sending SIGTERM
^C
</newz>

Continued indefinitely.  The "trap sigterm2 TERM" statement is ignored
when localtraps is on.


** Comment out "setopt LOCAL_TRAPS" and uncomment "trap sigterm1 TERM"
   in sigterm1() to try to accomplish the same thing without localopts.

<oldz>
main: sending SIGTERM
sigterm1(): sending SIGTERM
sigterm1(): sending SIGTERM
sigterm1(): sending SIGTERM
sigterm1(): sending SIGTERM
^C
</oldz>

<newz>
main: sending SIGTERM
sigterm1(): sending SIGTERM
sigterm1(): sending SIGTERM
sigterm1(): sending SIGTERM
sigterm1(): sending SIGTERM
^C
</newz>

<bsd sh>
main: sending SIGTERM
sigterm1(): sending SIGTERM
sigterm2()
main: sending SIGTERM
sigterm1(): sending SIGTERM
sigterm2()
</bsd sh>

newz is the same as oldz.

It works under BSD-sh because it processes the signal immediately so
that it does not execute the "trap sigterm1 TERM" before calling the
sig handler again.  This is the desired behavior.


On a side note, even though the binaries all seemed to compile OK, I
got a compilation error on NetBSD with 4.2.5 with the zsh-4_2-patches
that looks to me like a failure in generating the manuals.  Here is
the error.

-------------------------------------------------------------
rm -f zleparameter.so
gcc  -s -Wl,-x -shared --whole-archive -o zleparameter.so   zleparameter..o    -ltermcap
 -lm  -lc
(  echo 'STARTDEF()';  echo 'def(version)(0)('4.2.5')';  echo 'def(date)(0)(''April 6, 2
005'')';  echo 'ENDDEF()#' | tr '#' '\\';  ) > ./version.yo
case zsh.1 in  */*) target=zsh.1 ;;  *) target=./zsh.1 ;;  esac;  case ': yodl' in :*) ;
; *)  : yodl -I. -w zman.yo version.yo zsh.yo | sed -e '1s/\\-/-/g' -e '/^\.'\''/d' > $t
arget  ;; esac;  test -f $target
*** Error code 1

Stop.
make: stopped in /home/src/zsh-4.2.5-20050430/Doc
*** Error code 1

Stop.
make: stopped in /home/src/zsh-4.2.5-20050430
-------------------------------------------------------------


To compare the result, I compiled the 4.2.5 release and it ended without
error after the line,

-------------------------------------------------------------
gcc  -s -Wl,-x -shared --whole-archive -o zleparameter.so   zleparameter..o    -ltermcap
 -lm  -lc
-------------------------------------------------------------

So it is something in the latest patches.


-- 
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