bashdb-devel — Developer's discussion mailing list

Re: [Bashdb-devel] Planning remake 0.3 release

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

Typo?

--- remake.el	2004-05-22 09:33:48.000000000 +0900
+++ remake.el.new	2005-11-15 04:10:02.000000000 +0900
@@ -127,7 +127,7 @@
       buf)))
 
 
-(defcustom gud-remake-command-name "make -x"
+(defcustom gud-remake-command-name "make -X"
   "File name for executing make debugger."
   :type 'string
   :group 'gud)

[Bashdb-devel] Planning remake 0.3 release

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

Periodically I do use GNU Make + debugging/tracing and often it helps
me track down what's going on in Makefiles.

It's been over year since the last release and it is probably time to
flush out the various changes since then. Barring major problems, I'd
like to release within a week. 

So I'd appreciate it if folks try out what's in CVS and if there are
any major problems let me know or better just fix or suggest a fix.
I've also put a gzipp'ed tar in http://bashdb.sourceforge.net/remake-3.80+dbg-0.3cvs.tar.gz

Various problems remain. I don't use the debugger-enabled GNU Make in
place of the distributed GNU make for production work, only as a tool
to find out what's going on in a problem Makefile. And I was not not
planning on doing major last-minute overhauls, but I would like to fix
easy-to-solve bugs. 

Here's what's currently changed in this release: 

* tracing adds GNU Make "basic" debugging. If debugging, then we also
  enter the debugger read loop. Hopefully this adds more granularity
  but not the diarrhea that "make -d" gives. To reduce this, "next"
  could be used to skip over remaking targets that don't have
  commands.

* Allow abbreviations of debugger command attributes. As a result some
  attributes were renamed slighly, e.g. vars -> variables, deps ->
  depends, cmds -> commands. But note that since substrings are
  allowed, "command" and "com", and even "c" is the same as
  "commands".

* Make option --trace (-x) overrules using the --silent option and
  not echoing @ commands.

* "list" command renamed to "target". A future "list" command will 
  look more like gdb.

* fixed compilation issue(s) on systems that have readline, but do not
  have termcap.
  
* fixed failure of enter_debugger to exit on an empty line from
  readline.

* OS/X compilations fixes

[Bashdb-devel] Re: [PATCH] fix bashdb script handling of tmp directory

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

I've been meaning to thank Eric Blake for packaging the bash debugger
on cygwin (where others previously had either no interest or gave
up). So thanks!

That said, this bug report isn't relevant to full-fledged bash
debugger, but the older pot-bellied pig debugger which is included in
the bash distribution. In the past that code was a bit lacking,
probably still is and should be discarded (but given past history
probably won't be for a long time). The debugger from
http://bashdb.sourceforge.net in fact does understand "bashdb -V" and
"bashdb -h"

I'm sorry for the confusion of names that both are called bashdb. But
in truth there are probably a couple more bashdb's of historical
importance (unless you're running an old version of bash) which are
out there as well.  In the past, I tried calling the project rebash,
and source-code include files have been renamed from bashdb-main.inc
to dbg-main.inc. But alas confusion persists and I don't know how to
reduce it without a lot of work.

Finally, I should note that when submitting patches having them quoted
like this: 

> According to de...@fr... on 9/21/2005 11:53 AM:
...
> --- old-bashdb  2005-09-21 10:26:32.000000000 -0700
> +++ bashdb      2005-09-21 10:48:12.000000000 -0700
> @@ -509,11 +509,11 @@
>    fi

just makes it harder to apply the patch.


Eric Blake writes:
 > -----BEGIN PGP SIGNED MESSAGE-----
 > Hash: SHA1
 > 
 > [forwarding to bashdb-devel]
 > 
 > According to de...@fr... on 9/21/2005 11:53 AM:
 > > Configuration Information [Automatically generated, do not change]:
 > > Machine: i386
 > > OS: linux-gnu
 > > Compiler: gcc
 > > Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H  -I.  -I../bash -I../bash/include -I../bash/lib   -g -O2
 > > uname output: Linux dungeon2 2.6.11-1-k7-smp #1 SMP Mon Jun 20 22:34:51 MDT 2005 i686 GNU/Linux
 > > Machine Type: i386-pc-linux-gnu
 > > 
 > > Bash Version: 3.0
 > > Patch Level: 16
 > > Release Status: release
 > > 
 > > Description:
 > > 	Using bashdb on scripts with directory components in their names
 > > 	failes because it tried to create a temporary file in tmp
 > > 	without stripping the directories and it failes becuase the
 > > 	directories do not exist.
 > > 
 > > Fix:
 > > 	Included is a patch that strips the directory names from 
 > > 	$_guineapig before creating a temporary file.
 > > 
 > > 	For good measure it also strips the dirs before outputing the
 > > 	lines in the file.  It just makes it look better.
 > 
 > This patch is to bashdb, not bash.  Meanwhile, I just noticed that 'bashdb
 > - --help' and 'bashdb --version' are not accepted, and that neither 'bashdb
 > - -h' nor 'bashdb -V' output a bug-report address.
 > 
 > > 
 > > --- old-bashdb  2005-09-21 10:26:32.000000000 -0700
 > > +++ bashdb      2005-09-21 10:48:12.000000000 -0700
 > > @@ -509,11 +509,11 @@
 > >    fi
 > > 
 > >    if (( $line < 100 )); then
 > > -    _msg "$_guineapig:$line   $bp $cl${_lines[$line]}"
 > > +    _msg "${_guineapig/*\//}:$line   $bp $cl${_lines[$line]}"
 > >    elif (( $line < 10 )); then
 > > -    _msg "$_guineapig:$line  $bp $cl${_lines[$line]}"
 > > +    _msg "${_guineapig/*\//}:$line  $bp $cl${_lines[$line]}"
 > >    elif (( $line > 0 )); then
 > > -    _msg "$_guineapig:$line $bp $cl${_lines[$line]}"
 > > +    _msg "${_guineapig/*\//}:$line $bp $cl${_lines[$line]}"
 > >    fi
 > >  }
 > > 
 > > @@ -564,7 +564,7 @@
 > >  let _i=1
 > > 
 > >  # Be careful about quoted newlines
 > > -_potbelliedpig=${TMPDIR-/tmp}/$_guineapig.$$
 > > +_potbelliedpig=${TMPDIR-/tmp}/${_guineapig/*\//}.$$
 > >  sed 's,\\$,\\\\,' $_guineapig > $_potbelliedpig
 > > 
 > > Thanks,
 > > Devin Bayer
 > > 
 > > 
 > > 
 > > _______________________________________________
 > > Bug-bash mailing list
 > > Bug...@gn...
 > > http://lists.gnu.org/mailman/listinfo/bug-bash
 > > 
 > 
 > - --
 > 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
 > 
 > iD8DBQFDM0fy84KuGfSFAYARAthcAJ4kdxLnzgpveXaU1UJLsGpml+Tj4wCgpm4E
 > cRszTqsUUBzY5Q0FcstJ0SY=
 > =qIEM
 > -----END PGP SIGNATURE-----
 > 
 > 
 > -------------------------------------------------------
 > SF.Net email is sponsored by:
 > Tame your development challenges with Apache's Geronimo App Server. 
 > Download it for free - -and be entered to win a 42" plasma tv or your very
 > own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
 > _______________________________________________
 > Bashdb-devel mailing list
 > Bas...@li...
 > https://lists.sourceforge.net/lists/listinfo/bashdb-devel
 > 

[Bashdb-devel] Re: [PATCH] fix bashdb script handling of tmp directory

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

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

[forwarding to bashdb-devel]

According to de...@fr... on 9/21/2005 11:53 AM:
> Configuration Information [Automatically generated, do not change]:
> Machine: i386
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H  -I.  -I../bash -I../bash/include -I../bash/lib   -g -O2
> uname output: Linux dungeon2 2.6.11-1-k7-smp #1 SMP Mon Jun 20 22:34:51 MDT 2005 i686 GNU/Linux
> Machine Type: i386-pc-linux-gnu
> 
> Bash Version: 3.0
> Patch Level: 16
> Release Status: release
> 
> Description:
> 	Using bashdb on scripts with directory components in their names
> 	failes because it tried to create a temporary file in tmp
> 	without stripping the directories and it failes becuase the
> 	directories do not exist.
> 
> Fix:
> 	Included is a patch that strips the directory names from 
> 	$_guineapig before creating a temporary file.
> 
> 	For good measure it also strips the dirs before outputing the
> 	lines in the file.  It just makes it look better.

This patch is to bashdb, not bash.  Meanwhile, I just noticed that 'bashdb
- --help' and 'bashdb --version' are not accepted, and that neither 'bashdb
- -h' nor 'bashdb -V' output a bug-report address.

> 
> --- old-bashdb  2005-09-21 10:26:32.000000000 -0700
> +++ bashdb      2005-09-21 10:48:12.000000000 -0700
> @@ -509,11 +509,11 @@
>    fi
> 
>    if (( $line < 100 )); then
> -    _msg "$_guineapig:$line   $bp $cl${_lines[$line]}"
> +    _msg "${_guineapig/*\//}:$line   $bp $cl${_lines[$line]}"
>    elif (( $line < 10 )); then
> -    _msg "$_guineapig:$line  $bp $cl${_lines[$line]}"
> +    _msg "${_guineapig/*\//}:$line  $bp $cl${_lines[$line]}"
>    elif (( $line > 0 )); then
> -    _msg "$_guineapig:$line $bp $cl${_lines[$line]}"
> +    _msg "${_guineapig/*\//}:$line $bp $cl${_lines[$line]}"
>    fi
>  }
> 
> @@ -564,7 +564,7 @@
>  let _i=1
> 
>  # Be careful about quoted newlines
> -_potbelliedpig=${TMPDIR-/tmp}/$_guineapig.$$
> +_potbelliedpig=${TMPDIR-/tmp}/${_guineapig/*\//}.$$
>  sed 's,\\$,\\\\,' $_guineapig > $_potbelliedpig
> 
> Thanks,
> Devin Bayer
> 
> 
> 
> _______________________________________________
> Bug-bash mailing list
> Bug...@gn...
> http://lists.gnu.org/mailman/listinfo/bug-bash
> 

- --
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

iD8DBQFDM0fy84KuGfSFAYARAthcAJ4kdxLnzgpveXaU1UJLsGpml+Tj4wCgpm4E
cRszTqsUUBzY5Q0FcstJ0SY=
=qIEM
-----END PGP SIGNATURE-----

[Bashdb-devel] Fw: [bash-testers] Bash-3.1 alpha1 available for FTP

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

Masatake YAMATO writes:
 > F.Y.I.
 > 
 > > j.  BASH_COMMAND now preserves its value when a DEBUG trap is executed.

I tried building and running on the bash debugger's test/multi.sh test
program. It indeed addresses the regression in debugging between
rebash 2.05b and bash 3.00.00. However various other regression tests
fail and may need looking at.

(As always, volunteers are most welcome ;-)

[Bashdb-devel] Fw: [bash-testers] Bash-3.1 alpha1 available for FTP

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

F.Y.I.

> j.  BASH_COMMAND now preserves its value when a DEBUG trap is executed.

Is this something to do with bashdb?

[Bashdb-devel] bashdb: make check vs. VPATH build

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

Thanks for the patches and thanks for the analysis and report. I've
applied all that I could without breaking "make distcheck". The
ChangeLog entry has what was done.

As you note, more work is needed to make GNU make's VPATH work. 

I made an attempt to copy the debugger files dbg_*.inc from the source
directory to the build directory in configure.ac, but whatever I did
wasn't correct. Alas I tire easily of trying to coax configure.ac
and/or automake to do what strikes me as fairly straightforward
things. (Actually, a big motivation for the bash debugger itself is to
be able to cope better with the whole configuration/build system.). So
I leave this for someone else to work out or for some other time.

Some comments about the patches aside those already in the changelog
entry. In test/run-misc, I needed to set $builddir.  In your patch I
see some derived files which are not in CVS deleted, e.g.
dbg-pre.inc. So of course that doesn't do anything, but I guess it
does no harm either. 

Some derived files are still put in the distribution because of the -L
option problem in bashdb. You are correct that those should be removed
and would be were it not for my inability to know how to make "make
distcheck" work without doing so. On the other hand, if configure is
run as it should be those files should get overwritten.

Eric Blake writes:
 > I'm having trouble getting 'make check' to work when doing a VPATH build. 
...

[Bashdb-devel] bashdb: make check vs. VPATH build

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

I'm having trouble getting 'make check' to work when doing a VPATH build. 
To reproduce:

$ tar xzvf bashdb-3.00-0.02.tar.gz
$ cd bashdb-3.00-0.02
$ mkdir build
$ cd build
$ ../configure
$ make
$ make check

The problem is that the 3.00-0.02 distribution includes generated files, 
which is a no-no from autoconf's perspective.  If dbg-main.inc is generated 
at configure time (which it is), then you should only distribute 
dbg-main.inc.in.  Otherwise, bashdb-3.00-0.02/dbg-main.inc is what you 
distributed (and remembers your value of PKGDATADIR, among others), even 
though I want 'make check' to test using my 
bashdb-3.00-0.02/build/dgb-main.inc (with my PKGDATADIR).  Likewise with 
test/check_common, and so forth.

I tried editing the distribution, to make sure the tests are run on the 
built copies, but it leads to another problem.  Now, since some of the .inc 
files are in $(srcdir), while others are in $(builddir), the uninstalled 
bashdb will not work with its -L argument, because there is no one single 
directory to include.  Maybe the solution to use from here is to generate 
all of the .inc files, even though most of them have no autoconf @patterns@ 
to be replaced.  So, this patch is a good start, but needs more work before 
'make check' will work on a VPATH build.

2005-07-30  Eric Blake  <eb...@by...>

	* test/Makefile.am (check_DATA): Don't distribute generated files.
	* Makefile.am (pkgdata_DATA): Ditto.
	(pkgdatadir): Fix definition.
	(install-data-hook): Create dirname BASHDB_MAIN, if needed.
	* configure.ac (BASHDB_MAIN): Allow --with-bashdb-main to work.
	* test/run-*: Use built check_common.


-- 
Someday, I might put a cute statement here.

Eric Blake             eb...@by...

[Bashdb-devel] Thinking about a cleanup release

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

R. Bernstein writes:
 > "make distcheck" is closer to working, but now fails in testing the
 > "make install" because it gets DESTDIR is set wrong and I can't figure
 > out why. 

Change that. It now works.

[Bashdb-devel] Thinking about a cleanup release

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

I've been making some small changes not for functionality but to just
make things build with fewer errors such as - 
  - If texi2html isn't installed, don't give an error
  - allow regression tests to be run using the Bourne shell's /bin/sh
  - removing failed tests on bash 3.0

"make distcheck" is closer to working, but now fails in testing the
"make install" because it gets DESTDIR is set wrong and I can't figure
out why. If someone wants to investigate/fix, great otherwise we'll
leave it. 

I've currently tested on GNU/Linux, Solaris, cygwin. I'd appreciate it
if others would try. The CVS tag is "bash-3-00", and a candidate tarball is at
http://bashdb.sourceforge.net/bashdb-3.00-0.01cvs.tar.gz

[Bashdb-devel] bashdb PREFIX/share vs. PREFIX/lib

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

Alexander Mayer reports a problem the debugger scripts
got installed in the wrong place. 

Before the last change in CVS (so I guess this is true in the last
release) running ./configure with the appropriate --datadir (.e.g
/usr/local/lib) would probably work.

However I've just made a change in CVS so that Makefile picks up what
it discovers to be the natural place via looking at the bash code.

I'd like to set the default to the name that's been coded inside of
the bash program rather than some autoconf standard, since that is
what's used. But I don't know how to change the autoconf.

At this point in my life fed up with all the time I've spent coercing
automake and autoconf to what seems to me simple things. If someone
else want's to delve into the manure to suggest how to fix,
great. Otherwise we'll leave it as is. Basically setting datadir in
configure no longer works (in CVS) and pkgdatadir can only be set
implicitly via:

  --with-bash             location of bash 3.0 program
  --with-bashb-main       location of bashdb-main.inc

 > -----BEGIN PGP SIGNED MESSAGE-----
 > Hash: SHA1
 > 
 > Hi,
 > 
 > the bashdb installation is not working properly on my osx/darwin 7.8.0 
 > and linux: a 'make install' results in an error, because the bashdb 
 > scripts were not installed into /usr/local/lib/bashdb. In fact they are 
 > in /usr/local/share/bashdb. An excerpt from Makefile:
 > 
 > install-data-hook:
 > 	if test -e /usr/local/lib/bashdb/bashdb-main.inc ; then $(RM) 
 > /usr/local/lib/bashdb/bashdb-main.inc ; fi
 > 	$(LN_S) $(PKGDATADIR)/dbg-main.inc 
 > /usr/local/lib/bashdb/bashdb-main.inc
 > 
 > Running bash --debugger doesn't work because of the same problem. If I 
 > create a symlink from /usr/local/lib/bashdb to /usr/local/share/bashdb 
 > (and if I create the symlink bashdb-main.inc manually), everything 
 > work's fine.
 > 
 > The configure script of bash-3.0 sets
 > 
 > DEBUGGER_START_FILE=${ac_default_prefix}/lib/bashdb/bashdb-main.inc
 > 
 > But the bashdb uses PREFIX/share/bashdb. I am confused, what's the 
 > right path?
 > 
 > I am using bashdb-3.00-0.01 and bash-3.0.
 > 
 > Thanks,
 > Alexander
 > - -----
 > My GPG public key:
 > http://www.weihenstephan.org/~mayerale/pgp/AlexanderMayer.gpg.asc
 > -----BEGIN PGP SIGNATURE-----
 > Version: GnuPG v1.2.4 (Darwin)
 > 
 > iD8DBQFCJeVZBF+abY4YMw8RAn9rAJ9wSIHwt9z1aLWQtohQ2o0Bvv0YTQCdE6tO
 > DEt4nXjaUGbAP7Jqxbj0OnY=
 > =RRH2
 > -----END PGP SIGNATURE-----

[Bashdb-devel] bashd debugger for bash 3.0

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

I now have made the changes in CVS so that the debugger works for bash
3.0. 

There is one patch I had to make to get BASH_COMMAND - the last
command before the statement would work and this patch is needed to correct that.

I also made changes to the regression test correct output. For reasons
I don't understand, the command parameters don't appear to be saved on
the call stack as they did before. The arguments do get saved when
invoking "bash --debugger" though. If someone can figure out why the
difference and fix, I'd appreciate it. Otherwise I guess we live with
the slight backslide. (In my opinion, programming and debugging in
POSIX shell and bash in particular is a bit of a backslide anyway.)

After waiting for a reasonable amount of time, unless folks find
problems, I'll release this.

A candidate tarball can be obtained at
http://bashdb.sourceforge.net/bashdb-3.00-0.01cvs.tar.gz

Re: [Bashdb-devel] bashdb release for bash 3.0 ?

[Chet R. <ch...@ca...>]

> I guess you are referring to this from 
> http://sourceforge.net/mailarchive/forum.php?thread_id=3855720&forum_id=12061 :
> 
>    So of course, I rely on the regression tests, and although most of
>    these work in bash 3.0 not all do, notably those which fail show
>    what the upcoming command to be executed is which is used when there
>    are multiple statements on a line.  (I wrote Chet Ramey on this but
>    haven"t received any comment.)

I'll have to look back; I can't recall this immediately.

>   [with respect to shipping the debugger with bash]
>   > Eventually, yes, though independent development will continue.
> 
> Okay, if that's what Chet writes, I guess that's what will happen. ;-)

I envision the two of us getting together and putting together a bashdb
release to be included each time I make a bash release, but the two projects
proceeding at their own rates.

>   > As far as I know.  Rocky is on the bash-testers list, 
> 
> Funny, I haven't been getting any bash-testers mail.

I'll make sure you're on it.  Now that 3.0 is out, I'm interested in your
comments.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet )
						Live...Laugh...Love
Chet Ramey, ITS, CWRU    ch...@po...    http://tiswww.tis.cwru.edu/~chet/

Re: [Bashdb-devel] bashdb release for bash 3.0 ?

[Nicholas B. <nic...@ci...>]

Exellcent. I'm prepared to help were possible (testing etc).
I look forward to a bash 3.01 release with bashdb included. ;-)

Thanks guys for working to provide bash with script debugging support.
Cheers,
Nick

On Tuesday 17 Aug 2004 13:38, Chet Ramey wrote:
> > I guess you are referring to this from
> > http://sourceforge.net/mailarchive/forum.php?thread_id=3855720&forum_id=1
> >2061 :
> >
> >    So of course, I rely on the regression tests, and although most of
> >    these work in bash 3.0 not all do, notably those which fail show
> >    what the upcoming command to be executed is which is used when there
> >    are multiple statements on a line.  (I wrote Chet Ramey on this but
> >    haven"t received any comment.)
>
> I'll have to look back; I can't recall this immediately.
>
> >   [with respect to shipping the debugger with bash]
> >
> >   > Eventually, yes, though independent development will continue.
> >
> > Okay, if that's what Chet writes, I guess that's what will happen. ;-)
>
> I envision the two of us getting together and putting together a bashdb
> release to be included each time I make a bash release, but the two
> projects proceeding at their own rates.
>
> >   > As far as I know.  Rocky is on the bash-testers list,
> >
> > Funny, I haven't been getting any bash-testers mail.
>
> I'll make sure you're on it.  Now that 3.0 is out, I'm interested in your
> comments.
>
> Chet

[Bashdb-devel] Any comments on where to put the bash 3.0 debugger CVS?

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

The options I see are to branch under the debugger directory. And then
the choice is whether to make 3.0 HEAD (default that folks get) or
leave 2.05b the HEAD. Another possibility is to start something new up a level. 

Thoughts? comments? Indifference? 

[Bashdb-devel] bashdb release for bash 3.0 ?

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

Nicholas Brown writes:
 > Does bashdb support bash 3.0?

I have some changes on my local disk. I'm not sure how to handle in
bashdb CVS. Depending on the consensus of other bashdb developers, it
will go there one way or another.

 > If so, will a standalone release of it for bash 3.0 be made?

Sure. I don't when though. Probably the first thing to do is get it in
public CVS. If someone else wants to lead the development for a
release, I wouldn't mind. Right now I've been working heavily on other
projects like libcdio (http://www.gnu.org/software/libcdio/ and a
debugger for GNU make http://freshmeat.net/projects/remake/)

 > Though reading the post to bashdb-devel on 2003-10-23 suggests things don't 
 > quite work. 

I guess you are referring to this from 
http://sourceforge.net/mailarchive/forum.php?thread_id=3855720&forum_id=12061 :

   So of course, I rely on the regression tests, and although most of
   these work in bash 3.0 not all do, notably those which fail show
   what the upcoming command to be executed is which is used when there
   are multiple statements on a line.  (I wrote Chet Ramey on this but
   haven"t received any comment.)

 > Have these issues been resolved?

No. But showing the last command to disambiguate where you are in a
multi-statement line is a nicety not a necessity. Alas, it's something
though that can't be fixed in the bash debugger code but has to be
done in bash 3.0.

Chet Ramey writes:

  [with respect to shipping the debugger with bash]
  > Eventually, yes, though independent development will continue.

Okay, if that's what Chet writes, I guess that's what will happen. ;-)

  > As far as I know.  Rocky is on the bash-testers list, 

Funny, I haven't been getting any bash-testers mail. Perhaps the
bash-testers list owner can check on on whether there's someone by the
name rocky subscribed. I don't recall getting any bash-testers
e-mail. The alpha announcement was forwarded to me. 

  > and I didn't hear anything back from him regarding any of the alpha or beta releases.

There is a communication problem somewhere. I thought communicated the
problem I encountered in alpha described above. I thought it weird but
not uncommon for bash not to get word back on it. Also, I don't recall
receiving a beta release announcement or a bash 3.0 announcement.

Is there a public bash-testers mailing list archive somewhere?

[Bashdb-devel] bashdb release for bash 3.0 ?

[Nicholas B. <nic...@ci...>]

The new released bash 3.0 lists support for the bash debugger in its change 
log, but does not ship with a copy. (even though it seems to look 
for /usr/local/lib/bashdb/bashdb-main.inc when called with --debugger) Though 
it does ship with the older example/bashdb.

Does bashdb support bash 3.0?
If so, will a standalone release of it for bash 3.0 be made?
(I can only find it in rebash2.05b)
And/Or are there plans to ship it with bash?

Though reading the post to bashdb-devel on 2003-10-23 suggests things don't 
quite work. Have these issues been resolved?

Cheers,
Nick

Re: [Bashdb-devel] make debugger thoughts

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

> Given this split in goals, I think it best to maintain this initially
> as a seperate track. Although this track is alpha, I think it has some
> important and useful changes and needs early exposure to best grow
> this the right way. I don't think it should be tied down to the GNU
> make 3.81 release schedule and similarly I don't think the 3.81
> release schedule should be tied down to having this be flawless.
> 
> Two possibilities I see for this then are in GNU make's CVS as a
> separate branch, or completely outside such as for example bashdb's
> CVS (in sourceforge.net). The latter is the most convenient for me
> since that's an area I already have write access to and can easily
> make releases from. I've used that in the past for example to extend
> ddd to support the new bash debugging I wrote. 

I think you should talk to GNU Make developers.
Development style of GNU Make seems that more open than Bash.
So it is worth to contact them.
(http://savannah.gnu.org/mail/?group=make)

As a user, I'm happy if your code are merged to GNU Make official
tar.gz. If merging is the goal, general it is better to work near to 
official source tree:) Of course, in some case diplomacy is needed.

> As Masatake YAMATO has pointed out, down the line I'll need to set up
> GNU arch (http://www.gnuarch.org/) or something like that in order to
> track changes across the two branches.

I feel gnuarch is too strong weapon. It gives you real freedom about
development. You can reflect the GNU Make's CVS repository to your
gnuarch's archive by
cscvs(http://wiki.gnuarch.org/moin.cgi/Additional_20Tools).  My idea
is use gnuarch as your ace if the diplomacy is failed.

Masatake

[Bashdb-devel] make debugger thoughts

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

With steady progress, my debugger for make has gotten good enough to
be called "alpha" and good enough to make available in public under
version control.  (See below for thoughts on the public version
control).

Although there are a number of gaps listed in TODO, (like the ability
to keep global state global across subshell returns), the debugger is
very usable -- at least for me. It passes all the regression tests
with the exception of one where some commands are getting echoed that
shouldn't; right now I don't know why that's so.

Using the debugger I've learned something about Makefiles, those
produced by automake, and have been able to pinpoint some problems --
even if in some cases I'm still clueless as to how to get "make" or
"automake" fix them.

For example, one thing I learned is that in automake-produced
Makefiles, even though "all" is listed as the first target, it often
isn't the first target to trigger! It appears that
$(srcdir)/Makefile.in is -- and I don't ask me why. I imagine that as
folks start using this, the may be able to *understand* "make" better
and perhaps even write better or more efficient Makefiles.

In the process of the small changes to add better support for error
reporting and debugging, I've been also making changes to the code to
make more modern conventions. For example:

 - the source code now lives in a src directory,
 - configure.ac rather than configure.in is used, 
 - the prototypes for xxx.c are in xxx.h 
 - documentary comments at are found beginning of a function 
   are in the headers in doxygen format.
 - headers can be included in any order since they include what they need
 - headers have tests to make sure they are included only once. 
 - gcc -Wall warnings have been removed

Although none of this is strictly needed for better error reporting
and debugging, any code I may have to deal with, I may as well make as
palatable as possible. 

On the other hand, what has *not* been all that important to me has
been ensuring this builds and runs on a C compiler that isn't
C99-compliant.  Also right now I may have broken the ability to run on
OS's where there was a bit of specialized conditional compilation
(e.g. AMIGA or VMS), custom Makefiles, or build systems and OS's that
don't support automake and autoconf.  For that, there's always good
old GNU make version 3.80.

Given this split in goals, I think it best to maintain this initially
as a seperate track. Although this track is alpha, I think it has some
important and useful changes and needs early exposure to best grow
this the right way. I don't think it should be tied down to the GNU
make 3.81 release schedule and similarly I don't think the 3.81
release schedule should be tied down to having this be flawless.

Two possibilities I see for this then are in GNU make's CVS as a
separate branch, or completely outside such as for example bashdb's
CVS (in sourceforge.net). The latter is the most convenient for me
since that's an area I already have write access to and can easily
make releases from. I've used that in the past for example to extend
ddd to support the new bash debugging I wrote. 

As Masatake YAMATO has pointed out, down the line I'll need to set up
GNU arch (http://www.gnuarch.org/) or something like that in order to
track changes across the two branches.

Thoughts, comments? 

Oh yeah, a tarball snapshot of the latest version of the debuggers is 
http://bashdb.sourceforge.net/libcdio-0.69cvs.tar.gz

Re: [Bashdb-devel] first GNU make with a debugger

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

Thanks for the information and link. How the "make + debugger" project
is going to be managed is open for discussion and is very much up in
the air.

Up to now I've been focused on feasibility of developing such a tool,
getting a small but useful prototype working, and gauging the overall
difficulty. Although, I haven't had any feedback from others on what
is now there, based on my own experience I think this project is a
keeper. I've certainly learned more about the complex Makefiles
produced by automake and it has been able to help me understand what's
going on.

Also Interesting, this project meshes well with the bash
debugger. Makefiles often contain fragments of scripts. With the
"remake" debugger, you can stop at a point where you are about to run
a script fragment, extract the script fragment easily with the
Makefile variables expanded courtesy of remake and then use the bash
debugger to debug that! Cool if I say so myself (and I think I have
to since bulk of bashdb-devel often very silent ;-).


Masatake YAMATO writes:
 > Different from bash, the source code of GNU make is managed by cvs(
 > http://savannah.gnu.org/cgi-bin/viewcvs/make/make/).  So I higly
 > recommend you to try arch to manage your remake source code. 
 > 
 > http://www.dwheeler.com/essays/scm.html
 > 
 > You can do (1) make synchronize your remake source code and the
 > original GNU make source in CVS repository; and (2) you can manage
 > your remake source code under version control system.
 > 

Re: [Bashdb-devel] first GNU make with a debugger

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

Different from bash, the source code of GNU make is managed by cvs(
http://savannah.gnu.org/cgi-bin/viewcvs/make/make/).  So I higly
recommend you to try arch to manage your remake source code. 

http://www.dwheeler.com/essays/scm.html

You can do (1) make synchronize your remake source code and the
original GNU make source in CVS repository; and (2) you can manage
your remake source code under version control system.

[Bashdb-devel] first GNU make with a debugger

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

I've patched GNU make 3.80 to add better tracing, error reporting and
I have added a debugger. It is in
http://bashdb.sourceforge.net/remake-3.80+dbg.tar.gz

What I have here is very very preliminary; it there so one can get a
feel for what a debugger for GNU Make might look like. I've only been
able to compile this on GNU/Linux with RedHat 9.0 or
Debian. Compilations on other OS's seem to give problems in places
that as far as I can tell are not related to any of the changes I've
made. For the debugger, you should have GNU readline installed.

Okay, now some sample output. Here's a small test Makefile: 

1: FOO=bar
2: all: foo
3: foo:
4: 	@echo hi > /dev/null
5: 	@fdafds

To get trace output, I've added the -x (or --trace) option. So:

  ./make -x -f bug2
produces: 

bug2:2 all
bug2:3 foo
bug2:4 foo
       echo hi > /dev/null
bug2:5 foo
       fdafds
make: fdafds: Command not found
bug2:3: *** [foo] Error 127

One small thing to note above is that when -x is in effect the @'s to
turn off echoing are disregarded. So you see the "echo hi" and "fdafds"
in the output.

If you want a target backtrace on errors, add -E. For the above, this
adds to the end:

#0  foo at bug2:3
#1  all at bug2:2

I've also tried this the actual Makefile to the modified make. At
present it still gives too much output, but boy is it much more
comprehensible compared to what you get with "make -d"

Okay, now on to the debugger! Just add -X (or --debugger) and you are
put into the debugger. Although I have a small command set right now
with few command formats or opitons, many of the most useful debugging
commands are there. You can set/delete breakpoints at a target, step
execution, restart or quit execution, turn on/off/toggle tracing, go
up or down the target backtrack stack and look at variables, Actually,
there are two kinds of print commands: "print" give a variable
source/file location and the value in symbolic terms.

For example when I run "p MAKE" inside the debugger (remake), I get: 

  (remake) p MAKE
  (null):0 MAKE = $(MAKE_COMMAND)

The (null):0 means this is a builtin definition. However there is
another print which does full expansion of the variables. So if I run
x (examine) instead I get: 

  (null):0 MAKE = /src/local-cvs/remake/src/./make

In fact, "examine" doesn't need a variable name, it will work with a
string. So I could type "x This is $(MAKE)" or 
"x $(bin_PROGRAMS) $(noinst_PROGRAMS)". For the latter, I get

make loadavg

Note, no location identification is given here (since what I put in
isn't a variable).

For those of you like myself who live inside of GNU Emacs, included in
the tarball is remake.el which uses on gud.el to provide running the
debugger inside GNU Emacs just as the way you'd do with perl, gdb, my
bash debugger. I also have a patched gud.el which contains the remake
debugger support. For front-end support such as this, I added "up" and
"down" debugger commands to postion you up or down in the Makefile
source.

Okay that's about it for now. I thought it would take a year or so to
get something I'm happy with. I'm a little ahead of schedule (but not
by much). I've been very pleased and surprised at how little work it
took for the gains I've gotten so far. It's a real pity no one has
undertaken this before, it hasn't been that hard.

Some interesting issues down the line will be in adding a command to
show dependency results or figuring out the right level of display on
a trace. Maybe there would be several levels: one doesn't want to step
through every file dependency of which most of them are
satisfied. Right now I use the hueristic unless a breakpoint is set I
stop at targets that are explicitly mentioned on the left-hand
side. This is probably still too much. "phony targets" and targets
with commands may be too little.

[Bashdb-devel] make debugger

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

> I know it might not seem so, but part of the purpose of this project
> was to open bash development up more and encourage more people to be
> more involved to do whatever things that may be of interest.  (My
> desires were to have a debugger and a time-stamped history; the latter
> is completly done and the former is functional even though it could
> use a lot of improvement. My next big thing will probably be a
> debugger for GNU make even if it is as flaky as this debugger
> initially was.)

You may use perl well. Look into makepp(http://makepp.sourceforge.net/).
It is make written in perl. I wrote a sample debugger code for makepp and
sent to makepp maintainer. I got positive reply from the maintainer.
It is worth to hack makepp because makepp is actively maintained. 

Masatake YAMATO

Re: [Bashdb-devel] reading progress...

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

I've installed my progress bar patch to the repository.
Please try and fix it if something is wrong.

I wrote about my change to NEWS file.
Masatake YAMATO

[Bashdb-devel] ChangeLog

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

bashdb/ChangeLog:
    ##
    ## autogenerated ChangeLog -- don't edit
    ##

Where should I write my change? 
cvs's log?