Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Weird exit caused in a trap DEBUG which sources a file.
- X-seq: zsh-workers 25368
- From: "Rocky Bernstein" <rocky.bernstein@xxxxxxxxx>
- To: zsh-workers@xxxxxxxxxx
- Subject: Re: Weird exit caused in a trap DEBUG which sources a file.
- Date: Fri, 1 Aug 2008 11:21:50 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=XZ9rWOiecZE0dqGUw+mTyyolB/RpITMnbOytBqL8mQw=; b=jVQ4isOSffJEF8n2ECfJZFoD9ZHUmICvXIFMVXv6XsBJLBb8jQsWF2AbZ7PbZDx4Bm BjeBZw8Cu4OhQ2I/jlHDIBNYDOfCaxxim6ghix2GVCr7PR7RRMVM2e1pbIGjkz6ztH0C ihWfMDOxIS2fx2LogMj9ApMTXXqCqxcgdIjvU=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=p5poDDZy8asgfyeNL2ZkqsmHo+Exdb49Cy/vtBGkih7BhrJavQ1BTwl9HF+FzdlDBV uVC/PoaSfY4d/W/P6l3cikg8HjIYxDtofdrd/L+gLLR/1RWn9IzkO/C21+Y83u1q1EKv VUd3PL18Nqk1dIfHsLiV0gd7MnFQ3+GVRpOtE=
- In-reply-to: <20080801143747.19b65086@news01>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <6cd6de210807301938m28e05c84vf6296aa5b1bc0d44@xxxxxxxxxxxxxx> <200807310901.m6V91g8T002478@xxxxxxxxxxxxxx> <6cd6de210807310305q5954b65ax405f51e54d6754ee@xxxxxxxxxxxxxx> <6cd6de210808010529h11898619kba301fddf8b72f00@xxxxxxxxxxxxxx> <20080801143747.19b65086@news01>
Comments in line.
On Fri, Aug 1, 2008 at 9:37 AM, Peter Stephenson <pws@xxxxxxx> wrote:
> On Fri, 1 Aug 2008 08:29:29 -0400
> "Rocky Bernstein" <rocky.bernstein@xxxxxxxxx> wrote:
>> Looks like the crucial change that makes zsh 4.3.5-dev and current SVN
>> sources fail is an extra source after the trap DEBUG:
>
> Thanks, this is what I needed.
No, thank you! I just tried the patch and it works fine.
So there's no mystery. I've been porting the bash debugger code to
zsh. So far, print/eval, stepping and some stack frame commands work.
But this is far from ready for general consumption.
Part of this is a more general effort at writing about POSIX shells
which I give maybe a 50% chance of happening.
>
> The source code wasn't handling the variable that indicates a trap has told
> us to return from a function properly. The variable is only primed for
> action if negative. That's the init.c hunk.
>
> The signals.c hunk is to save and restore trapreturn for nested trap
> handlers. I'm not sure it's necessary; I am sure it's not wrong and
> prevents hostages to fortune.
Not sure the additional code is necessary or that nested trap handlers
are necessary? I'm pretty sure you mean the former. Nested trap
handlers are useful.
>
> The hairy trap tests still pass, which is good; it would be better to add
> this as a test, too, which shouldn't be too hard as there's nothing here
> that depends on external behaviour.
>
> I've documented the variable trapreturn better.
Thanks. It seems weird that trapreturn is is initialised to -1 for a
function trap and
-2 for a non-function trap and decremented for subsequent function
calls. Because this means that trapreturn for a for a function trap
that calls a function would have the same value as for a non-function
trap.
>
> Index: Src/exec.c
> ===================================================================
> RCS file: /cvsroot/zsh/zsh/Src/exec.c,v
> retrieving revision 1.135
> diff -u -r1.135 exec.c
> --- Src/exec.c 31 Jul 2008 08:44:21 -0000 1.135
> +++ Src/exec.c 1 Aug 2008 13:29:06 -0000
> @@ -64,7 +64,23 @@
> /**/
> mod_export int errflag;
>
> -/* Status of return from a trap */
> +/*
> + * Status of return from a trap.
> + * This is only active if we are inside a trap, else its value
> + * is irrelevant. It is initialised to -1 for a function trap and
> + * -2 for a non-function trap and if negative is decremented as
> + * we go deeper into functions and incremented as we come back up.
> + * The value is used to decide if an explicit "return" should cause
> + * a return from the caller of the trap; it does this by setting
> + * trapreturn to a status (i.e. a non-negative value).
> + *
> + * In summary, trapreturn is
> + * - zero unless we are in a trap
> + * - negative in a trap unless it has triggered. Code uses this
> + * to detect an active trap.
> + * - non-negative in a trap once it was triggered. It should remain
> + * non-negative until restored after execution of the trap.
> + */
>
> /**/
> int trapreturn;
> Index: Src/init.c
> ===================================================================
> RCS file: /cvsroot/zsh/zsh/Src/init.c,v
> retrieving revision 1.87
> diff -u -r1.87 init.c
> --- Src/init.c 31 Jul 2008 08:44:21 -0000 1.87
> +++ Src/init.c 1 Aug 2008 13:29:06 -0000
> @@ -191,7 +191,7 @@
> exit(lastval);
> if (((!interact || sourcelevel) && errflag) || retflag)
> break;
> - if (trapreturn) {
> + if (trapreturn >= 0) {
> lastval = trapreturn;
> trapreturn = 0;
> }
> Index: Src/signals.c
> ===================================================================
> RCS file: /cvsroot/zsh/zsh/Src/signals.c,v
> retrieving revision 1.47
> diff -u -r1.47 signals.c
> --- Src/signals.c 31 Jul 2008 08:44:21 -0000 1.47
> +++ Src/signals.c 1 Aug 2008 13:29:06 -0000
> @@ -1085,6 +1085,7 @@
> int trapret = 0;
> int obreaks = breaks;
> int oretflag = retflag;
> + int otrapreturn = trapreturn;
> int isfunc;
> int traperr;
>
> @@ -1183,6 +1184,7 @@
> trapret = trapreturn + 1;
> }
> traperr = errflag;
> + trapreturn = otrapreturn;
> execrestore();
> lexrestore();
>
>
> --
> Peter Stephenson <pws@xxxxxxx> Software Engineer
> CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
> Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070
>
Messages sorted by:
Reverse Date,
Date,
Thread,
Author