[Bashdb-devel] Re: Bugfix patch for V cmd.

[R. B. <ro...@pa...>]

Mikael Andersson writes:
 > An updated patch  is attached (vcd-CVS-002.patch.

Many thanks. Will look at later.

 > As far as i understand the other tests was ok (some linenumbers were wrong
 > for me thou ) 

Yes, the line number mismatch from a stack traceback often happens
when code moves around. A better "diff" mechanism might be nice. In
some of the debugger regression tests there is some sort of grepping
to filter beforehand.

 > and that:
 > dq_args="variables dq*"
 > dq_cmd="info"
 > Should be the proper output from infor variables dq* if i understand it 
 > correctly. 

Probably, will double check.

 > I'll look into this and the linenumber issue i mentioned in the other mail. 
 > But we'll se if i'll be able to fix it. But i'll probably put off the 
 > linenumber issue until i've done with a proposed set of changes to 
 > automake/autoconf. 

When I get a chance I'll try to take a look. Probably easier for me to
find it and fix since I've seen something like this before (acutally,
several times). I'd rather do that than make to changes to automake; so
probably this is better division of labor and efficiency.

 > 
 > Mostly adding som substitution variables so that you
 > can move things around freely with --prefix etc. Also moved .inc files to 
 > /usr/share/$package as this should be the proper location as they are arch 
 > independant. Not all packages do like this, but perl and emacs seems to do it 
 > that way. And FHS [1] seems to agree also.

Okay, thanks. The reason we have open CVS and list management is so
that folks who have a vision as to how to improve things can, and I
welcome all suggestions and improvements folks have to offer.

It's been pretty quiet in bash development and bash debugger
development for quite a while.

 > Further i have enabled --program-transform-* (AC_ARG_PROGRAM macro) and added
 > an ALT_PACKAGE_NAME variable to be able to decide on what package name to use 
 > when installing.

Good. 

 > 
 > Now i have some questions :
 > 1) I have placed additional m4 macros in debugger/.. (ie bash-dir) in a file 
 > functions.m4. Is this a good idea or should i place them somewhere else ? The
 > are used in both bash configure.in and in debugger configure.ac

I don't have an opinion so I'll rely on yours. If someone down line
feels differently and makes a convincing case, we can change it later.

 > 2) What should be default package name ? As it is now it's bash and with my 
 > changes that will lead to arch independent data being installed in 
 > /usr/local/share/bash if --prefix is /usr/local.

In the source tree, I've tried to keep this sort of as two packages
even though they are closely related. There has to be a patched bash
which has improved debug support (whether or not you use the debugger
in the debugger directory). It is needed to fix bugs like the one you
recently discovered and to write any sort of decent debugger. Improvements
here I haven't been as agressive as in the debugger directory because
whenever the next version of bash comes out a big reconcilliation will
be needed. That's why we have configure.in vs debugger/configure.ac
and why no automake in bash.

And then there's the bash debugger code which really only works under
bash. My hope was that at some point in the future I wouldn't need the
patched bash since that would make it into the mainstream. As for the
debugger, even though it is very strongly bash-specific if I could
make it less-so to make porting say to David Korn's recent versions of
ksh easier, that would be nice. So for example I try to use "typeset"
instead of "declare" and subroutines were renamed from _bashdb_ to
_Dbg_.

I know I haven't answered your question. What I've been using for the
combined source is that rather long and ugly bash-2.05b-debugger. For
just the debugger code proper, "bashdb" is the top-level
script. There's probably a little confusion with the name "bashdb"
because there were toy debuggers also called bashdb that have nothing
to do with this other than it purports to debug bash.

In short that's data. Use your judgement and I think you'll do the
right thing.

 > 
 > 3) If i want to do side-by-side installation of bash and bashdb ( this is for 
 > use in gentoo) and not place it in /usr/local since /usr/local is reserved 
 > for system-administrator installed packages. And gentoo packages is not 
 > regarded as being in that category ( since otherwise all gentoo packages 
 > should fall in that category since they're all buld from scratch).
 > Have you got any suggestions as how to name the files ? It'd feels natural
 > to rename bash to bashdb and bashdb to bash-debugger (bdg .) ). but that
 > might be confusing to people who have already  used bashdb. 

For the POSIX shell, the idea/intention is that it is bash but with
enhanced error reporting and debugging support although it in of
itself isn't a debugger. Were the bug you found fixed, the improved
error line number reporting might be helpful to those who don't know
or care about the "bashdb" debugger in the package. How about bash+dbg?