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

[Peter Stephenson <pws@csr.com>]

"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