zsh-workers
 help / color / mirror / code / Atom feed
* line number reporting weirdnesses
@ 2008-08-30 14:49 Rocky Bernstein
  2008-08-31 15:55 ` Peter Stephenson
  0 siblings, 1 reply; 4+ messages in thread
From: Rocky Bernstein @ 2008-08-30 14:49 UTC (permalink / raw)
  To: Zsh hackers list

Some of odd the behavior I've noticed in how line numbers gets set (as
reported by funcfiletrace in trap DEBUG).

Consider this program:

#!/usr/local/bin/zsh -f
debug_hook() { print '====' ;  print $funcfiletrace[-1]; }
set -o DEBUG_BEFORE_CMD
trap "debug_hook" DEBUG
if [[ "$TERM" != bogus ]]; then  # line 5
[[ -z "$terminfo[kdch1]" ]] || bindkey -M emacs "$terminfo[kdch1]" delete-char
[[ -z "$terminfo[khome]" ]] || bindkey -M emacs "$terminfo[khome]"
beginning-of-line
[[ -z "$terminfo[kend]" ]] || bindkey -M emacs "$terminfo[kend]" end-of-line
fi
x='
line 11
line 12
line 13'
echo line 14

The output I get is:

====
./linebug2.sh:5
====
./linebug2.sh:5
====
./linebug2.sh:3920
====
./linebug2.sh:3920
====
./linebug2.sh:3920
====
./linebug2.sh:13
====
./linebug2.sh:14
line 14


There are two effects I think shown above.

First, the lines numbers of with [[ ]] inside if [[ ]] are weird -
there is no line 3920.

Second the line number in an assignment statement is basically the
line of the string token which spans several lines.  Possibly it might
be more helpful to give the line number of the LHS token.

What tends to happen say in a debugger is that someone will try to set
a breakpoint on one of the line numbers that most people would
associate with the weird line numbers (i.e. lines 6-8 or 10 above) and
lacking a way to report which line numbers are possible stopping
points as reported in funcfiletrace, people will get surprised when
none of those lines don't get reported or stopped at.

But of course the surprise is not limited to a debugger. Tools which
track code coverage, or tools to time scripts or just a program where
there is an error will also exhibit the weirdness.

(Ruby has this interesting feature too. No doubt it's an artifact of
LINENO getting set through a global variable tracking the the position
of the character previously read.)

- - -

Recently added to zshdb was the ability to "next" or step over
functions. It is possible way down the line stepping over functions
may be slow because there is tracing overhead inside a function. If
that's the case, more support in zsh might be warranted. Beforehand
though it's probably premature optimization which Knuth says is the
root of evil.


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2008-09-01  2:24 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-08-30 14:49 line number reporting weirdnesses Rocky Bernstein
2008-08-31 15:55 ` Peter Stephenson
2008-08-31 19:46   ` Peter Stephenson
2008-08-31 23:29     ` Rocky Bernstein

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).