bashdb-devel — Developer's discussion mailing list

[Bashdb-devel] eclipse, readarray

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

The problem with making an eclipse plugin for bashdb is that seems to
want to debug via some sort of out of process mechanism (and usually
via a socket). Right now bashdb doesn't have support for remote
debugging or debugging via a socket. 

As for readarray, sure, I think reading in a file into an array
quickly is a generally useful thing. Python has a fancier module
called linecache. Volunteers for sheparding this through?

[Bashdb-devel] bashdb-trace not installed (bashdb-3.1-0.06)

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

Folks - 

Noticed as a slight omission in the bashdb-3.1-0.06 release in that
bashdb-trace is not installed. bashdb-trace is needed if you want to
use set_trace (call the debugger from inside your BASH program).  

CVS sources have been fixed, the patch to Makefile.am should be
attached below.

[Bashdb-devel] readarray

[Masatake Y. <je...@gy...>]

Do you think bash itself should have readarray?
(I think so.)

Masatake YAMATO

[Bashdb-devel] eclipse

[Masatake Y. <je...@gy...>]

You may be interested in following article:
    http://www.eclipse.org/articles/Article-Debugger/how-to.html

Re: [Bashdb-devel] Another release (3.1-0.06) in a week or so

[Masatake Y. <je...@gy...>]

Could you review this patch and install it if you appreciate?

2006-07-22  Masatake YAMATO  <je...@gy...>

	* emacs/bashdb.el (bashdb-bashdbtrack-overlay-arrow): Don't set value to pos.
	Fix a typo.
	(bashdb-bashdbtrack-track-stack-file): Put target_buffer to let*'s variable 
	list.

--- bashdb.el.orig	2006-07-22 16:33:44.000000000 +0900
+++ bashdb.el	2006-07-22 16:34:58.000000000 +0900
@@ -340,13 +340,12 @@
   ;; This was derived/simplified from edebug-overlay-arrow
   (cond (activation
 	 (setq overlay-arrow-position (make-marker))
-	 (setq pos (point))
 	 (setq overlay-arrow-string "=>")
 	 (set-marker overlay-arrow-position (point) (current-buffer))
 	 (setq bashdb-bashdbtrack-is-tracking-p t))
 	(bashdb-bashdbtrack-is-tracking-p
 	 (setq overlay-arrow-position nil)
-	 (setq bashdb-bashdbtrack-tracking-p nil))
+	 (setq bashdb-bashdbtrack-is-tracking-p nil))
 	))
 
 (defun bashdb-bashdbtrack-track-stack-file (text)
@@ -377,7 +376,7 @@
                                            (- procmark
                                               bashdb-bashdbtrack-track-range))
                                       procmark))
