wishing: zsh debugger (more thoughts)

[nwsgpamachine@xxxxxxxxxxxxxxxxxx]

All zsh lovers,

The purpose of this posting is to urge others to think about doing
some work on this subject.

In response to an earlier (12/7/06) message I posted about wishing
for a zsh debugger, two bash(db) developers have kindly written to
me.

I hope they don't mind me sharing some excerpts of their messages.

| Masatake YAMATO <jet@xxxxxxxx>:
| 
| F.Y.I bash has a really good debugger written by Rocky Bernstein. See
| 
|   http://bashdb.sourceforge.net/
| 
| bashdb is well documented. So it will be help to implement a debugger 
| for zsh.

and

| Rocky Bernstein <rocky.bernstein@xxxxxxxxx>
| 
| Thanks for the kind words.
| 
| I just looked at the excellent zsh documentation
| (http://zsh.sourceforge.net/Doc/Release/index-frame.html).  It has
| many interesting and nice features.
| 
| .....
| 
| There are some things added to bash mostly between versions 2.05b and
| 3.0 that might not be in zsh (yet). For example I see there is  a
| LINENO variable, and for functions it reports the position as the
| absolute position from the file it was included from - good! However
| in a debugger (or debugging tool such as line tracing), one would also
| probably want the name of the source file. And one would want this
| information for all of the routines in the current call stack.
| 
| Another thing that is nice (but not strictly necessary) would be a
| variable which stores the command that is about to be executed. If zsh
| doesn't already have these, I suspect these are pretty easy to add.
| 
| But even without these, one could probably write some sort of
| debugger.  However nice zsh is,  I don't have a need for using it and
| I can't  justify spending time on this. someone wants to undertake
| this, I'd be happy to answer questions or offer a little help. (Ditto
| for ksh93 which also has nice features and might be even easier to
| write a debugger for than bashdb was.)
| 
| One way to get started is to write a program that more or less
| simulates set -x. See
| http://sourceforge.net/mailarchive/forum.php?thread_id=31299742&forum_id=12061
| Even though this is not how bashdb was developed, I think it would be
| a good approach. The idea is that after you are convinced you can get
| some basic information about the program non-interactively, and that
| you cover tracing the entire program, adding a read loop and adding
| conditions under which you want to stop is pretty straightforward.
|
| ...
|
| I hope your have more luck with your hoping that I have had in the
| past. Or hope you will not not be disappointed if it doesn't happen.
|
| ...
|
| moral: one can suggest, hope, pray, and/or  wait. But if it's really
| important I've found it more expedient to just dig in. :-)

I went to the bashdb web site mentioned above and took a quick
glance. I think that Rocky et al have done an EXCELLENT job. I told
Rocky that I like zsh very much and have invested too much in it to
give it up at this moment, but the lagging of zsh behind bash in
this debugger aspect can very well discourage newcomers to choose
to learn zsh.

Based on some suggestions from Rocky and ideas from bashdb, I am
able to write a very rudimentary zsh debugger, using a combination
of perl and zsh. 

It is far far from perfect, and lacks a lot of desirable
functionality. But it is a proof that a zsh debugger is within
reach. Believe it or not, it is actually useful for debugging
scripts of moderate length. (I would have chosen perl for more
complicated tasks.) 

Will some smart zsh lovers out there be willing to devote some time
on developing a real zsh debugger?

My simple debugger can do:

  * Single stepping.

  * Set breakpoints using line numbers.

  * Print or set variable values while at a breakpoint.

  * Print current statement at breakpoint. Print next 10 statements.

  * Watch points are not implemented, but easy to do.

Drawbacks:

  - It can only deal with single-file scripts. 

  - Slow.

  - Does not handle stepping into or over a function well.

  - In a conventional debugger, setting a breakpoint means stopping
    before the breakpoint statement is executed. This debugger
    breaks after the breakpoint statement is executed. This is not
    so disastrous - if conventionally you set a breakpoint at line
    7, now you have to set it to the statement before line 7, in
    order for the debugger to stop right before executing line 7.

  - Another annoying thing is that before finishing a conditional
    block or a loop construct, it always step back to the first
    statement (the one with the conditon) of the block, before
    moving to the next statement after the block.

As seen from the development of bashdb, hacking into the zsh source
code is needed to get further. Will you zsh developers be interested?

I want zsh to continue to be the BEST shell available.

mk

********************************************************************

On Thu, 7 Dec 2006 09:53:01 -0600 (CST), mkkwong wrote:

> In my opinion, one thing that deters people from writing more
> complicated zsh scripts is the lack of a symbolic debugger. C/C++,
> Perl and Ruby all have one.
> 
> "zsh -x SCRIPT" helps but often it prints too much, much more than
> we really need. Say, if there is a bug near the beginning of the
> script, then the output from the later part of the program becomes
> mere noise and is distracting.
> 
> Wish that someone will write a debugger, even a very simple one to
> start out with can be greatly helpful. It only needs to have the
> capability to
> 
>    * step through line by line
>    * step into functions (at least for those defined within the
>      same script)
>    * set breakpoint for given line numbers
>    * print and set variable values while at a break point.
> 
> Making use of the output from "zsh -x", It is easy to write a perl
> script to simulate a fake-debugger that can do the first 3 bullet
> items. Someone more capable will have to write a real one that can
> do all 4.
> 
> mk kwong