Re: PATCH: source file info from PS4

Thanks for fixing.

On Thu, Sep 18, 2008 at 8:13 AM, Peter Stephenson <pws@xxxxxxx> wrote:

On Wed, 17 Sep 2008 12:39:36 -0400
"Rocky Bernstein" <rocky.bernstein@xxxxxxxxx> wrote:
> On Tue, Sep 16, 2008 at 10:50 AM, Peter Stephenson <pws@xxxxxxx> wrote:
>
> > Now we have logic for finding the source file and corresponding line
> > number of executed code, this adds the prompt escapes %x and %I which
> > are like %N and %i but for the file where the code was defined.
>
> Looks like this has problems when used inside trap DEBUG.

What's happening here is that the current shell logic doesn't update line
numbers when inside a trap, even inside nested functions.

Ok. Thanks for the explanation. I don't see how this gives a line number that is larger than the number of lines in the entire program, but if the problem is fixed this is moot.

The idea is that
you're interested in the line number of what triggered the trap; this is
particularly true of a DEBUG trap where you might want to examine LINENO to
see what's going on in the code you're debugging, and you're much less
likely to be interested in the line number inside the trap itself.

If one wants the line number that triggered the trap, there are two simple ways to get this:
1. Save the line number in the call
trap 'int_handler $LINENO' INT
2. Use funcfiletrace

So the obvious fix is to make the prompt code I added take account of
this.

Yes, I think this the best thing.

Another possibility would be to make traps respect the EVALLINENO option,
so that you would get the local line numbers. However, I think that's less
useful.

It's possible the same problem affects some of the other new features. In
particular I think funcstack line number info for eval commands inside
traps is going to get thoroughly confused. I think the simplest fix would
be not to add funcstack info for eval in this case; this is sort of
plausible since it's like the case where eval isn't keep track of its own
line numbers, where we don't add funcstack info, and we don't add funcstack
info for a trap which is like an eval without its own line number.
Otherwise it's not currently obvious to me what the fix would be.

It might be a good idea to add special variables ZSH_SOURCE_LINENO and
ZSH_SOURCE_FILE as more readable alternatives to ${(%):-%I} and
${(%):-%x}.

Index: Src/prompt.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/prompt.c,v

retrieving revision 1.54
diff -u -r1.54 prompt.c
--- Src/prompt.c 16 Sep 2008 15:07:16 -0000 1.54
+++ Src/prompt.c 18 Sep 2008 11:55:04 -0000
@@ -726,7 +726,8 @@

stradd(Rstring);
break;
case 'I':
- if (funcstack && funcstack->tp != FS_SOURCE) {

+ if (funcstack && funcstack->tp != FS_SOURCE &&
+ (!intrap || trapisfunc)) {
/*

* We're in a function or an eval with
* EVALLINENO. Calculate the line number in

@@ -749,7 +750,8 @@

bp += strlen(bp);
break;
case 'x':
- if (funcstack && funcstack->tp != FS_SOURCE)

+ if (funcstack && funcstack->tp != FS_SOURCE &&
+ (!intrap || trapisfunc))

promptpath(funcstack->filename ? funcstack->filename : "",
arg, 0);
else

--

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