From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28826 invoked from network); 18 Sep 2008 15:06:47 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=3.2.5 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 18 Sep 2008 15:06:47 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 20484 invoked from network); 18 Sep 2008 15:06:27 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 18 Sep 2008 15:06:27 -0000 Received: (qmail 27996 invoked by alias); 18 Sep 2008 15:06:16 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 25685 Received: (qmail 27977 invoked from network); 18 Sep 2008 15:06:15 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 18 Sep 2008 15:06:15 -0000 Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by bifrost.dotsrc.org (Postfix) with ESMTP id AE54980308B9 for ; Thu, 18 Sep 2008 17:05:56 +0200 (CEST) Received: by wf-out-1314.google.com with SMTP id 29so3927589wff.3 for ; Thu, 18 Sep 2008 08:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=BgV4z1ygE214lmP1NnGSEu4mEN4q8jP0XchqRPv9ovM=; b=IAhiAWLCX5lWcpSydaFxRIVwT/i3p2HVZFxXYGX1ULe1/yG3ia5bimGxtWJtHHEAAP YFdVrU6JYG0s5XSKJ7euevxqJqWpfEndjpnUxlEkJ5qbH7XPp1hV8sd6hz0LNlxaQucW +w+guiuC3o7ax3+MUVbM4eWyS8oFnI+ceFS5w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=enqTXNXIxRs4YVA3KpgA1Hmz9zYdTxrwK+I5MPfS6TtTLkfkFAovhICibRyUsg8OUt VXP9ejVbBMDhK8X5LCeQp1D50PMGzSkFZtdT4PnzWs/5jxJj2M7Q3ZbxUF1CV7/Ny3KX B6WZMtbI6DB6loVc3tui5ExTBGOnchrEUDWqU= Received: by 10.114.81.1 with SMTP id e1mr3439433wab.16.1221750353851; Thu, 18 Sep 2008 08:05:53 -0700 (PDT) Received: by 10.114.159.2 with HTTP; Thu, 18 Sep 2008 08:05:53 -0700 (PDT) Message-ID: <6cd6de210809180805w6a60f2eft222e436176659fe4@mail.gmail.com> Date: Thu, 18 Sep 2008 11:05:53 -0400 From: "Rocky Bernstein" To: "Peter Stephenson" Subject: Re: PATCH: source file info from PS4 Cc: "Zsh hackers list" In-Reply-To: <20080918131320.2d7f88f4@news01> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_15154_9881581.1221750353840" References: <6005.1221576641@csr.com> <6cd6de210809170939p968d36bufda419592a10cb45@mail.gmail.com> <20080918131320.2d7f88f4@news01> X-Virus-Scanned: ClamAV 0.92.1/8279/Thu Sep 18 14:42:42 2008 on bifrost X-Virus-Status: Clean ------=_Part_15154_9881581.1221750353840 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks for fixing. On Thu, Sep 18, 2008 at 8:13 AM, Peter Stephenson wrote: > On Wed, 17 Sep 2008 12:39:36 -0400 > "Rocky Bernstein" wrote: > > On Tue, Sep 16, 2008 at 10:50 AM, Peter Stephenson 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 Software Engineer > CSR PLC, Churchill House, Cambridge Business Park, Cowley Road > Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070 > ------=_Part_15154_9881581.1221750353840 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Thanks for fixing.

On Thu, Sep 18, 2008 at 8:13 AM, Peter Stephenson <pws@csr.com> wrote:
On Wed, 17 Sep 2008 12:39:36 -0400
"Rocky Bernstein" <rocky.bernstein@gmail.com> wrote:
> On Tue, Sep 16, 2008 at 10:50 AM, Peter Stephenson <pws@csr.com> 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@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070

------=_Part_15154_9881581.1221750353840--