Debugging of dynamocally defined functions

Debugging of dynamocally defined functions

[Andrej Borsenkow]

Trying to debug one problem I had to look at set -x output of compinit. The
last line was compdef:101:... It turned out, there is no way to find correct
place. compdef is itself defined in compinit, and has comments. which
compdef produces source without comments and line numbers do not match.

Honestly speaking, I never liked it (function defining other functions that
is); why not simply have them autoloaded is beyond me.

-andrej

Re: Debugging of dynamocally defined functions

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> Trying to debug one problem I had to look at set -x output of compinit. The
> last line was compdef:101:... It turned out, there is no way to find correct
> place. compdef is itself defined in compinit, and has comments. which
> compdef produces source without comments and line numbers do not match.
> 
> Honestly speaking, I never liked it (function defining other functions that
> is); why not simply have them autoloaded is beyond me.

You were here, you should know.  That it's historical -- what now is
compinit once was the whole completion system (with so many changes that
noone would recognise it, but...).  It's just that noone took the time
to move compdef into an autoloaded file.

About the line numbers: the way I normally do it is to move the cursor
to the first line of the function and then use cursor-down with a prefix
argument.  Ugly, I agree.

Hm, could we change it so that it saves the line number of the script or
surrounding function?


Bye
  Sven


-- 
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: Debugging of dynamocally defined functions

[Peter Stephenson]

Sven Wischnowsky wrote:
> Hm, could we change it so that it saves the line number of the script or
> surrounding function?

What does the principle of least surprise give here?  Here's the current
behaviour.

  % cat fn
  print fn has now been executed.  Ecky thump.
  
  fn2() {                
  print $LINENO  
  }
  % autoload fn
  % fn
  fn has now been executed.  Ecky thump.
  % fn2
  1

(remember that the `fn2() {' line is numbered zero).

If you used the file it was in, you would get a line number of 4 in a 1
line function, together (with xtrace) with the name of that function.  What
you really want to know, I suppose, is the name of the function, the name
of the file it was read from, and the line number in that file.  That could
probably be arranged.  But it does mean an increased number of special
cases --- are we autoloading or running a dot file, if so, are we defining
a function which is not the one we are autoloading --- so it's not that
simple.

Alternatively, we forget about using line numbers on input and define them
when parsing, so they relate to the `which' output.  That's a big change,
and probably less useful since it's the original file you're going to be
editing.  I don't think it's worth remembering both.

By the way, you can use the trick of

  eval "$(which compdef)"

to sync the line numbers with the which output.  At least I hope so --- if
this goes screwy there's a bug in text.c.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: Debugging of dynamocally defined functions

[Bart Schaefer]

On Jul 5,  9:33am, Andrej Borsenkow wrote:
} Subject: Debugging of dynamocally defined functions
}
} Honestly speaking, I never liked it (function defining other functions that
} is); why not simply have them autoloaded is beyond me.

