zshdb ready for stalwart hackers

["Rocky Bernstein" <rocky.bernstein@xxxxxxxxx>]

I think zshdb is good enough for stalwart hackers to get an initial
feel for it. To try out

   git-clone git://github.com/rocky/zshdb.git
   cd zshdb
   ./configure # possibly --with-zsh=/location/of/cvs/zsh
   make && make test
   sudo make install # if happy with the above

But to play the game you really do need a recent version of zsh. That
is, from CVS - recall that there was a  patch recently to make fc work
when not interactive (and funcfiletrace addition, line number
corrections, exec status code bug fix, etc.)

What's there is a little frail. These are some of the issues any
debugger (especially one written in zsh) has to deal with:
   setting emulation modes and zsh options, and built-in variables like IFS
   redirecting input/ouput and/or dev/nulling it
   using dynamic variables like $?
   running inside a subshell or nested shell.

zshdb does try to deal with all of this, but it has gaps which will
take time to work out.

Sometimes when zshdb runs into an error, the debugged program just
continues running to the end.

As before, a number of features that are in bashdb and the other
gdb-like debuggers I've worked on are not there yet. These include
conditions on breakpoints, display statements, logging options, and a
gdb "return" statement (but here I think I'm waiting on support inside
zsh).

But that said, I've been able to use it without total disaster on
large configure files and start/stop scripts that source other files,
and scripts that have redirections in them and so on.

If past experience is a guide, folks will come up with lots of
features they'd like to see. It's all zsh code, so feel free to jump
in add add what you want. :-)

As before an overall guide or document is lacking. If you are familiar
with gdb or any of the gdb-like debuggers I've worked on (bashdb,
pydb, ruby-debug, remake), this is like that. Probably closest of
course to bashdb with a little bit of a face lift.

Share and enjoy!