Weird exit caused in a trap DEBUG which sources a file.

Weird exit caused in a trap DEBUG which sources a file.

[Rocky Bernstein]

Below is a small program whittled down from a larger one. It has
behavior I can't figure out.

It seems to show that when a function is called via trap DEBUG and you
then source a file and it has a statement in it, on return from the
TRAP an exit will be taken.  Here is the program:

#!/usr/bin/zsh
function debug_trap_handler {
    print $functrace[1]
    do_bug
}

function do_bug {
   . ./bug-file
}

trap 'echo EXIT hit' EXIT
trap 'debug_trap_handler' DEBUG
a=1
b=2
d=3

In "bug-file" put any command. ":" will do. Or a print statement.
Let's say it contains the line:
print bug file here

When I run the above I get:

$ ./zshtrace.sh

./zshtrace.sh:12
bug file here
EXIT hit

Now if the file contains only comments or blank lines or is empty,
here is what I get:
$ ./zshtrace.sh
./zshtrace.sh:12
./zshtrace.sh:13
./zshtrace.sh:14
./zshtrace.sh:15
EXIT hit

which is what I would expect.

Anyone care to venture a guess as to what's going on? It feels like a
bug to me, if for no other reason than some message about why the exit
was raised is missing.

Thanks.

Re: Weird exit caused in a trap DEBUG which sources a file.

[Peter Stephenson]

"Rocky Bernstein" wrote:
> Below is a small program whittled down from a larger one. It has
> behavior I can't figure out.
> 
> It seems to show that when a function is called via trap DEBUG and you
> then source a file and it has a statement in it, on return from the
> TRAP an exit will be taken.  Here is the program:
> 
> #!/usr/bin/zsh
> function debug_trap_handler {
>     print $functrace[1]
>     do_bug
> }
> 
> function do_bug {
>    . ./bug-file
> }
> 
> trap 'echo EXIT hit' EXIT
> trap 'debug_trap_handler' DEBUG
> a=1
> b=2
> d=3
> 
> In "bug-file" put any command. ":" will do. Or a print statement.
> Let's say it contains the line:
> print bug file here
> 
> When I run the above I get:
> 
> $ ./zshtrace.sh
> 
> ./zshtrace.sh:12
> bug file here
> EXIT hit

That certainly looks like a bug, but it didn't happen for me.  What
version of the shell do you have, and does it happen with the -f option
after /usr/bin/zsh?

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070

Re: Weird exit caused in a trap DEBUG which sources a file.

[Rocky Bernstein]

I don't get different results by adding -f. However I do get different
results depending on the zsh version.

The buggy output was run using the stock zsh for Ubunty Hardy Heron:
zsh 4.3.4 (i686-pc-linux-gnu)

I don't get it for the "zsh-beta" package which is
zsh 4.3.5-dev-0+ (i686-pc-linux-gnu)

Life would be good were that were the end of the story.

This is this is whittled down from a larger set of files, and in that
larger set, I still have the problem no matter which of the above two
zsh's is used or a third or the one I built from recent CVS with the
patches I posted applied. So it looks like I'll have to go back and
start again from the larger program and whittle it down again.

If anyone is aware of what bug was fixed between 4.3.4 and 4.3.5-dev-0
that addresses this, it might help understand the nature of the
problem better. (I will also at some point scour ChangeLogs to try to
figure this out too.)

Thanks for double checking and the suggestions.


On Thu, Jul 31, 2008 at 5:01 AM, Peter Stephenson <pws@csr.com> wrote:
> "Rocky Bernstein" wrote:
>> Below is a small program whittled down from a larger one. It has
>> behavior I can't figure out.
>>
>> It seems to show that when a function is called via trap DEBUG and you
>> then source a file and it has a statement in it, on return from the
>> TRAP an exit will be taken.  Here is the program:
>>
>> #!/usr/bin/zsh
>> function debug_trap_handler {
>>     print $functrace[1]
>>     do_bug
>> }
>>
>> function do_bug {
>>    . ./bug-file
>> }
>>
>> trap 'echo EXIT hit' EXIT
>> trap 'debug_trap_handler' DEBUG
>> a=1
>> b=2
>> d=3
>>
>> In "bug-file" put any command. ":" will do. Or a print statement.
>> Let's say it contains the line:
>> print bug file here
>>
>> When I run the above I get:
>>
>> $ ./zshtrace.sh
>>
>> ./zshtrace.sh:12
>> bug file here
>> EXIT hit
>
> That certainly looks like a bug, but it didn't happen for me.  What
> version of the shell do you have, and does it happen with the -f option
> after /usr/bin/zsh?
>
> --
> Peter Stephenson <pws@csr.com>                  Software Engineer
> CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
> Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070
>