In the case of compdef I agree with you -- it's complicated enough that it
should have an entry in the documentation (separate from the `#comdpef'
entries, which are deceptively similar but use slightly different syntax).

In other cases functions defining functions is quite appropriate; consider
the `compadd' front-end that's defined in _approximate or _complete_help.
Not only would it be a waste to put it in a separate file, it would cause
errors to locate that file anywhere in the fpath!

In another message, PWS said:
> 
> By the way, you can use the trick of
> 
>   eval "$(which compdef)"
> 
> to sync the line numbers with the which output.  At least I hope so ---
> if this goes screwy there's a bug in text.c.

No, you can't.  This causes all the lines to be numbered zero.

`zed -f' has the same problem; drives me nuts.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Debugging of dynamocally defined functions

[Peter Stephenson]

"Bart Schaefer" wrote:
> In another message, PWS said:
> > 
> > By the way, you can use the trick of
> > 
> >   eval "$(which compdef)"
> > 
> > to sync the line numbers with the which output.  At least I hope so ---
> > if this goes screwy there's a bug in text.c.
> 
> No, you can't.  This causes all the lines to be numbered zero.

I've already made a note about this eval behaviour, in fact, in a slightly
different context (see the option tests I just added).  The original idea
was that eval'd code should show the line of the eval, not that of the
place where the eval was, but it has this side effect of suppressing proper
line numbering in functions within the eval.

I'm sure somebody will look at this eventually.  It's a question of the
availabliity of stamina and moral fibre.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@csr.com
Web: http://www.pwstephenson.fsnet.co.uk

Re: Debugging of dynamocally defined functions

[Peter Stephenson]

"Bart Schaefer" wrote:
> In another message, PWS said:
> > 
> > By the way, you can use the trick of
> > 
> >   eval "$(which compdef)"
> > 
> > to sync the line numbers with the which output.  At least I hope so ---
> > if this goes screwy there's a bug in text.c.
> 
> No, you can't.  This causes all the lines to be numbered zero.

> `zed -f' has the same problem; drives me nuts.

Should we try this patch for the time being?  It's a local fix to enable
line numbers any time strings are parsed in a standard fashion (there are
other ways strings can get parsed, but most of the syntactically
significant code such as eval goes through here).  If we decide to adopt
this, a lot of other code can go.

This has other side effects.  For one thing, `eval' now produces line
numbers in its own context, rather than in the surrounding context.  This
is what perl does, so maybe that's OK:

  % fn() {
  function> print $LINENO
  function> print $LINENO
  function> eval 'print eval $LINENO'
  function> eval 'print eval $LINENO'
  function> print $LINENO
  function> }
  % fn
  1
  2
  eval 1
  eval 1
  5

Previously, you would get `3' and `4' from the evals.  That was the object
of doing it that way.  The good news is that `eval "$(which fn)"' works
with the new way.

It's rather messier to turn line numbering on just when you start parsing a
function, but I can have a go at that if it seems useful.  However, I
rather suspect that road could get horrendously twisted, and I'd much
rather have it all or nothing.

Index: Src/exec.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/exec.c,v
retrieving revision 1.33
diff -u -r1.33 exec.c
--- Src/exec.c	2001/06/27 11:22:05	1.33
+++ Src/exec.c	2001/07/09 10:34:28
@@ -152,6 +152,14 @@
     Eprog p;
     int oldlineno = lineno;
 
+#if 1
+    /*
+     * Force line numbering on.  If this seems like a good idea,
+     * we can enable it globally, with consequent code simplifications.
+     * But I bet it's not that simple.
+     */
+    ln = 1;
+#endif
     lexsave();
     inpush(s, (ln ? INP_LINENO : 0), NULL);
     strinbeg(0);

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: Debugging of dynamocally defined functions

[Peter Stephenson]

"Bart Schaefer" wrote:
> In another message, PWS said:
> > 
> > By the way, you can use the trick of
> > 
> >   eval "$(which compdef)"
> > 
> > to sync the line numbers with the which output.  At least I hope so ---
> > if this goes screwy there's a bug in text.c.
> 
> No, you can't.  This causes all the lines to be numbered zero.

> `zed -f' has the same problem; drives me nuts.

I've sent a patch on this, which has disappeared, probably into our
non-UNIX (sorry if I like labouring this point) mail server.  Here's a
fuller version.  It turns on line numbering anywhere which behaves like an
eval (by using the parse_string() function; there are some other ways into
the parser which still don't do this).

I've discovered that bash simply gives 0 for line numbers in eval.  This
(perl-like) behaviour of numbering eval's separately is probably more
useful than that, at least.

I suspect the only way of finding out whether people prefer this behaviour
is to commit it.  So I'll do that and produced 4.1.0-dev-1.

Index: Src/builtin.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/builtin.c,v
retrieving revision 1.48
diff -u -r1.48 builtin.c
--- Src/builtin.c	2001/07/08 00:33:45	1.48
+++ Src/builtin.c	2001/07/09 14:45:09
@@ -3421,7 +3421,7 @@
 {
     Eprog prog;
 
-    prog = parse_string(zjoin(argv, ' ', 1), 0);
+    prog = parse_string(zjoin(argv, ' ', 1));
     if (!prog) {
 	errflag = 0;
 	return 1;
@@ -4027,7 +4027,7 @@
     arg = *argv++;
     if (!*arg)
 	prog = &dummy_eprog;
-    else if (!(prog = parse_string(arg, 0))) {
+    else if (!(prog = parse_string(arg))) {
 	zwarnnam(name, "couldn't parse trap command", NULL, 0);
 	return 1;
     }
Index: Src/exec.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/exec.c,v
retrieving revision 1.33
diff -u -r1.33 exec.c
--- Src/exec.c	2001/06/27 11:22:05	1.33
+++ Src/exec.c	2001/07/09 14:45:09
@@ -147,15 +147,15 @@
 
 /**/
 mod_export Eprog
-parse_string(char *s, int ln)
+parse_string(char *s)
 {
     Eprog p;
     int oldlineno = lineno;
 
     lexsave();
-    inpush(s, (ln ? INP_LINENO : 0), NULL);
+    inpush(s, INP_LINENO, NULL);
     strinbeg(0);
-    lineno = ln ? 1 : -1;
+    lineno = 1;
     p = parse_list();
     lineno = oldlineno;
     strinend();
@@ -711,7 +711,7 @@
     Eprog prog;
 
     pushheap();
-    if ((prog = parse_string(s, 0)))
+    if ((prog = parse_string(s)))
 	execode(prog, dont_change_job, exiting);
     popheap();
 }
@@ -2669,7 +2669,7 @@
     pid_t pid;
     Wordcode pc;
 
-    if (!(prog = parse_string(cmd, 0)))
+    if (!(prog = parse_string(cmd)))
 	return NULL;
 
     pc = prog->prog;
@@ -2800,7 +2800,7 @@
 	return NULL;
     }
     *str = '\0';
-    if (str[1] || !(prog = parse_string(cmd + 2, 0))) {
+    if (str[1] || !(prog = parse_string(cmd + 2))) {
 	zerr("parse error in process substitution", NULL, 0);
 	return NULL;
     }
@@ -3496,7 +3496,7 @@
 		    d = metafy(d, len, META_REALLOC);
 
 		    scriptname = dupstring(s);
-		    r = parse_string(d, 1);
+		    r = parse_string(d);
 		    scriptname = oldscriptname;
 
 		    zfree(d, len + 1);
Index: Src/glob.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/glob.c,v
retrieving revision 1.20
diff -u -r1.20 glob.c
--- Src/glob.c	2001/07/06 09:23:58	1.20
+++ Src/glob.c	2001/07/09 14:45:09
@@ -2632,7 +2632,7 @@
 {
     Eprog prog;
 
-    if ((prog = parse_string(str, 0))) {
+    if ((prog = parse_string(str))) {
 	int ef = errflag, lv = lastval, ret;
 
 	unsetparam("reply");
Index: Src/parse.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/parse.c,v
retrieving revision 1.27
diff -u -r1.27 parse.c
--- Src/parse.c	2001/07/06 09:40:08	1.27
+++ Src/parse.c	2001/07/09 14:45:09
@@ -2602,7 +2602,7 @@
 	close(fd);
 	file = metafy(file, flen, META_REALLOC);
 
-	if (!(prog = parse_string(file, 1)) || errflag) {
+	if (!(prog = parse_string(file)) || errflag) {
 	    errflag = 0;
 	    close(dfd);
 	    zfree(file, flen);
Index: Src/Modules/parameter.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Modules/parameter.c,v
retrieving revision 1.20
diff -u -r1.20 parameter.c
--- Src/Modules/parameter.c	2001/05/31 09:44:00	1.20
+++ Src/Modules/parameter.c	2001/07/09 14:45:09
@@ -342,7 +342,7 @@
 
     val = metafy(val, strlen(val), META_REALLOC);
 
-    prog = parse_string(val, 1);
+    prog = parse_string(val);
 
     if (!prog || prog == &dummy_eprog) {
 	zwarn("invalid function definition", value, 0);
Index: Src/Modules/zpty.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Modules/zpty.c,v
retrieving revision 1.23
diff -u -r1.23 zpty.c
--- Src/Modules/zpty.c	2001/05/08 10:26:58	1.23
+++ Src/Modules/zpty.c	2001/07/09 14:45:09
@@ -276,7 +276,7 @@
     int master, slave, pid;
     Eprog prog;
 
-    prog = parse_string(zjoin(args, ' ', 1), 0);
+    prog = parse_string(zjoin(args, ' ', 1));
     if (!prog) {
 	errflag = 0;
 	return 1;
Index: Src/Modules/zutil.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Modules/zutil.c,v
retrieving revision 1.8
diff -u -r1.8 zutil.c
--- Src/Modules/zutil.c	2001/01/16 13:44:20	1.8
+++ Src/Modules/zutil.c	2001/07/09 14:45:09
@@ -115,7 +115,7 @@
     if (eval) {
 	int ef = errflag;
 
-	eprog = parse_string(zjoin(vals, ' ', 1), 0);
+	eprog = parse_string(zjoin(vals, ' ', 1));
 	errflag = ef;
 
 	if (!eprog)

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: Debugging of dynamocally defined functions

[Peter Stephenson]

Peter Stephenson wrote:
> It turns on line numbering anywhere which behaves like an
> eval (by using the parse_string() function; there are some other ways into
> the parser which still don't do this).

These are the consequent changes for the tests.  Most of these actually
improve things --- the line numbers now reflect the position in the eval,
rather than the line of the function that was executing, which isn't
visible when you're writing the test.

However, there's one nuisance:  trap '...' DEBUG now gives a line number in
the trap expression, rather than the number of the line you've just
executed.  This is probably a bug.  It's annoying to have that single case
where the line number has to be passed through, though.

Index: Test/A01grammar.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/A01grammar.ztst,v
retrieving revision 1.2
diff -u -r1.2 A01grammar.ztst
--- Test/A01grammar.ztst	2001/06/22 06:35:54	1.2
+++ Test/A01grammar.ztst	2001/07/09 16:26:57
@@ -108,7 +108,7 @@
     :
   fi
 1d:`if ...' (iv)
-?ZTST_execchunk:-1: parse error near `fi'
+?ZTST_execchunk:3: parse error near `fi'
 
   for name in word to term; do
     print $name
Index: Test/A02alias.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/A02alias.ztst,v
retrieving revision 1.2
diff -u -r1.2 A02alias.ztst
--- Test/A02alias.ztst	2001/06/25 03:06:35	1.2
+++ Test/A02alias.ztst	2001/07/09 16:26:57
@@ -16,7 +16,7 @@
 
   \foo foo
 127:Not aliasing
-?ZTST_execchunk:2: command not found: foo
+?ZTST_execchunk:1: command not found: foo
 
   \bar \bar
 0:Aliasing with a backslash
Index: Test/A04redirect.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/A04redirect.ztst,v
retrieving revision 1.1
diff -u -r1.1 A04redirect.ztst
--- Test/A04redirect.ztst	2001/04/02 12:31:04	1.1
+++ Test/A04redirect.ztst	2001/07/09 16:26:57
@@ -200,7 +200,7 @@
   print cat input >out1
   <out1
 1:READNULLCMD with NULLCMD unset
-?ZTST_execchunk:2: redirection with no command
+?ZTST_execchunk:3: redirection with no command
 
   NULLCMD=:
   >out1
Index: Test/A05execution.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/A05execution.ztst,v
retrieving revision 1.1
diff -u -r1.1 A05execution.ztst
--- Test/A05execution.ztst	2001/04/02 12:31:39	1.1
+++ Test/A05execution.ztst	2001/07/09 16:26:57
@@ -134,7 +134,7 @@
   rm fn
 0:trap DEBUG
 >Line 1
->Line 2
+>Line 1
 
   TRAPZERR() { print Command failed; }
   true
Index: Test/C01arith.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/C01arith.ztst,v
retrieving revision 1.2
diff -u -r1.2 C01arith.ztst
--- Test/C01arith.ztst	2001/07/06 18:33:59	1.2
+++ Test/C01arith.ztst	2001/07/09 16:26:57
@@ -53,11 +53,11 @@
 
   print $(( 3 ? 2 ))
 1:parsing ternary (1)
-?ZTST_execchunk:2: ':' expected
+?ZTST_execchunk:1: ':' expected
 
   print $(( 3 ? 2 : 1 : 4 ))
 1:parsing ternary (2)
-?ZTST_execchunk:2: ':' without '?'
+?ZTST_execchunk:1: ':' without '?'
 
   print $(( 0, 4 ? 3 : 1, 5 ))
 0:comma operator
@@ -91,7 +91,7 @@
 
   print $(( 13 = 42 ))
 1:bad lvalue
-?ZTST_execchunk:2: lvalue required
+?ZTST_execchunk:1: lvalue required
 
   x=/bar
   (( x = 32 ))
Index: Test/D04parameter.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/D04parameter.ztst,v
retrieving revision 1.2
diff -u -r1.2 D04parameter.ztst
--- Test/D04parameter.ztst	2001/05/19 23:47:58	1.2
+++ Test/D04parameter.ztst	2001/07/09 16:26:58
@@ -74,7 +74,7 @@
 1:${...:?...}, ${...?...}
 >set1v
 >
-?ZTST_execchunk:2: unset1: exiting1
+?ZTST_execchunk:1: unset1: exiting1
 ?ZTST_execchunk:2: null1: exiting2
 
   print ${set1:+word1} ${set1+word2} ${null1:+word3} ${null1+word4}
Index: Test/D06subscript.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/D06subscript.ztst,v
retrieving revision 1.5
diff -u -r1.5 D06subscript.ztst
--- Test/D06subscript.ztst	2001/04/24 05:45:17	1.5
+++ Test/D06subscript.ztst	2001/07/09 16:26:58
@@ -95,7 +95,7 @@
 
   eval 'A[*]=star'
 1:Illegal associative array assignment
-?ZTST_execchunk:2: A: attempt to set slice of associative array
+?ZTST_execchunk:1: A: attempt to set slice of associative array
 
   x='*'
   A[$x]=xstar
Index: Test/E01options.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/E01options.ztst,v
retrieving revision 1.6
diff -u -r1.6 E01options.ztst
--- Test/E01options.ztst	2001/07/05 14:51:35	1.6
+++ Test/E01options.ztst	2001/07/09 16:26:58
@@ -133,7 +133,7 @@
   print [b
 1:BAD_PATTERN option
 >[a
-?ZTST_execchunk:2: bad pattern: [b
+?ZTST_execchunk:4: bad pattern: [b
 
   unsetopt bareglobqual nomatch
   print *(.)
@@ -192,8 +192,8 @@
 1q:CDABLE_VARS option
 >`print -P '%~'`/tmpcd
 >back in options.tmp
-?ZTST_execchunk:cd:2: no such file or directory: cdablevar1
-?ZTST_execchunk:cd:2: no such file or directory: cdablevar2
+?ZTST_execchunk:cd:4: no such file or directory: cdablevar1
+?ZTST_execchunk:cd:10: no such file or directory: cdablevar2
 
 # CHASE_DOTS should go with CHASE_LINKS in B01cd.ztst
 # which saves me having to write it here.
@@ -227,8 +227,8 @@
 >wimpole
 >royston
 >foxton
-?ZTST_execchunk:2: file exists: foo1
-?ZTST_execchunk:2: no such file or directory: bar1
+?ZTST_execchunk:4: file exists: foo1
+?ZTST_execchunk:6: no such file or directory: bar1
 
    setopt cshjunkieloops
    eval 'for f in swaffham bulbeck; print $f; end'
@@ -239,7 +239,7 @@
 >swaffham
 >bulbeck
 ?next one should fail
-?ZTST_execchunk:-1: parse error near `end'
+?ZTST_execchunk:1: parse error near `end'
 
   setopt cshjunkiequotes
   print this should cause an error >&2
@@ -253,7 +253,7 @@
 >line three
 >  line four
 ?this should cause an error
-?ZTST_execchunk:-1: unmatched '
+?ZTST_execchunk:1: unmatched '
 ?this should not
 
   nullcmd() { print '$NULLCMD run'; }
@@ -279,10 +279,10 @@
 >Running $READNULLCMD
 >$NULLCMD run
 ?This should fail
-?ZTST_execchunk:2: redirection with no command
+?ZTST_execchunk:8: redirection with no command
 ?This should succeed
 ?This should also fail
-?ZTST_execchunk:2: redirection with no command
+?ZTST_execchunk:13: redirection with no command
 
 # nomatch should be overridden by cshnullglob
   setopt nomatch cshnullglob
@@ -297,7 +297,7 @@
 >tmpcd tmpfile1 tmpfile2 blah
 >tmpcd tmpfile1 tmpfile2 nothing* blah
 >nothing* blah
-?hoping for no match: ZTST_execchunk:2: no match
+?hoping for no match: ZTST_execchunk:4: no match
 ?
 
 # The trick is to avoid =cat being expanded in the output while $catpath is.
@@ -625,7 +625,7 @@
   print with nomatch flooble*
 1:NOMATCH option
 >with nonomatch: flooble*
-?ZTST_execchunk:2: no matches found: flooble*
+?ZTST_execchunk:4: no matches found: flooble*
 
 # NULL_GLOB should override NONOMATCH...
   setopt nullglob nomatch
@@ -688,7 +688,7 @@
 >File in upper dir
 >File in lower dir
 >unsetting option...
-?ZTST_execchunk:2: no such file or directory: pathtestdir/findme
+?ZTST_execchunk:14: no such file or directory: pathtestdir/findme
 
   setopt posixbuiltins
   command print foo
@@ -698,7 +698,7 @@
 127:POSIX_BUILTINS option
 >foo
 >unsetting...
-?ZTST_execchunk:2: command not found: print
+?ZTST_execchunk:5: command not found: print
 
 # This option seems to be problematic.  I don't quite know how it works.
 ##   func() {
@@ -807,7 +807,7 @@
 >one'quoted'expression
 >anotherquotedexpression
 
-  # too lazy to test jobs -Z and ARGV0.
+# too lazy to test jobs -Z and ARGV0.
   (setopt restricted; cd /)
   (setopt restricted; PATH=/bin:/usr/bin)
   (setopt restricted; /bin/ls)
@@ -817,13 +817,13 @@
   (setopt restricted; unsetopt restricted)
   :
 0:RESTRICTED option
-?ZTST_execchunk:cd:2: restricted
+?ZTST_execchunk:cd:1: restricted
 ?ZTST_execchunk:2: PATH: restricted
-?ZTST_execchunk:2: /bin/ls: restricted
-?ZTST_execchunk:hash:2: restricted: /bin/ls
-?ZTST_execchunk:2: writing redirection not allowed in restricted mode
-?ZTST_execchunk:exec:2: ls: restricted
-?ZTST_execchunk:unsetopt:2: can't change option: restricted
+?ZTST_execchunk:3: /bin/ls: restricted
+?ZTST_execchunk:hash:4: restricted: /bin/ls
+?ZTST_execchunk:5: writing redirection not allowed in restricted mode
+?ZTST_execchunk:exec:6: ls: restricted
+?ZTST_execchunk:unsetopt:7: can't change option: restricted
 
   fn() {
     print =ls ={ls,}
@@ -909,10 +909,9 @@
 >nonsense
 >nonsense
 >nonsense
-?fn:-1: parse error near `print'
-?fn:-1: parse error near `print'
-?fn:-1: parse error near `print'
-# Eugh, that line numbering behaviour with eval is probably a bug.
+?fn:1: parse error near `print'
+?fn:1: parse error near `print'
+?fn:1: parse error near `print'
 
   fn() { print -l $*; }
   setopt shwordsplit
@@ -959,6 +958,6 @@
 0:XTRACE option
 >message
 >message
-?+ZTST_execchunk:2> fn
+?+ZTST_execchunk:3> fn
 ?+fn:0> print message
-?+ZTST_execchunk:2> unsetopt xtrace
+?+ZTST_execchunk:4> unsetopt xtrace
Index: Test/E02xtrace.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/E02xtrace.ztst,v
retrieving revision 1.1
diff -u -r1.1 E02xtrace.ztst
--- Test/E02xtrace.ztst	2001/04/02 12:34:40	1.1
+++ Test/E02xtrace.ztst	2001/07/09 16:26:58
@@ -54,30 +54,30 @@
 >Tracing: function 2>file
 >Tracing: source
 >Tracing: source 2>file
->+ZTST_execchunk:2> print Tracing: ( builtin ) 2>file
->+ZTST_execchunk:2> cat
->+ZTST_execchunk:2> print Tracing: { builtin } 2>file
->+ZTST_execchunk:2> cat
->+ZTST_execchunk:2> print Tracing: do builtin done 2>file
->+ZTST_execchunk:2> cat
+>+ZTST_execchunk:7> print Tracing: ( builtin ) 2>file
+>+ZTST_execchunk:9> cat
+>+ZTST_execchunk:11> print Tracing: { builtin } 2>file
+>+ZTST_execchunk:13> cat
+>+ZTST_execchunk:15> print Tracing: do builtin done 2>file
+>+ZTST_execchunk:17> cat
 ?+ZTST_execchunk:2> print Tracing: builtin
-?+ZTST_execchunk:2> print Tracing: builtin 2>file
-?+ZTST_execchunk:2> cat
-?+ZTST_execchunk:2> cat
-?+ZTST_execchunk:2> print Tracing: ( builtin )
-?+ZTST_execchunk:2> cat
-?+ZTST_execchunk:2> print Tracing: { builtin }
-?+ZTST_execchunk:2> cat
-?+ZTST_execchunk:2> print Tracing: do builtin done
-?+ZTST_execchunk:2> cat
-?+ZTST_execchunk:2> xtf Tracing: function
-?+xtf:0> local regression_test_dummy_variable
-?+xtf:0> print Tracing: function
-?+ZTST_execchunk:2> xtf Tracing: function 2>file
-?+xtf:0> local regression_test_dummy_variable
-?+xtf:0> print Tracing: function 2>file
-?+ZTST_execchunk:2> . ./xt.in Tracing: source
+?+ZTST_execchunk:3> print Tracing: builtin 2>file
+?+ZTST_execchunk:4> cat
+?+ZTST_execchunk:5> cat
+?+ZTST_execchunk:6> print Tracing: ( builtin )
+?+ZTST_execchunk:8> cat
+?+ZTST_execchunk:10> print Tracing: { builtin }
+?+ZTST_execchunk:12> cat
+?+ZTST_execchunk:14> print Tracing: do builtin done
+?+ZTST_execchunk:16> cat
+?+ZTST_execchunk:18> xtf Tracing: function
+?+xtf:1> local regression_test_dummy_variable
+?+xtf:2> print Tracing: function
+?+ZTST_execchunk:19> xtf Tracing: function 2>file
+?+xtf:1> local regression_test_dummy_variable
+?+xtf:2> print Tracing: function 2>file
+?+ZTST_execchunk:20> . ./xt.in Tracing: source
 ?+./xt.in:1> print Tracing: source
-?+ZTST_execchunk:2> . ./xt.in Tracing: source 2>file
+?+ZTST_execchunk:21> . ./xt.in Tracing: source 2>file
 ?+./xt.in:1> print Tracing: source 2>file
-?+ZTST_execchunk:2> set +x
+?+ZTST_execchunk:22> set +x
Index: Test/V01zmodload.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/V01zmodload.ztst,v
retrieving revision 1.3
diff -u -r1.3 V01zmodload.ztst
--- Test/V01zmodload.ztst	2001/05/23 17:05:56	1.3
+++ Test/V01zmodload.ztst	2001/07/09 16:26:58
@@ -47,7 +47,7 @@
 
  zmodload zsh/main
 1:Test reloading an already-loaded module
-?ZTST_execchunk:zmodload:2: module zsh/main already loaded.
+?ZTST_execchunk:zmodload:1: module zsh/main already loaded.
 
 # Loop over the modules found above and attempt to load each one.  Use
 # the -i flag in case dependencies cause multiple modules to be loaded,

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: Debugging of dynamocally defined functions

[Bart Schaefer]

On Jul 9,  3:52pm, Peter Stephenson wrote:
} Subject: Re: Debugging of dynamocally defined functions
}
} I've discovered that bash simply gives 0 for line numbers in eval.  This
} (perl-like) behaviour of numbering eval's separately is probably more
} useful than that, at least.
}  
} I suspect the only way of finding out whether people prefer this behaviour
} is to commit it.  So I'll do that and produced 4.1.0-dev-1.

After playing with this for a few minutes I have the following observations:

In xtrace output the `eval' itself gets a line number before the commands
that it executes are numbered, so that's fine -- it's possible to track
the eval to a line in the calling function/file.

However, neither the value of %N nor that of %_ in PS4 changes to indicate
that you've entered a new line numbering scope; only %i changes.  For a
large `eval' that can be quite distracting.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Debugging of dynamocally defined functions

[Peter Stephenson]

"Bart Schaefer" wrote:
> In xtrace output the `eval' itself gets a line number before the commands
> that it executes are numbered, so that's fine -- it's possible to track
> the eval to a line in the calling function/file.
> 
> However, neither the value of %N nor that of %_ in PS4 changes to indicate
> that you've entered a new line numbering scope; only %i changes.  For a
> large `eval' that can be quite distracting.

Yes, that's pretty much the same point I made over the matter of line
numbering of functions whose definitions is embedded in some other file;
you really want to know both the function and the file to make sense of it.

The following is how perl does it, marking an `eval' as a separate
environment.  This time I've included the Test changes --- those
ZTST_execchunk's are gone in favour of `(eval)' (good riddance --- this
improves the look of thing markedly).

I can't absolutely guarantee that setting scriptname has no side effects,
but the tests as modified all still pass.

Is this better?  It's missed 4.1.0-dev-1.

Index: Src/builtin.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/builtin.c,v
retrieving revision 1.49
diff -u -r1.49 builtin.c
--- Src/builtin.c	2001/07/09 16:05:14	1.49
+++ Src/builtin.c	2001/07/09 17:26:24
@@ -3420,7 +3420,10 @@
 bin_eval(char *nam, char **argv, char *ops, int func)
 {
     Eprog prog;
+    char *oscriptname = scriptname;
 
+    scriptname = "(eval)";
+
     prog = parse_string(zjoin(argv, ' ', 1));
     if (!prog) {
 	errflag = 0;
@@ -3431,6 +3434,9 @@
 	lastval = errflag;
 	errflag = 0;
     }
+
+    scriptname = oscriptname;
+
     return lastval;
 }
 
Index: Test/A01grammar.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/A01grammar.ztst,v
retrieving revision 1.3
diff -u -r1.3 A01grammar.ztst
--- Test/A01grammar.ztst	2001/07/09 16:41:19	1.3
+++ Test/A01grammar.ztst	2001/07/09 17:26:24
@@ -108,7 +108,7 @@
     :
   fi
 1d:`if ...' (iv)
-?ZTST_execchunk:3: parse error near `fi'
+?(eval):3: parse error near `fi'
 
   for name in word to term; do
     print $name
Index: Test/A02alias.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/A02alias.ztst,v
retrieving revision 1.3
diff -u -r1.3 A02alias.ztst
--- Test/A02alias.ztst	2001/07/09 16:41:19	1.3
+++ Test/A02alias.ztst	2001/07/09 17:26:24
@@ -16,7 +16,7 @@
 
   \foo foo
 127:Not aliasing
-?ZTST_execchunk:1: command not found: foo
+?(eval):1: command not found: foo
 
   \bar \bar
 0:Aliasing with a backslash
Index: Test/A04redirect.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/A04redirect.ztst,v
retrieving revision 1.2
diff -u -r1.2 A04redirect.ztst
--- Test/A04redirect.ztst	2001/07/09 16:41:19	1.2
+++ Test/A04redirect.ztst	2001/07/09 17:26:24
@@ -189,7 +189,7 @@
   unset NULLCMD
   >out1
 1:null redir with NULLCMD unset
-?ZTST_execchunk:2: redirection with no command
+?(eval):2: redirection with no command
 
   echo this should still work >out1
   print "$(<out1)"
@@ -200,7 +200,7 @@
   print cat input >out1
   <out1
 1:READNULLCMD with NULLCMD unset
-?ZTST_execchunk:3: redirection with no command
+?(eval):3: redirection with no command
 
   NULLCMD=:
   >out1
Index: Test/C01arith.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/C01arith.ztst,v
retrieving revision 1.3
diff -u -r1.3 C01arith.ztst
--- Test/C01arith.ztst	2001/07/09 16:41:19	1.3
+++ Test/C01arith.ztst	2001/07/09 17:26:24
@@ -53,11 +53,11 @@
 
   print $(( 3 ? 2 ))
 1:parsing ternary (1)
-?ZTST_execchunk:1: ':' expected
+?(eval):1: ':' expected
 
   print $(( 3 ? 2 : 1 : 4 ))
 1:parsing ternary (2)
-?ZTST_execchunk:1: ':' without '?'
+?(eval):1: ':' without '?'
 
   print $(( 0, 4 ? 3 : 1, 5 ))
 0:comma operator
@@ -91,7 +91,7 @@
 
   print $(( 13 = 42 ))
 1:bad lvalue
-?ZTST_execchunk:1: lvalue required
+?(eval):1: lvalue required
 
   x=/bar
   (( x = 32 ))
Index: Test/D01prompt.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/D01prompt.ztst,v
retrieving revision 1.1
diff -u -r1.1 D01prompt.ztst
--- Test/D01prompt.ztst	2001/04/02 12:33:15	1.1
+++ Test/D01prompt.ztst	2001/07/09 17:26:24
@@ -30,7 +30,7 @@
 >  %M:  $HOST
 >  %m:  ${HOST%%.*}
 >  %n:  $USERNAME
->  %N:  ZTST_execchunk
+>  %N:  (eval)
 >  %i:  2
 >  a%{...%}b:  ab
 >  
Index: Test/D04parameter.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/D04parameter.ztst,v
retrieving revision 1.3
diff -u -r1.3 D04parameter.ztst
--- Test/D04parameter.ztst	2001/07/09 16:41:19	1.3
+++ Test/D04parameter.ztst	2001/07/09 17:26:24
@@ -74,8 +74,8 @@
 1:${...:?...}, ${...?...}
 >set1v
 >
-?ZTST_execchunk:1: unset1: exiting1
-?ZTST_execchunk:2: null1: exiting2
+?(eval):1: unset1: exiting1
+?(eval):2: null1: exiting2
 
   print ${set1:+word1} ${set1+word2} ${null1:+word3} ${null1+word4}
   print ${unset1:+word5} ${unset1+word6}
@@ -279,7 +279,7 @@
   foo='unmatched "'
   print ${(QX)foo}
 1:${(QX)...}
-?ZTST_execchunk:2: unmatched "
+?(eval):2: unmatched "
 
   array=(characters in an array)
   print ${(c)#array}
Index: Test/D06subscript.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/D06subscript.ztst,v
retrieving revision 1.6
diff -u -r1.6 D06subscript.ztst
--- Test/D06subscript.ztst	2001/07/09 16:41:19	1.6
+++ Test/D06subscript.ztst	2001/07/09 17:26:24
@@ -95,7 +95,7 @@
 
   eval 'A[*]=star'
 1:Illegal associative array assignment
-?ZTST_execchunk:1: A: attempt to set slice of associative array
+?(eval):1: A: attempt to set slice of associative array
 
   x='*'
   A[$x]=xstar
Index: Test/E01options.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/E01options.ztst,v
retrieving revision 1.7
diff -u -r1.7 E01options.ztst
--- Test/E01options.ztst	2001/07/09 16:41:19	1.7
+++ Test/E01options.ztst	2001/07/09 17:26:24
@@ -133,7 +133,7 @@
   print [b
 1:BAD_PATTERN option
 >[a
-?ZTST_execchunk:4: bad pattern: [b
+?(eval):4: bad pattern: [b
 
   unsetopt bareglobqual nomatch
   print *(.)
@@ -192,8 +192,8 @@
 1q:CDABLE_VARS option
 >`print -P '%~'`/tmpcd
 >back in options.tmp
-?ZTST_execchunk:cd:4: no such file or directory: cdablevar1
-?ZTST_execchunk:cd:10: no such file or directory: cdablevar2
+?(eval):cd:4: no such file or directory: cdablevar1
+?(eval):cd:10: no such file or directory: cdablevar2
 
 # CHASE_DOTS should go with CHASE_LINKS in B01cd.ztst
 # which saves me having to write it here.
@@ -227,8 +227,8 @@
 >wimpole
 >royston
 >foxton
-?ZTST_execchunk:4: file exists: foo1
-?ZTST_execchunk:6: no such file or directory: bar1
+?(eval):4: file exists: foo1
+?(eval):6: no such file or directory: bar1
 
    setopt cshjunkieloops
    eval 'for f in swaffham bulbeck; print $f; end'
@@ -239,7 +239,7 @@
 >swaffham
 >bulbeck
 ?next one should fail
-?ZTST_execchunk:1: parse error near `end'
+?(eval):1: parse error near `end'
 
   setopt cshjunkiequotes
   print this should cause an error >&2
@@ -253,7 +253,7 @@
 >line three
 >  line four
 ?this should cause an error
-?ZTST_execchunk:1: unmatched '
+?(eval):1: unmatched '
 ?this should not
 
   nullcmd() { print '$NULLCMD run'; }
@@ -279,10 +279,10 @@
 >Running $READNULLCMD
 >$NULLCMD run
 ?This should fail
-?ZTST_execchunk:8: redirection with no command
+?(eval):8: redirection with no command
 ?This should succeed
 ?This should also fail
-?ZTST_execchunk:13: redirection with no command
+?(eval):13: redirection with no command
 
 # nomatch should be overridden by cshnullglob
   setopt nomatch cshnullglob
@@ -297,7 +297,7 @@
 >tmpcd tmpfile1 tmpfile2 blah
 >tmpcd tmpfile1 tmpfile2 nothing* blah
 >nothing* blah
-?hoping for no match: ZTST_execchunk:4: no match
+?hoping for no match: (eval):4: no match
 ?
 
 # The trick is to avoid =cat being expanded in the output while $catpath is.
@@ -625,7 +625,7 @@
   print with nomatch flooble*
 1:NOMATCH option
 >with nonomatch: flooble*
-?ZTST_execchunk:4: no matches found: flooble*
+?(eval):4: no matches found: flooble*
 
 # NULL_GLOB should override NONOMATCH...
   setopt nullglob nomatch
@@ -688,7 +688,7 @@
 >File in upper dir
 >File in lower dir
 >unsetting option...
-?ZTST_execchunk:14: no such file or directory: pathtestdir/findme
+?(eval):14: no such file or directory: pathtestdir/findme
 
   setopt posixbuiltins
   command print foo
@@ -698,7 +698,7 @@
 127:POSIX_BUILTINS option
 >foo
 >unsetting...
-?ZTST_execchunk:5: command not found: print
+?(eval):5: command not found: print
 
 # This option seems to be problematic.  I don't quite know how it works.
 ##   func() {
@@ -707,7 +707,7 @@
 ##   }
 ##   func
 ## 1:PRINT_EXIT_VALUE option
-## ?ZTST_execchunk:2: exit 1
+## ?(eval):2: exit 1
 
   setopt promptbang
   print -P !
@@ -817,13 +817,13 @@
   (setopt restricted; unsetopt restricted)
   :
 0:RESTRICTED option
-?ZTST_execchunk:cd:1: restricted
-?ZTST_execchunk:2: PATH: restricted
-?ZTST_execchunk:3: /bin/ls: restricted
-?ZTST_execchunk:hash:4: restricted: /bin/ls
-?ZTST_execchunk:5: writing redirection not allowed in restricted mode
-?ZTST_execchunk:exec:6: ls: restricted
-?ZTST_execchunk:unsetopt:7: can't change option: restricted
+?(eval):cd:1: restricted
+?(eval):2: PATH: restricted
+?(eval):3: /bin/ls: restricted
+?(eval):hash:4: restricted: /bin/ls
+?(eval):5: writing redirection not allowed in restricted mode
+?(eval):exec:6: ls: restricted
+?(eval):unsetopt:7: can't change option: restricted
 
   fn() {
     print =ls ={ls,}
@@ -909,9 +909,9 @@
 >nonsense
 >nonsense
 >nonsense
-?fn:1: parse error near `print'
-?fn:1: parse error near `print'
-?fn:1: parse error near `print'
+?(eval):1: parse error near `print'
+?(eval):1: parse error near `print'
+?(eval):1: parse error near `print'
 
   fn() { print -l $*; }
   setopt shwordsplit
@@ -958,6 +958,6 @@
 0:XTRACE option
 >message
 >message
-?+ZTST_execchunk:3> fn
+?+(eval):3> fn
 ?+fn:0> print message
-?+ZTST_execchunk:4> unsetopt xtrace
+?+(eval):4> unsetopt xtrace
Index: Test/E02xtrace.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/E02xtrace.ztst,v
retrieving revision 1.2
diff -u -r1.2 E02xtrace.ztst
--- Test/E02xtrace.ztst	2001/07/09 16:41:19	1.2
+++ Test/E02xtrace.ztst	2001/07/09 17:26:24
@@ -54,30 +54,30 @@
 >Tracing: function 2>file
 >Tracing: source
 >Tracing: source 2>file
->+ZTST_execchunk:7> print Tracing: ( builtin ) 2>file
->+ZTST_execchunk:9> cat
->+ZTST_execchunk:11> print Tracing: { builtin } 2>file
->+ZTST_execchunk:13> cat
->+ZTST_execchunk:15> print Tracing: do builtin done 2>file
->+ZTST_execchunk:17> cat
-?+ZTST_execchunk:2> print Tracing: builtin
-?+ZTST_execchunk:3> print Tracing: builtin 2>file
-?+ZTST_execchunk:4> cat
-?+ZTST_execchunk:5> cat
-?+ZTST_execchunk:6> print Tracing: ( builtin )
-?+ZTST_execchunk:8> cat
-?+ZTST_execchunk:10> print Tracing: { builtin }
-?+ZTST_execchunk:12> cat
-?+ZTST_execchunk:14> print Tracing: do builtin done
-?+ZTST_execchunk:16> cat
-?+ZTST_execchunk:18> xtf Tracing: function
+>+(eval):7> print Tracing: ( builtin ) 2>file
+>+(eval):9> cat
+>+(eval):11> print Tracing: { builtin } 2>file
+>+(eval):13> cat
+>+(eval):15> print Tracing: do builtin done 2>file
+>+(eval):17> cat
+?+(eval):2> print Tracing: builtin
+?+(eval):3> print Tracing: builtin 2>file
+?+(eval):4> cat
+?+(eval):5> cat
+?+(eval):6> print Tracing: ( builtin )
+?+(eval):8> cat
+?+(eval):10> print Tracing: { builtin }
+?+(eval):12> cat
+?+(eval):14> print Tracing: do builtin done
+?+(eval):16> cat
+?+(eval):18> xtf Tracing: function
 ?+xtf:1> local regression_test_dummy_variable
 ?+xtf:2> print Tracing: function
-?+ZTST_execchunk:19> xtf Tracing: function 2>file
+?+(eval):19> xtf Tracing: function 2>file
 ?+xtf:1> local regression_test_dummy_variable
 ?+xtf:2> print Tracing: function 2>file
-?+ZTST_execchunk:20> . ./xt.in Tracing: source
+?+(eval):20> . ./xt.in Tracing: source
 ?+./xt.in:1> print Tracing: source
-?+ZTST_execchunk:21> . ./xt.in Tracing: source 2>file
+?+(eval):21> . ./xt.in Tracing: source 2>file
 ?+./xt.in:1> print Tracing: source 2>file
-?+ZTST_execchunk:22> set +x
+?+(eval):22> set +x
Index: Test/V01zmodload.ztst
===================================================================
RCS file: /cvsroot/zsh/zsh/Test/V01zmodload.ztst,v
retrieving revision 1.4
diff -u -r1.4 V01zmodload.ztst
--- Test/V01zmodload.ztst	2001/07/09 16:41:19	1.4
+++ Test/V01zmodload.ztst	2001/07/09 17:26:24
@@ -47,7 +47,7 @@
 
  zmodload zsh/main
 1:Test reloading an already-loaded module
-?ZTST_execchunk:zmodload:1: module zsh/main already loaded.
+?(eval):zmodload:1: module zsh/main already loaded.
 
 # Loop over the modules found above and attempt to load each one.  Use
 # the -i flag in case dependencies cause multiple modules to be loaded,

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: Debugging of dynamocally defined functions

[Bart Schaefer]

On Jul 9,  6:32pm, Peter Stephenson wrote:
} Subject: Re: Debugging of dynamocally defined functions
}
} The following is how perl does it, marking an `eval' as a separate
} environment.

I was fooling with almost exactly the same thing, though I'd been trying
to figure out a nice way to embed the line number of the eval inside the
`(eval)' string; e.g. for an eval on line 30 of the calling function you
would see something like

(30:eval):1: echo foo
(30:eval):2: echo bar

etc.  However, as the placment of %i and the use of colons or whatnot is
completely dependent on the PS4 setting, I couldn't decide how to do it
such that it wouldn't garble somebody's pretty prompt.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Debugging of dynamocally defined functions

[Peter Stephenson]

"Bart Schaefer" wrote:
> I was fooling with almost exactly the same thing, though I'd been trying
> to figure out a nice way to embed the line number of the eval inside the
> `(eval)' string; e.g. for an eval on line 30 of the calling function you
> would see something like
> 
> (30:eval):1: echo foo
> (30:eval):2: echo bar
> 
> etc.  However, as the placment of %i and the use of colons or whatnot is
> completely dependent on the PS4 setting, I couldn't decide how to do it
> such that it wouldn't garble somebody's pretty prompt.

Maybe we need to grab another prompt escape.  Or maybe we could make a
stack of environments and line numbers and you can choose whether you want
the line number (e.g.) in the innermost eval, in the function above that,
or in the script the function is embedded in, fixing the other problem,
too --- if we can work out a way of deciding which the right one to print
at any given time is.  Maybe this needs more work to make quite sure
scriptname and lineno are tied together.  Maybe we can add an option to get
errors to print a backtrace of that.  Maybe I'm rambling.

I've committed the patch for now.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: Debugging of dynamocally defined functions

[Bart Schaefer]

On Jul 9,  7:36pm, Peter Stephenson wrote:
} Subject: Re: Debugging of dynamocally defined functions
}
} "Bart Schaefer" wrote:
} > I was fooling with almost exactly the same thing, though I'd been trying
} > to figure out a nice way to embed the line number of the eval inside the
} > `(eval)' string; e.g. for an eval on line 30 of the calling function you
} > would see something like
} > 
} > (30:eval):1: echo foo
} > (30:eval):2: echo bar

There's one other extremely minor problem with this.

I have my PS4 string set to begin with ": " and end with ";" because then
I can cut'n'paste xtrace output and the PS4 stuff is discarded as a `:'
command.  But with the parens in there around the `(eval)', I get globbing
errors when I cut'n'paste.

} Maybe we need to grab another prompt escape.

I was toying with something like %N{...}, where you could use other prompt
escapes inside the {...} the way you can use strftime escapes in %D{...}.

But really what we'd need is a %(X.T.F) sort of thing, where X is true if
you're inside an eval, so that one could write

	PS4='%(e.(%i:eval%).%N)... '

Except that then we'd also need a way for %i to specify that it's actually
the saved line number from the surrounding scope, etc. etc.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net