Re: trap for EXIT doesn't catch exit?

Re: trap for EXIT doesn't catch exit?

[Bart Schaefer]

On Sep 18, 12:28pm, Peter Stephenson wrote:
> 
> Probably the correct thing to do here is to pop all the saved EXIT's off
> the stack of saved traps, executing them one by one, to simulate exiting
> the scope of each function in turn.  I'll wait to see if there are comments
> before I do that (further discussion should probably go to zsh-workers).

I don't think it's sufficient to simulate exiting the scopes, because the
traps have to execute as if they're in the scope where they were installed.
It may be necessary to actually unwind the stack; at least it's necessary
to call endparamscope() and endtrapscope() the correct number of times.

The problem is really with the overloading of the exit trap for both return
from a function and exit from the shell.  In bash, for example, the exit
trap is never called when a function returns, only when the shell exits.
On the other hand, bash doesn't have the notion of local traps; changing a
trap in a bash function changes it globally, and it is not restored when
the function returns.

We may want to bring this up on the shell@research.att.com list.

Re: trap for EXIT doesn't catch exit?

[Peter Stephenson]

Bart Schaefer wrote:
> I don't think it's sufficient to simulate exiting the scopes, because the
> traps have to execute as if they're in the scope where they were installed.
> It may be necessary to actually unwind the stack; at least it's necessary
> to call endparamscope() and endtrapscope() the correct number of times.

Yes, that eventually occurred to me.

> We may want to bring this up on the shell@research.att.com list.

Possibly a good idea, but the other shells' behaviour, having an exit trap
only for the shell, already seems to be standard.  We would need to treat
it specially as an option.  It's a bit of pain because this works

18:34% ksh
$ foo() { trap 'echo exit' EXIT; }
$ foo
$ exit
exit

while most (or maybe all) other traps in ksh are local.  That is, at least,
an argument for our way of doing it.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

PATCH: trap for EXIT doesn't catch exit?

[Peter Stephenson]

Bart Schaefer wrote:
> I don't think it's sufficient to simulate exiting the scopes, because the
> traps have to execute as if they're in the scope where they were installed.
> It may be necessary to actually unwind the stack; at least it's necessary
> to call endparamscope() and endtrapscope() the correct number of times.

Unwinding the stack is a whole load of code embedded in two separate (C)
functions, but you do need quite a lot of it to make sure the traps get a
consistent environment.

Here's a first go at a simple strategy which I'm not completely convinced
about yet: mark that we need to exit and return from all shell functions
using the normal return code, then exit when we've left the last function.
Comments, particularly in zexit(), will need to be improved.  It seems to
do the basics, and to get right the interaction with `stopmsg', which is
one of the things I'm least happy about, partly because that variable is
already scattered through too much of the code.

Another question is whether I should be combining the new exit_pending flag
and the existing in_exit somehow.

By the way, coincidentally I assume, David Korn addressed the issue of the
scope for the EXIT trap on the shell list --- it's part of a set of
compatibility problems with POSIX-style functions.

I tested it with this:

% ./zsh
% fn() { trap 'echo Bar' EXIT; exit 3; print Not reached; }
% fn2() { trap 'echo Again' EXIT; fn; print Not reached; }
% trap 'echo Foo' EXIT
% fn2; print Not reached
Bar
Again
Foo

(and the exit status is 3).  This could go in the test suite.

Index: Src/builtin.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/builtin.c,v
retrieving revision 1.53
diff -u -r1.53 builtin.c
--- Src/builtin.c	2001/09/18 17:50:26	1.53
+++ Src/builtin.c	2001/09/19 10:30:52
@@ -3208,6 +3208,10 @@
 
 /**/
 int
+exit_pending;
+
+/**/
+int
 bin_break(char *name, char **argv, char *ops, int func)
 {
     int num = lastval, nump = 0;
@@ -3248,10 +3252,16 @@
 	    zerrnam(name, "not login shell", NULL, 0);
 	    return 1;
 	}
-	zexit(num, 0);
-	break;
+	/*FALLTHROUGH*/
     case BIN_EXIT:
-	zexit(num, 0);
+	if (locallevel) {
+	    if (stopmsg || (zexit(0,2), !stopmsg)) {
+		retflag = 1;
+		breaks = loops;
+		exit_pending = (num << 1) | 1;
+	    }
+	} else
+	    zexit(num, 0);
 	break;
     }
     return 0;
@@ -3295,11 +3305,11 @@
 
 /**/
 mod_export void
-zexit(int val, int from_signal)
+zexit(int val, int from_where)
 {
     static int in_exit;
 
-    if (isset(MONITOR) && !stopmsg && !from_signal) {
+    if (isset(MONITOR) && !stopmsg && from_where != 1) {
 	scanjobs();    /* check if jobs need printing           */
 	if (isset(CHECKJOBS))
 	    checkjobs();   /* check if any jobs are running/stopped */
@@ -3308,12 +3318,12 @@
 	    return;
 	}
     }
-    if (in_exit++ && from_signal)
+    if (from_where == 2 || (in_exit++ && from_where))
 	    return;
 
     if (isset(MONITOR)) {
 	/* send SIGHUP to any jobs left running  */
-	killrunjobs(from_signal);
+	killrunjobs(from_where == 1);
     }
     if (isset(RCS) && interact) {
 	if (!nohistsave)
Index: Src/exec.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/exec.c,v
retrieving revision 1.36
diff -u -r1.36 exec.c
--- Src/exec.c	2001/08/19 04:23:46	1.36
+++ Src/exec.c	2001/09/19 10:30:52
@@ -3429,6 +3429,16 @@
     if (noreturnval)
 	lastval = oldlastval;
     popheap();
+
+    if (exit_pending) {
+	if (locallevel) {
+	    retflag = 1;
+	    breaks = loops;
+	} else {
+	    stopmsg = 1;
+	    zexit(exit_pending >> 1, 0);
+	}
+    }
 }
 
 /* This finally executes a shell function and any function wrappers     *

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: PATCH: trap for EXIT doesn't catch exit?

[Peter Stephenson]

Peter Stephenson wrote:
> Here's a first go at a simple strategy which I'm not completely convinced
> about yet: mark that we need to exit and return from all shell functions
> using the normal return code, then exit when we've left the last function.

I've checked this in with extra comments but no code changes (you'll have
to back the patch out before updating if you have it in).  It doesn't look
like any alternative strategy is about to emerge.

I'll try and remember to construct a test.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************