Re: Weird exit caused in a trap DEBUG which sources a file.

[Rocky Bernstein]

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:


#!/bin/zsh-beta -f
function debug_trap_handler {
   print $functrace[1]
  . ./bug-file
}

trap 'echo EXIT hit' EXIT
trap 'debug_trap_handler' DEBUG
. ./testing.sh

Put in ./testing.sh and bug-file some executable code. You probably
want to have several statements in testing.sh so you can see exiting
after the first statement.



On Thu, Jul 31, 2008 at 6:05 AM, Rocky Bernstein
<rocky.bernstein@gmail.com> wrote:
> I don't get different results by adding -f. However I do get different
> results depending on the zsh version.
>
> The buggy output was run using the stock zsh for Ubunty Hardy Heron:
> zsh 4.3.4 (i686-pc-linux-gnu)
>
> I don't get it for the "zsh-beta" package which is
> zsh 4.3.5-dev-0+ (i686-pc-linux-gnu)
>
> Life would be good were that were the end of the story.
>
> This is this is whittled down from a larger set of files, and in that
> larger set, I still have the problem no matter which of the above two
> zsh's is used or a third or the one I built from recent CVS with the
> patches I posted applied. So it looks like I'll have to go back and
> start again from the larger program and whittle it down again.
>
> If anyone is aware of what bug was fixed between 4.3.4 and 4.3.5-dev-0
> that addresses this, it might help understand the nature of the
> problem better. (I will also at some point scour ChangeLogs to try to
> figure this out too.)
>
> Thanks for double checking and the suggestions.
>
>
> On Thu, Jul 31, 2008 at 5:01 AM, Peter Stephenson <pws@csr.com> wrote:
>> "Rocky Bernstein" wrote:
>>> Below is a small program whittled down from a larger one. It has
>>> behavior I can't figure out.
>>>
>>> It seems to show that when a function is called via trap DEBUG and you
>>> then source a file and it has a statement in it, on return from the
>>> TRAP an exit will be taken.  Here is the program:
>>>
>>> #!/usr/bin/zsh
>>> function debug_trap_handler {
>>>     print $functrace[1]
>>>     do_bug
>>> }
>>>
>>> function do_bug {
>>>    . ./bug-file
>>> }
>>>
>>> trap 'echo EXIT hit' EXIT
>>> trap 'debug_trap_handler' DEBUG
>>> a=1
>>> b=2
>>> d=3
>>>
>>> In "bug-file" put any command. ":" will do. Or a print statement.
>>> Let's say it contains the line:
>>> print bug file here
>>>
>>> When I run the above I get:
>>>
>>> $ ./zshtrace.sh
>>>
>>> ./zshtrace.sh:12
>>> bug file here
>>> EXIT hit
>>
>> That certainly looks like a bug, but it didn't happen for me.  What
>> version of the shell do you have, and does it happen with the -f option
>> after /usr/bin/zsh?
>>
>> --
>> Peter Stephenson <pws@csr.com>                  Software Engineer
>> CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
>> Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070
>>
>

Re: Weird exit caused in a trap DEBUG which sources a file.

[Peter Stephenson]

On Fri, 1 Aug 2008 08:29:29 -0400
"Rocky Bernstein" <rocky.bernstein@gmail.com> 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.

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.

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.

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@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070

Re: Weird exit caused in a trap DEBUG which sources a file.

[Rocky Bernstein]

Comments in line.

On Fri, Aug 1, 2008 at 9:37 AM, Peter Stephenson <pws@csr.com> wrote:
> On Fri, 1 Aug 2008 08:29:29 -0400
> "Rocky Bernstein" <rocky.bernstein@gmail.com> 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@csr.com>                  Software Engineer
> CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
> Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070
>