-             target target_fname target_lineno)
+             target target_fname target_lineno target_buffer)
 
         (if (not (string-match (concat bashdb-bashdbtrack-input-prompt "$") block))
             (bashdb-bashdbtrack-overlay-arrow nil)

[Bashdb-devel] Another release (3.1-0.06) in a week or so

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

There have been a number of small put important changes. Basically
working on extending the Python debugger has helped this project out
and I've tried to make the code bases be more alike.

If folks can try out what's on CVS that'd be great. If there's
interest in making a candidate tarball, let me know.

Here's what I have in the NEWS file:

- Add gdb 'commands' command: 
  runs debugger commands at a specified breakpoint

- Add gdb 'info program'. (Shows program status)

- Add ability to invoke from inside a running program rather than
  at the outset (set_trace)

- Add a better line tracing:
   * shows bash nesting, 
   * bash subshell nesting
   * function nesting
   * source line preserving initial indentation

- Add line tracing command-line option in bashdb: -X, and long option --trace

- add ability to turn on and off line tracing from inside a program

- Revise sample sessions in bashdb document

- Sourcing a debugger command file now prints the 
  command before executing it.

- Executing a string (option -c or --command) shows the command
  to be run in the call stack.

- Attempt to get documentation on GNU Emacs section in order. Describe
  bashdbtrack.

[Bashdb-devel] linetracing via the debugger.

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

First a little recap: through involvment with the Python debugger and
feedback from that I've extended the bash debugger to allow calling
the debugger in the middle of a complex script. It has a benefit of
not causing a slowdown for the part of the code that doesn't need
debugging. (And in bash much more that Python this is needed.)

Sourceforge CVS is back so I've committed these changes.

One of the things I've always found annoying about "set -x" traces is
that there is no position information given in the trace output, in
particular the line number and the file name.  Although function
nesting information is shown, other important Information such as BASH
shell and subshell nesting count is not.  From a programming
standpoint, these are just as important because they affect the
namespace, or the scope over which variables are seen.

Although I this is best fixed inside BASH, the debugger provides a way
to do better I think. So I've just added and committed "set linetrace"
on. Here's a simple session.

/usr/local/bin/bashdb /tmp/fact.sh

Bourne-Again Shell Debugger, release bash-3.1-0.05
Copyright 2002, 2003, 2004, 2006 Rocky Bernstein
This is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.

(/tmp/fact.sh:11):
11:	echo fact 0 is: `fact 0`
bashdb<0> set linetrace on
bashdb<1> cont
(/tmp/fact.sh:11):
level 1, subshell 1, depth 0:	echo fact 0 is: `fact 0`
fact 0
(/tmp/fact.sh:2):
level 1, subshell 1, depth 1:	fact() @{
(/tmp/fact.sh:3):
level 1, subshell 1, depth 1:	    local -i n=$@{1:0@}
(/tmp/fact.sh:4):
level 1, subshell 1, depth 1:	    ((n==0)) && echo 1 && return
(/tmp/fact.sh:4):
...

An explanation of the output. The "level" is how many invocations of
BASH are in effect before the statement shown is executed. The
"subshell" is how many subshells you are nested in. The depth is the
function depth or how many calls you are nested in. (A ``source''
command also increases this depth.)

Notice also that in contrast to "set -x" tracing, the line shown
is exactly as you entered it in the source. 

As this is new, if folks have comments or suggestions now is the best
time to voice them.

Thanks

[Bashdb-devel] Debugging inside a long or complicated program or speeding up debugging

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

In working with a debugger for python, I noticed a nice feature which
just had a chance to code up and try out in the bash debugger.

Rather than start a script inside the debugger, the python debugger
allows one to load the debugger at any place in the script and then
issue a call to enter give control to the debugger. 

Here's an example script 

  # Lots of stuff here. ...
  x=2
  source /usr/local/share/bashdb/bashdb-trace # or whereever
  _Dbg_set_trace
  y=3

You will be stopped before y=3 in the debugger. This mechanism allows
one to run lots of complex code which might otherwise get messed up by
the debugger. Another use might be in a large script where running the
debugger every step (e.g. configure) is just too slow.

- - -

At present I can't commit any of this code as sourceforge CVS is down
and has been so for two days. (Ironically, this is right when
sourceforge send out its monthly status report which was bragging
about how great they've been working hard on improving things
including reliablity.)

[Bashdb-devel] Re: ugly code in install-data-hook

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

Eric Blake writes:
 > -----BEGIN PGP SIGNED MESSAGE-----
 > Hash: SHA1
 > 
 > According to Eric Blake on 2/16/2006 10:29 PM:
 > > The following code in Makefile.am's install-data-hook has a severe bug,
 > > and I'm not sure how to work around it.  

Maybe a start is to describe what the bug is and what's severe about
it. While we are being severe, I'd say the fact that bash has a
hardcoded (and usually wrong) location of where the debugger init file
is pretty lame. ;-) 

It doesn't take much imagination to say change --debugger to add an
optional argument for where the init script is. The idea was that
perhaps there could be more than this debugger (or different versions
of this debugger) around. It would also allow users to install bashdb
without (generally) needing system-level access or installing their
own bash. If someone want's to make a suggestion using bashbug please
do. I've had my fill of bashbug reporting.

 > > Furthermore, the code is tied to
 > > GNU make, and is not portable to other make programs:

You are correct, it is a deficiency. But given the situtation there
aren't that many choices. I suppose one could write some sort of
standalone script that does the install hook thing. I suppose that would
be better in that it would be Makefile independent.

 > But, as long as we are requiring GNU make, the attached hack seemed to do
 > the trick (it depends on the -ef operator in GNU coreutils' test, and I
 > don't know of any other easy way to prove that /foo and /foo/ are (not)
 > the same directory in makefile syntax).  

Actually "test -ef" is probably more reliable than whatever could be
done in some sort of Makefile mechanism which as you say probably
wouldn't translate to make's other than this or that one.

 > Please don't install this hack as
 > an official patch; rather, use it as a starting point for what needs to be
 > improved in this hook to overcome its current bug.

If you don't want this installed, it won't be installed. That's your
call.  As for improving, do we have any volunteers out there?

[Bashdb-devel] VPATH build patches

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

Thanks for the patches. They've now been applied for both 3.00 and
3.01.  An additional patch was needed to make this work *not* using
VPATH in some cases.

[Bashdb-devel] VPATH build patches

[Eric B. <eb...@by...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The following patch is needed for a VPATH build to succeed (in a CVS tree,
do: mkdir build; cd build; ../configure; make; make check).  This is the
entire patch for the cygwin release of bashdb-3.1-0.04, except for the
previously reported bug with install-data-hook obliterating just-installed
files if bash and bashdb are both configured to use the same
bashdb-main.inc.  The patch is against CVS head of the bash-3.1
subdirectory; if you are still maintaining the bash-3.00 subdirectory it
will be needed there too.

2006-02-18  Eric Blake  <eb...@by...>

	* configure.ac (AM_PROG_CC_C_O): Required by CVS automake.
	(DIFF_OPTS): In VPATH build, ./configure doesn't exist.
	* .cvsignore (config.cache): Add another file to ignore.
	* test/Makefile.am (TESTS_ENVIRONMENT, abs_srcdir, abs_builddir):
	Add, to make VPATH builds testable.
	* test/bugIFS.tests (debugged_script): Look in correct directory
	during VPATH build.
	* test/run-multi (TEST_FILE): Ditto.
	* test/run-skip (TEST_FILE): Ditto.
	* test/run-subshell (TEST_FILE): Ditto.

- --
Life is short - so eat dessert first!

Eric Blake             eb...@by...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD9zt/84KuGfSFAYARAg5jAKCwyExUwaUeVO9k9lIM6ui739aBSwCgiTHr
gsDfD2Vi3x36jJCD5t3LzY0=
=IOP0
-----END PGP SIGNATURE-----

[Bashdb-devel] Re: ugly code in install-data-hook

[Eric B. <eb...@by...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Eric Blake on 2/16/2006 10:29 PM:
> The following code in Makefile.am's install-data-hook has a severe bug,
> and I'm not sure how to work around it.  Furthermore, the code is tied to
> GNU make, and is not portable to other make programs:

But, as long as we are requiring GNU make, the attached hack seemed to do
the trick (it depends on the -ef operator in GNU coreutils' test, and I
don't know of any other easy way to prove that /foo and /foo/ are (not)
the same directory in makefile syntax).  Please don't install this hack as
an official patch; rather, use it as a starting point for what needs to be
improved in this hook to overcome its current bug.

- --
Life is short - so eat dessert first!

Eric Blake             eb...@by...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD9WJ/84KuGfSFAYARAj1QAKDCIEs5MHI190v+HctXaPWhjvd8eACg1Kq4
bk4jPjc9hkUwImixfjI41Hs=
=PBlz
-----END PGP SIGNATURE-----

[Bashdb-devel] ugly code in install-data-hook

[Eric B. <eb...@by...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The following code in Makefile.am's install-data-hook has a severe bug,
and I'm not sure how to work around it.  Furthermore, the code is tied to
GNU make, and is not portable to other make programs:

#
# This is ugly. Bash 3.0 requires things to be different than where
# many OS's would want to put bash debugger scripts or where a user
# may have asked for this to be put. It's wrong in the directory
# names it uses and for the name of the main include.
# So... using the place that configure determined bash
# wants this to be put, (BASHDB_MAIN), we try to remove any existing files
# before making a symbolic link to it. Also if was in a directory
# (containing perhaps old code), that gets removed and a symbolic link
# is added or relocated if there was another symbolic link. Finally
# the basename that bash wants to use is symlinked to the main name
# that this distribution uses dbg-main.inc, unless those are the same.
#
OLD_DIR :=$(dir @BASHDB_MAIN@)
OLD_MAIN:=$(notdir @BASHDB_MAIN@)
PARENT_DIR:=$(dir $(OLD_DIR))
install-data-hook:
	@if test -e @BASHDB_MAIN@ ; then \
	  if test $(OLD_MAIN) != dbg-main.inc ; then \
	    $(RM) @BASHDB_MAIN@ || true; \
          fi; fi
	@if test -d $(DESTDIR)$(OLD_DIR) ; then \
	     $(RM) -fr $(DESTDIR)$(OLD_DIR:/=) || true; \
	else if test -L $(DESTDIR)$(OLD_DIR:/=) ; then \
	     $(RM) -f $(DESTDIR)$(OLD_DIR:/=) || true; \
	fi; fi
	test -d $(DESTDIR)$(PKGDATADIR) || $(mkdir_p) $(DESTDIR)$(PKGDATADIR)
	$(LN_S) $(DESTDIR)$(PKGDATADIR) $(DESTDIR)$(PARENT_DIR:/=) || true
	@if test dbg-main.inc != $(OLD_MAIN) ; then \
	  ( if cd $(DESTDIR)$(pkgdatadir) ; then \
	     test -e $(OLD_MAIN) && $(RM) $(OLD_MAIN); \
	     $(LN_S) dbg-main.inc $(OLD_MAIN) || \
	     echo "WARNING: I'm having trouble letting bash know where the
debugger is. Use the bashdb script only." ; \
	  fi ) \
	fi


In the case where bash was configured with DEBUGGER_START_FILE set in the
environment to the same location as where I configured bashdb
- --with-bashdb-main, then OLDDIR and PKGDATADIR are the same directory, and
'make install' proceeds to install all the dbg-*.inc files, then calls the
hook which removes the directory containing all the newly installed
dbg-*.inc files, leaving a crippled installation.

This is the case on cygwin because I maintain both the bash and bashdb
packages, so I can coordinate the two configure runs to use the same
location for the debugger main entry point.

An informative trace from 'make install', where I manually replaced all
the instructions in install-data-local with echos of what would otherwise
run, shows:

...
 /usr/bin/install -c -m 644 '/tmp/bashdb-3.1-0.04/dbg-set-d-vars.inc'
'/tmp/bashdb-3.1-0.04/.inst/usr/share/bashdb/dbg-set-d-vars.inc'
make  install-data-hook
make[3]: Entering directory `/tmp/bashdb-3.1-0.04/.build'
if test -e /usr/share/bashdb/bashdb-main.inc ; then  if test
bashdb-main.inc != dbg-main.inc ; then  /usr/bin/rm
/usr/share/bashdb/bashdb-main.inc || true;  fi; fi
if test -d /tmp/bashdb-3.1-0.04/.inst/usr/share/bashdb/ ; then
/usr/bin/rm -fr /tmp/bashdb-3.1-0.04/.inst/usr/share/bashdb || true;  else
if test -L /tmp/bashdb-3.1-0.04/.inst/usr/share/bashdb ; then  /usr/bin/rm
- -f /tmp/bashdb-3.1-0.04/.inst/usr/share/bashdb || true;  fi; fi
echo 'test -d /tmp/bashdb-3.1-0.04/.inst/usr/share/bashdb || mkdir -p --
/tmp/bashdb-3.1-0.04/.inst/usr/share/bashdb'
test -d /tmp/bashdb-3.1-0.04/.inst/usr/share/bashdb || mkdir -p --
/tmp/bashdb-3.1-0.04/.inst/usr/share/bashdb
echo 'ln -s /tmp/bashdb-3.1-0.04/.inst/usr/share/bashdb
/tmp/bashdb-3.1-0.04/.inst/usr/share/bashdb || true'
ln -s /tmp/bashdb-3.1-0.04/.inst/usr/share/bashdb
/tmp/bashdb-3.1-0.04/.inst/usr/share/bashdb || true
if test dbg-main.inc != bashdb-main.inc ; then  ( if cd
/tmp/bashdb-3.1-0.04/.inst/usr/share/bashdb ; then  test -e
bashdb-main.inc && /usr/bin/rm bashdb-main.inc;  ln -s dbg-main.inc
bashdb-main.inc ||  echo "WARNING: Im having trouble letting bash know
where the debugger is. Use the bashdb script only." ;  fi )  fi

- --
Life is short - so eat dessert first!

Eric Blake             eb...@by...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD9V9H84KuGfSFAYARAvcmAKC8r4CR4I0qu3XgBOTUKJCtTc6mRQCgvNYy
BxR1Np+tfJsu5UUFKaRqifE=
=CYLz
-----END PGP SIGNATURE-----

[Bashdb-devel] just another make debugger?

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

Masatake YAMATO writes:
 > Do you know this article?
 > http://www.cmcrossroads.com/ubbthreads/showflat.php?Number=52560

It seems a tour-de-force effort. Clever for what one can manage to
squeeze out of GNU Make. The debugger builds on that author's other
GNU Make tour-de-force set of macros called GMSL which adds boolean
operations and some simple mathematical functions to GNU Make.

Although from a theoretical standpoint this is interesting and clever
-- implementing integers by representing them in unary as lists --
clearly if this is needed it should be done inside GNU Make. (But
prototyping it as GNU make macros as the author has done is clearly a
great idea!) One consequence of GMSL's unary word-list approach to
representing numbers is that it doesn't scale all that well - at
present only numbers up to something like 256 can be represented. And
as numbers get larger it takes linearly longer (rather than
logarithmically longer) to count/convert them.

Getting back to the GMD (the debugger) rather than GMSL.  I think one
of its strong points is in helping out with the macro expansion phase
of GNU make which occurs before any dependency checking is done.

I tried using it and, alas, I didn't find it very helpful in any of
the problems I've encountered using GNU Make and automake. That said,
if others have tried this and generally found it effective, I'd be
interested learning of those experiences -- what one did to track down
the GNU Make problems using this tool, etc.

The GMD approach does have an advantage of working on top of the
existing GNU Make 3.80. It would have more of an advantage if it
supported make systems other than GNU Make with versions equal or
close to 3.80.  And finally, one needs to
modify your Makefile to add: 
  include gmd
in order to use the debugger.

Hmmm... Perhaps I should add a command-line option allow one to
specify an include command to get run before makefile processing. In
any event, GNU Make currently doesn't have any such thing.

So:
1) the narrow range of "make" systems supported (same as remake)
2) the need to have this extra code around (same as remake) and 
3) the need to modify a makefile to put in the include (*not* 
   required by remake)

narrows the gap between compiling and installing another binary such
as remake versus this approach.

But although *not* having to install a new binary is an advantage, I
think that's also a disadvantage, For me it's deja vu. Recall that
before my patches to bash 2.05b, writing a debugger for Bash was
really not usable in practice. Really the problem lay in Bash, not
someone's ability to write debugger code via "trap DEBUG".

Sadly, I think the same is true for GNU Make.

One last thought. Although I haven't contacted the author of GMSL/GMD
about this, it might be possible to include one this along with remake
or a stripped-down version with the slow parts (like integer
conversion) implemented in GNU Make. In other words get the best of
both worlds. However remake is still too new, still too much out of my
control and perhaps even too fragile to widen its scope larger at this
point. (If others got involved - hint, hint - that might be a
different story ;-)

[Bashdb-devel] just another make debugger?

[Masatake Y. <je...@gy...>]

Do you know this article?
http://www.cmcrossroads.com/ubbthreads/showflat.php?Number=52560

[Bashdb-devel] bashdb.el and bashdb script

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

Mel HE recently mentioned having a problem in not being able to run
the debugger from inside GNU Emacs.

In all bashdb all releases, GNU Emacs bashdb.el runs "bash --debugger"
which requires the debugger to be installed in a way that bash can
find it. No matter how I've tried to improve installation, getting
"bash --debugger" to work has always been problematic.

In looking at ways to make things more reliable I've made the a change
to bashdb.el so that it will allow one to run the bashdb script as
well as "bash --debugger". It now adds "--debugger" unless the program
to be run matches "bashdb" at the beginning of the command line (with
a possible pathname before "bashdb").

Also in going over bashdb.el I see that current practices allow
numeric paramenters on "step" and "next" commands and that filenames
on tbreak and break are always filled in. There are probably other
small changes to bashdb.el that should be made to make more full use
of what GNU Emacs gud has to offer.

In thinking about how to get GNU Emacs to work with bashdb, I also
realized that there is GNU long getopt routine called "getopt";
"getopts", which is built in to Bash, handles only short options.
That is used as a fallback when the long-option routine ("getopt") is
not available.

After making the to bashdb to support long options, I now allow
--debugger as a bashdb option which is just ignored. The idea here is
that one should be able to run bashdb --debugger just as one can run
bash --debugger and that may make things more transparent to
front-ends like GNU Emacs which previously always forced the
--debugger option.

I don't have a feel for whether any of these changes warrants a new
release, probably not. But I as always I accept guidance from others
and or comments on the above.

[Bashdb-devel] bashdb 0.04 out. One addendum

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

0.04 is out. 

I noticed after release that I omitted to mention anything about *how*
to get the speedup. One needs to have the bash headers and objects to
compile and link against. And they've change between 3.0 and 3.1 so
you have to have the right one for your version.

Assuming this, one also needs to use the --with-bash-src option so the
debugger will find the sources to use. And of course, the source
should be compatible with the --with-bash option or the one bash that
is found automatically if --with-bash is not specified.

Finally, when using --with-bash, it is best to use an absolute path or
the regression tests will fail in trying to find the bash.

Cheers...

Re: [Bashdb-devel] Last call for testing of bash 3.1 and bash 3.0 (release 0.04)

[Masatake Y. <je...@gy...>]

> My thought right, is that unless major problems are discovered, bash
> 3.1 and bash 3.0 (release 0.04) will be released Monday.

As far as my understanding, it seems that readarray is intalled to
${prefix}/share/bashdb/.  If not, ignore the following sentences. If
this issue was already discussed before, forgive me.

I think readarray should be installed to ${prefix}/lib,
${prefix}/libexec/bashdb, or ${prefix}/bin because it is a binary
file.

Masatake YAMATO

[Bashdb-devel] Last call for testing of bash 3.1 and bash 3.0 (release 0.04)

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

My thought right, is that unless major problems are discovered, bash
3.1 and bash 3.0 (release 0.04) will be released Monday.

[Bashdb-devel] debugger for bash 3.1 largely works

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

With the last round of changes, the debugger works on bash 3.1.  

It seems that bash 3.1 added a restriction to file-descriptors:

   Redirections using file descriptors greater than 9 should be used
   with care, as they may conflict with file descriptors the shell uses
   internally.

I haven't a clue as to what "with care" means here, but bashdb
lovingly and tenderly starts using file descriptors for reading in
debugger commands *exactly* at nine. A real bummer how bashdb foresaw
exactly where bash was going to cause an incompatibility. And no
matter how much care I put into that statement it seems not to
work. So I've lowered bashdb's starting file descriptor to 4. However
I don't know if this will cause some bash scripts which use file
descriptors of their own to fail. Sigh.

(It probably would been nice for bash use a higher-numbered file
descriptor - I believe even on the smallest OS there are at least 256
of them that can be used.)

The good news is that regression tests that were be removed between
2.05b and 3.00 due to the breakage from 3.00 now work. So indeed,
correct reporting next statement to executed in a line now works
as it did in 2.05b.

I've tested this on GNU/Linux and cygwin. On GNU/Linux everything is
fine and I've tried with both my built-in readarray (which speeds
startup) and without.

On cygwin there is one not-important difference how filenames are
reported in output. I may look into that. I haven't yet been able to
compile readarray because of loader differences. Also the loader can't
find GNU getline.

But given the progress, there will probably be new releases of the
debugger for bash 3.0 an bash 3.1 in the not too distant future.

Re: [Bashdb-devel] bash 3.1 vs bash 3.0 differences

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

Eric Blake reports (on the use of backtic in array declarations):
 > This issue has been reported several times; official patch 1 is
 > supposed to fix it, but you need a one-line unofficial patch on top
 > of that for array assignments - see the thread at:
 > http://lists.gnu.org/archive/html/bug-bash/2005-12/msg00060.html

Okay - thanks for the information! It is easier to just not use that
construct than to require folks get the patches. (Although, no doubt
cygwin folks will be fortunate to have the right patches applied for
them. ;-)

 > > And instead of:
 > >       if [[  $basename == '$cdir' ]] ; then
 > > 
 > > what seems to work is:
 > >       if [  $basename = '\$cdir' ] ; then
 > 
 > Not quite the same.  [[ ]] has different semantics than
 > [ ] (for example, [[ does not perform word splitting, while
 > [ does, so if $basename has spaces, you would need to
 > quote it in the latter).

Okay -thanks again for the information. I've put back [[. It seems
that the operable part is '$cdir' versus '\$cdir'.

 > However, I wonder where you are assigning $basename
 > before using it in [[ ]].  

The place it comes up is in dbg-file.inc. Look around line 114. You
can also look at recent commits to CVS to find this too.

Re: [Bashdb-devel] bash 3.1 vs bash 3.0 differences

[<eri...@co...>]

> I've started to look into making the bash debugger work on bash 3.1.
> As with bash 3.0, I've checked this in as a separate location
> (bash-3.1) rather than make a branch of either bash-3.00 or of bashdb
> (for 2.05b).
> 
> In bash 3.0 whereas in the bashdb code one could do this:
> 
>     local -a fns_a=(`declare -F`)
> 
> what now seems to work is:
> 
>     local -a fns_a
>     fns_a=(`declare -F`)

This issue has been reported several times; official patch 1 is
supposed to fix it, but you need a one-line unofficial patch on top
of that for array assignments - see the thread at:
http://lists.gnu.org/archive/html/bug-bash/2005-12/msg00060.html

> 
> using $() for `' makes no difference.
> 
> And instead of:
>       if [[  $basename == '$cdir' ]] ; then
> 
> what seems to work is:
>       if [  $basename = '\$cdir' ] ; then

Not quite the same.  [[ ]] has different semantics than
[ ] (for example, [[ does not perform word splitting, while
[ does, so if $basename has spaces, you would need to
quote it in the latter).

> 
> I don't know if the incompatibility is intentional or not; if the
> mistake was my prior misuse of the language. I report the above in
> case others have problems or in case someone else wants to investigate
> or make a bug report if one is warranted.

Bash 3.1 does have the same bug as bash 3.0 in that [[ ]]
does not affect the value of $PIPESTATUS, but as that bug
is not a regression, I don't see it affecting you here.

However, I wonder where you are assigning $basename
before using it in [[ ]].  I was unable to reproduce a failure
in [[ ]], and wonder if instead you used some other construct
earlier on where bash 3.0 mistakenly expanded quotes twice,
but where bash 3.1 correctly only expands quotes once (again,
this is related to the earlier change in array parsing syntax,
and in the thread mentioned above, Chet Ramey did mention
that more quoting characters are preserved).

My test case:
bash-3.1$ basename=abc
bash-3.1$ [[ $basename == '$abc' ]] && echo yes
bash-3.1$ basename='$abc'
bash-3.1$ echo $basename
$abc
bash-3.1$ [[ $basename == '$abc' ]] && echo yes
yes
--
Eric Blake

[Bashdb-devel] bash 3.1 vs bash 3.0 differences

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

I've started to look into making the bash debugger work on bash 3.1.
As with bash 3.0, I've checked this in as a separate location
(bash-3.1) rather than make a branch of either bash-3.00 or of bashdb
(for 2.05b).

In bash 3.0 whereas in the bashdb code one could do this:

    local -a fns_a=(`declare -F`)

what now seems to work is:

    local -a fns_a
    fns_a=(`declare -F`)

using $() for `' makes no difference.

And instead of:
      if [[  $basename == '$cdir' ]] ; then

what seems to work is:
      if [  $basename = '\$cdir' ] ; then

I don't know if the incompatibility is intentional or not; if the
mistake was my prior misuse of the language. I report the above in
case others have problems or in case someone else wants to investigate
or make a bug report if one is warranted.

[Bashdb-devel] potential bashdb speedup in reading script lines

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

I was thinking about one source of slowness in bashdb - reading in the
script file to be debugged. 

We read in the source file in order to be able to accurately display
the source code that bash is running against. If bashdb used an
external command like "head", "tail", or "pr", the file could be
changed in the course of the run of the program. (In fact, I often do
this.) Bash however would not pick up the line changes until the
program is restarted. Since we rely on line numbers to set
breakpoints, it is helpful for the line numbers to match those that
bash reports.[1]

In order to speed up reading source files into arrays, I've been able
to create a built-in routine that does just that. Testing using the
28,000-line configure script for bash, the difference in time was
something like 9 seconds (real time) for the builti-in routine versus
40 seconds for what is currently used -- a loop over each line of the
file with a eval of a read.

The downside of this approach is that the built-in routine would only
run for the the version of bash it is compiled against, and to compile
the source I guess folks would need the bash sources around. It's
possible this routine might have to get changed from version to
version.

My experience with writing built-in routines is that if something is
wrong, the routine or bash dies without much information, and I
haven't been able to figure out how to easily debug such built
ins. This makes a more highly optimized routine a bit tougher - right
now I just call a routine to do repeated array assignments; for each
assignment, a function lookup of the variable name is made; and on
each line flags are tested to see if the assignment is okay (i.e. not
read only).

To compensate for the difficulties of having sources to compile
against, I suppose the debugger could have two versions of some
routines - some that work with the built in and some that don't.

Lastly, in the back of my mind I think it would be beneficial to push
more of this into bash itself - if there is not already a way to do
this. (I think the last time I looked I couldn't find something simple
without changing code.)  That is, it woudl be nice if one could ask
bash for the source code for a given file and line -- it keeps some
sort of internal representation of it which it unparses when it does
set -x tracing.

And the notion of asking more of bash is related to another big source
of slowness in the debugger: traps get called after every statement
just to figure out if it's time to enter the debugger. (Most of the
time the answer is no). A better organization would be to register a
line or function name to the bash and have bash do at least
preliminary checking.

- - - 
[1] If one sets a breakpoint on a function, internally it gets turned
into a file/line number. So if one tries to debug this script:

line=1; 
line=2; dbg() { echo "dbg called"; }
line=3;
dbg
exit 5

You won't be able to set a breakpoint on dbg until line 3 is reached
because dbg isn't defined until then. And if one then restarts, an
continues, the breakpoint occurs before the assignment line=2. I
suppose this is a bug. 

[Bashdb-devel] Planning another release

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

Occasionally, I need use the bash debugger at work via (probably) the
only GNU/Linux RPM that's available - SuSE Packman. However there have
been a couple of installation bugs in the current release that have
made installation not automatic, and thus a little annoying.

With progress in the GNU Make debugger, I was able to use that to
delve into the Makefile and figure out the hackery that is needed to
get a stock Bash 3.00 find installation paths the debugger. (In
particular, I used the make debugger's "write" command to create a
script and then bashdb to debug that).

As usual, I've put a candidate tarball at
http://bashdb.sourceforge.net/bashdb-3.00-0.03cvs.tar.gz

Barring objections, it will become a release in a reasonable amount of
time.

Thanks.