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

["Rocky Bernstein" <rocky.bernstein@gmail.com>]

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
>