Re: Weird exit caused in a trap DEBUG which sources a file.

[Peter Stephenson]

"Rocky Bernstein" wrote:
> On Fri, Aug 1, 2008 at 9:37 AM, Peter Stephenson <pws@csr.com> wrote:
> > Thanks, this is what I needed.
> 
> No, thank you! I just tried the patch and it works fine.

Good.

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

This will be very useful.

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

Yes, I'm talking about the additional code.  I think it probably *is*
necessary for consistency, but there are cases where we disable nested
handling (so for example we don't run a DEBUG trap on commands when
we're inside a DEBUG trap).

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

This is because of the way an explicit "return" from a trap works (which
is documented in the manual).  "return" with non-zero status from a
shell function forces the parent function to return; "return" with any
status from a non-function trap forces the immediately surrounding
function to return.  In other words, the difference is there's an extra
level of functions in one case which we have to jump over for the
special return.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070

Re: Weird exit caused in a trap DEBUG which sources a file.

[Rocky Bernstein]

Hmm. This brings up a couple of other things to consider.

It may be useful to have some "trap DEBUG" exit codes alter program
flow. For example in bash if "trap DEBUG" returns 2, then if you are
inside a function that does an immediate return from the function
(implementing a gdb "return" command).
It might also be nice to have a "trap DEBUG" exit value which
indicates that the next command is skipped rather than executed.

Of course, this makes more sense when "trap DEBUG" is run before a
statement is executed rather than after, because doing these things
when you don't really know what the next statement is or which
function you are in is like flying blind.

And since I brought up "trap DEBUG" execution order again, at the risk
of beating a dead horse...

I recently asked David Korn about this:

me:  I guess what I was asking is why it originally kicked in afterwards
 rather than before. This one seemingly innocuous thing is one of the
 biggest things that kept writing a serious debugger impossible. (But
 of course as perhaps you may understand, there are others that still
 make it hard.)

David Korn: That was a mistake which is why I changed it.

I also recall suggesting to Chet Ramey that another trap could be
added like "trap DEBUG" if compatibility was at issue. Although I
never got a reply, he too didn't try to keep the previous behavior
which suggests, like David Korn, he thought it just wrong. In neither
case am I aware of any outcry of incompatibility because this behavior
was changed.


On Fri, Aug 1, 2008 at 11:31 AM, Peter Stephenson <pws@csr.com> wrote:
>
> This is because of the way an explicit "return" from a trap works (which
> is documented in the manual).  "return" with non-zero status from a
> shell function forces the parent function to return; "return" with any
> status from a non-function trap forces the immediately surrounding
> function to return.  In other words, the difference is there's an extra
> level of functions in one case which we have to jump over for the
> special return.
>
> --
> Peter Stephenson <pws@csr.com>                  Software Engineer
> CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
> Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070
>

Re: Weird exit caused in a trap DEBUG which sources a file.

[Peter Stephenson]

On Sat, 2 Aug 2008 07:21:43 -0400
"Rocky Bernstein" <rocky.bernstein@gmail.com> wrote:
> 
> It may be useful to have some "trap DEBUG" exit codes alter program
> flow. For example in bash if "trap DEBUG" returns 2, then if you are
> inside a function that does an immediate return from the function
> (implementing a gdb "return" command).

This happens on any explicit "return" from a non-function trap.

> It might also be nice to have a "trap DEBUG" exit value which
> indicates that the next command is skipped rather than executed.

That's a little more tricky:  it's not very clear what the next command
actually is if it's a complicated expression.  Looking at the code, it's
not hard to do something here, but making it properly consistent is
another matter.  I think it would probably work if done at the level of
commands separated by semicolons, newlines or ampersands (described
internally as sublists).

> And since I brought up "trap DEBUG" execution order again, at the risk
> of beating a dead horse...

I don't really understand what the issue is.  Is there something about
the DEBUG_BEFORE_CMD option that makes it hard to ensure it is set at
the right point (this is not a trick question, that's perfectly
possible)?

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: Weird exit caused in a trap DEBUG which sources a file.

[Rocky Bernstein]

Comments in line.

On Sun, Aug 3, 2008 at 6:42 AM, Peter Stephenson
<p.w.stephenson@ntlworld.com> wrote:
> On Sat, 2 Aug 2008 07:21:43 -0400
> "Rocky Bernstein" <rocky.bernstein@gmail.com> wrote:
>>
>> It may be useful to have some "trap DEBUG" exit codes alter program
>> flow. For example in bash if "trap DEBUG" returns 2, then if you are
>> inside a function that does an immediate return from the function
>> (implementing a gdb "return" command).
>
> This happens on any explicit "return" from a non-function trap.
>
>> It might also be nice to have a "trap DEBUG" exit value which
>> indicates that the next command is skipped rather than executed.
>
> That's a little more tricky:  it's not very clear what the next command
> actually is if it's a complicated expression.  Looking at the code, it's
> not hard to do something here, but making it properly consistent is
> another matter.  I think it would probably work if done at the level of
> commands separated by semicolons, newlines or ampersands (described
> internally as sublists).

I do not see why this is semantically complicated when the trap DEBUG
occurs before the statement it refers to is run.  Can you give a very
specific example of something you feel is tricky?

>
>> And since I brought up "trap DEBUG" execution order again, at the risk
>> of beating a dead horse...
>
> I don't really understand what the issue is.  Is there something about
> the DEBUG_BEFORE_CMD option that makes it hard to ensure it is set at
> the right point (this is not a trick question, that's perfectly
> possible)?

David Korn made a mistake and he says so.  Chet Ramey also says he
changed the behavior because he thought it a mistake too. zsh copied
the mistake. The only claim I've heard for keeping the mistake is
compatibility with previous versions of zsh. However right now there
is no evidence that anyone is making use of this mistake that would
not be happier if it weren't made.  When this mistake was corrected in
bash and ksh, no complaint was registered to keep the old less-helpful
behavior.

Generally one thinks of the default value as the thing most people
would choose. Compatibility is a good thing, but using it as an
argument for keeping a mistake that no one is using, seems to me to be
blindly following a rule without understanding why the rule is there.

So the suggestion is changing the default behavior to something which
follows both bash and ksh of the last 6 or so years.  If nothing else,
both bash and sh emulation in zsh should make this default behavior.

Thanks.

Re: Weird exit caused in a trap DEBUG which sources a file.

[Peter Stephenson]

On Sun, 3 Aug 2008 07:28:37 -0400
"Rocky Bernstein" <rocky.bernstein@gmail.com> wrote:
> I do not see why this is semantically complicated when the trap DEBUG
> occurs before the statement it refers to is run.  Can you give a very
> specific example of something you feel is tricky?

You mean that the new return value from a DEBUG trap should skip
everything that would happen until the next trap is run?  That's kind of
what I ended up saying, and that's well-defined.

> David Korn made a mistake and he says so.  Chet Ramey also says he
> changed the behavior because he thought it a mistake too. zsh copied
> the mistake. The only claim I've heard for keeping the mistake is
> compatibility with previous versions of zsh. However right now there
> is no evidence that anyone is making use of this mistake that would
> not be happier if it weren't made.

Well, there's no actual evidence it won't cause the toppling of
governments in small Himalayan kingdoms, either.  We probably won't find
out unless we change the default.  I agree setting DEBUG_BEFORE_CMD is
generally more useful, but you're the only user of the feature I've
heard from at all, and I still don't know if there's anything that makes
it hard to set the feature explicitly, in either direction (and at least
trying to set it in your script is the only way to guarantee the correct
behaviour).

If you're going to produce a working debugger that requires this to be
set then I'll be very tempted to change the default, since a generally
available working debugger is extremely useful.

Any definite views from anyone else are welcome.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: Weird exit caused in a trap DEBUG which sources a file.

[Rocky Bernstein]

On Sun, Aug 3, 2008 at 7:50 AM, Peter Stephenson
<p.w.stephenson@ntlworld.com> wrote:
> On Sun, 3 Aug 2008 07:28:37 -0400
> "Rocky Bernstein" <rocky.bernstein@gmail.com> wrote:
>> I do not see why this is semantically complicated when the trap DEBUG
>> occurs before the statement it refers to is run.  Can you give a very
>> specific example of something you feel is tricky?
>
> You mean that the new return value from a DEBUG trap should skip
> everything that would happen until the next trap is run?

Yes.

> That's kind of
> what I ended up saying, and that's well-defined.

Ok. I misunderstood. My mistake. I misremembered bash. The way it
currently works is that a return code 1 from a trap causes a skip. See
http://bashdb.sourceforge.net/bashdb.html#SEC36 for a description of
the debugger command.

Right now in bash returning 2 means immediate return. However, it
might be slick to have a negative value skip that many levels of
return. For a debugger this isn't strictly necessary because the
debugger can keep track of the number of levels to return. However for
those who write small custom trap DEBUG code (which right now is
probably anyone who uses it) it can be a nice convenience.

>
>> David Korn made a mistake and he says so.  Chet Ramey also says he
>> changed the behavior because he thought it a mistake too. zsh copied
>> the mistake. The only claim I've heard for keeping the mistake is
>> compatibility with previous versions of zsh. However right now there
>> is no evidence that anyone is making use of this mistake that would
>> not be happier if it weren't made.
>
> Well, there's no actual evidence it won't cause the toppling of
> governments in small Himalayan kingdoms, either.  We probably won't find
> out unless we change the default.  I agree setting DEBUG_BEFORE_CMD is
> generally more useful, but you're the only user of the feature I've
> heard from at all, and I still don't know if there's anything that makes
> it hard to set the feature explicitly, in either direction (and at least
> trying to set it in your script is the only way to guarantee the correct
> behaviour).

Well of course right now I do that, because I have to. :-)

