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

["Rocky Bernstein" <rocky.bernstein@xxxxxxxxx>]

On Sun, Aug 3, 2008 at 7:50 AM, Peter Stephenson
<p.w.stephenson@xxxxxxxxxxxx> wrote:
> On Sun, 3 Aug 2008 07:28:37 -0400
> "Rocky Bernstein" <rocky.bernstein@xxxxxxxxx> 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.