As for ensuring correct behavior, because the of the dearth of bugs,
clearly I'll  have to put some tests in to make sure features and bug
fixes are there. I've been through this before. I probably won't
explicitly test for trap DEBUG but rather may check $ZSH_VERSION.

>From my side it would be nice if the debuggers in bash, ksh and zsh
shared the same code. But I agree all of this is small stuff.

>
> If you're going to produce a working debugger that requires this to be
> set then I'll be very tempted to change the default, since a generally
> available working debugger is extremely useful.

There are lots of other useful changes I see happening so if I have a
limit, I'd probably want to save that for some of the other things.
Probably the next thing on the list is a way to get subshell levels.
SHLVL check zsh/bash invocations, but one would like the same thing
for subshells. (In bash it is called $BASH_SUBSHELL) I suspect this is
pretty straightforward to do.

Instead my argument was based on the fact that it's the Right Thing To
Do (tm). There are a number of little benefits one gets by doing the
right thing.  Above I  gave one small example.

Here are some other small examples:

Consider this thread on "How to debug a running process"
http://groups.google.com/group/comp.unix.shell/browse_thread/thread/87c3f728476ed29d/5e056069f30efa35
 which was written before I was aware of the current zsh behavior.

Someone who reads that and decides to do follow  will have to know and
remember to set the ZSH-specific option to be more useful.

RIght now I'm in early stages of writing a book which covers program
development in POSIX shell. It will cover trap DEBUG, but I suppose
I'd also have to mention the ZSH specific option. Do we want people
reminded that this mistake was made and that ZSH makes its presence
known by still setting doing this in a less helpful way?

"trap DEBUG" is not currently mandated in POSIX 1003.1. However  David
Korn has said that a number of the features that are common in the
POSIX-compatible shells should eventually find their way into some
more aggressive spec. Making zsh like bash and ksh will only serve to
increase the likelihood that when this happens, trap DEBUG will be
there and done in the right way.

>
> Any definite views from anyone else are welcome.
>

As before with bash and ksh, resounding silence against and one or two
people who've weighed in and said it seems like a good thing.  I think
it safe to say this is analogous to making the mistake 0/0=1. Many
people won't notice or care or feel that strongly about. Personally
having been annoyed 3 times by it, so it is irksome to me. Something
like 8 years ago, I mentioned it to David Korn and he quickly
acknowledged and changed it.

Ok. I'll stop and I'll try to resist from written any more. Far more
has been written about this than the possibly 1 character change to
set this correctly. And by the way, if the current default is kept, it
probably needs to be set it when "emulate sh" or "emulate bash" is in
effect.