bashdb-devel — Developer's discussion mailing list

Re: [Bashdb-devel] bashdb.el

[Rocky B. <roc...@gm...>]

Advantages of not being part of GNU Emacs

   - easier to affect a change (at least for me)
   -  more frequent releases for users
   - shorter turn-around time when a problem is found or an
   improvement/patch offered

Some of the advantages may vary over time. In particular, bashdb releases
are currently much more frequent that GNU Emacs releases. Will that always
be the case? I don't know. However since bashdb is much much smaller than
GNU Emacs, it stands a good chance of being true.

The  turn-around time to address/fix a problem is also a dynamically
changeable thing. Above I'm just observing that this is what the
currentsituation seems to be.

Disadvantages of not being part of GNU Emacs

   -  People are more knowledgeable about the workings of GNU Emacs ,
   GUD, and Emacs Lisp than most bashdb  folks are
   -  When GUD and GNU Emacs change, this code will get updated in
   conjunction with that (we hope) so...
   - Easier to keep code consistent with the currently installed GNU
   Emacs. In bashdb I guess some compatibility needs to happen across
   many  GNU Emacses

Given the above advantages and disadvantages, I think the advantages of not
being part of GNU Emacs outweigh the disadvantages. But I'd like to hear the
comments of others. Should this be cross-posted to the emacs newsgroups  and
emacs developers groups?

And by they way, isn't there also a bashdb.el that gets distributed with
BASH?

Let me close, by relating something that caused me to change bashdb.el. In a
way it fleshes out in detail some of the points above.

Recently someone reported a regexp problem in the pydb -equivalent Emacs
program. As part of fixing that, I decided we really should start adding a
regression test for this. As best as I can tell there are no unit tests for
GNU Emacs, and in fact I think one of Richard Stallman's complaints is that
folks aren't testing things in GNU Emacs. So I went over the regular
expression pattern in bashdb.el and added a unit test, at least for the part
that had been a bug.

I suppose I should have sent another patch for GNU Emacs, but the last time
I put in a patch it wasn't all that satisfying or quick. I had to send some
copyright release thing (having done so several times in the past), and I
got a complaint from RMS about how the ChangeLog entry was written,
something about listing function names in a file or something. All of this
spanned about a month.

And after all of that work, none of that code has seen light of day in terms
of a general release. So the thing I care about most really hasn't happened
(yet). And as we see, when it happens it will likely be obsolete code
because of the hassle (at least for me) of keeping this code up to date.

On 1/21/07, Masatake YAMATO <je...@gy...> wrote:
>
> There are two M-x bashdb; one is distributed as part of bashdb, and
> another will be distributed as part of the next version of GNU emacs.
> I guess the users may be confused.
>
> What is the best way to deal this situation?
> My opinion is that it is better to remove M-x bashdb code from GNU emacs.
> In stead I will add some code to the bashdb.el distributed as part of
> bashdb to make it work well with the CVS version of GNU Emacs.
>
> Rocky, how do you think?
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Bashdb-devel mailing list
> Bas...@li...
> https://lists.sourceforge.net/lists/listinfo/bashdb-devel
>

[Bashdb-devel] bashdb.el

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

There are two M-x bashdb; one is distributed as part of bashdb, and
another will be distributed as part of the next version of GNU emacs.
I guess the users may be confused.

What is the best way to deal this situation?
My opinion is that it is better to remove M-x bashdb code from GNU emacs.
In stead I will add some code to the bashdb.el distributed as part of 
bashdb to make it work well with the CVS version of GNU Emacs.

Rocky, how do you think?

Re: [Bashdb-devel] debugger for zsh

[Rocky B. <roc...@gm...>]

On 12/27/06, nws...@al... <
nws...@al...> wrote:
>
> Rocky,
>
> I took a quick look at the bashdb web site. Great work!


Again, thanks.

I hope that someone will be willing to port it to zsh.


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.

A little fable:
When I first learned about Perl4 I thought, gee, this is great -- it has
hash tables, access to C library routines and a debugger. I'll just wait for
POSIX shells to disappear. Ten years later, I'm still plagued with init
scipts and configure scripts that are written using POSIX shells. So I
embarked on that debugger.

When that debugger became good enough to debug configure scripts, I thought
all my autotools  problems were solved! Well, no there still was GNU Make. I
read this article about autoconf http://freshmeat.net/articles/view/889/ and
suggested someone write a debugger for GNU Make. A year later, I started
writing one myself.

Sometimes people tell me: I don't really have the skills to undertake such a
task. Maybe. But I'm not sure I had the skills to do many of the projects
I've undertook beforehand either.

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 have
> invested too much in zsh to give it up for bash now. Besides, zsh
> does have many good features that I like.
>
> Keep up the excellent work.
>
> mk
>
> ********************************************************************
>
> > From roc...@gm... Wed Dec 27 08:53:59 2006
> > To: "Masatake YAMATO" <je...@gy...>
> > Subject: Re: [Bashdb-devel] debugger for zsh
> > Cc: mkk...@al..., bas...@li...
> >
> > 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.
> >
> > For example in the bash debugger we wrote our own routine to read a
> > file into an array quickly. I see in zsh this is called "mapfile".
> > (Masatake: That's the name you decided on in revising readarray.c,
> > right? - zsh I now see that got there first with this routine, so we
> > should make it easy on those folks who use both.)
> >
> > 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.
> >
> > On 12/27/06, Masatake YAMATO <je...@gy...> wrote:
> > > Hi,
> > >
> > > I read your article
> > >
> > >   http://article.gmane.org/gmane.comp.shells.zsh.devel/11563
> > >
> > >
> > > F.Y.I bash has 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.
> > >
> > > Masatake YAMATO
> > >
> > >
> -------------------------------------------------------------------------
> > > Take Surveys. Earn Cash. Influence the Future of IT
> > > Join SourceForge.net's Techsay panel and you'll get the chance to
> share your
> > > opinions on IT & business topics through brief surveys - and earn cash
> > >
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > > _______________________________________________
> > > Bashdb-devel mailing list
> > > Bas...@li...
> > > https://lists.sourceforge.net/lists/listinfo/bashdb-devel
> > >
> >
>
>

Re: [Bashdb-devel] debugger for zsh

[<nws...@al...>]

Rocky,

I took a quick look at the bashdb web site. Great work!

I hope that someone will be willing to port it to zsh. I have
invested too much in zsh to give it up for bash now. Besides, zsh
does have many good features that I like.

Keep up the excellent work.

mk

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

> From roc...@gm... Wed Dec 27 08:53:59 2006
> To: "Masatake YAMATO" <je...@gy...>
> Subject: Re: [Bashdb-devel] debugger for zsh
> Cc: mkk...@al..., bas...@li...
> 
> 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.
> 
> For example in the bash debugger we wrote our own routine to read a
> file into an array quickly. I see in zsh this is called "mapfile".
> (Masatake: That's the name you decided on in revising readarray.c,
> right? - zsh I now see that got there first with this routine, so we
> should make it easy on those folks who use both.)
> 
> 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.
> 
> On 12/27/06, Masatake YAMATO <je...@gy...> wrote:
> > Hi,
> >
> > I read your article
> >
> >   http://article.gmane.org/gmane.comp.shells.zsh.devel/11563
> >
> >
> > F.Y.I bash has 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.
> >
> > Masatake YAMATO
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share your
> > opinions on IT & business topics through brief surveys - and earn cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Bashdb-devel mailing list
> > Bas...@li...
> > https://lists.sourceforge.net/lists/listinfo/bashdb-devel
> >
> 

Re: [Bashdb-devel] debugger for zsh

[Rocky B. <roc...@gm...>]

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.

For example in the bash debugger we wrote our own routine to read a
file into an array quickly. I see in zsh this is called "mapfile".
(Masatake: That's the name you decided on in revising readarray.c,
right? - zsh I now see that got there first with this routine, so we
should make it easy on those folks who use both.)

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.

On 12/27/06, Masatake YAMATO <je...@gy...> wrote:
> Hi,
>
> I read your article
>
>   http://article.gmane.org/gmane.comp.shells.zsh.devel/11563
>
>
> F.Y.I bash has 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.
>
> Masatake YAMATO
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Bashdb-devel mailing list
> Bas...@li...
> https://lists.sourceforge.net/lists/listinfo/bashdb-devel
>

[Bashdb-devel] debugger for zsh

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

Hi,

I read your article

  http://article.gmane.org/gmane.comp.shells.zsh.devel/11563


F.Y.I bash has 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.

Masatake YAMATO

[Bashdb-devel] line tracing with variable substitution

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

Since bashdb-3.1-0.06 the bash debugger has had the ability to do line
tracing sort of like set -x, but adding a little more information,
namely position information and BASH_LEVEL information. 

Recently I added string expansion of before printing lines.  This is
controlled by the debugger command "set linetrace expand", and from
the bashdb script using option -Y (or long-option --vtrace if you have
a working getopt).

Here's a small example using a recursive factorial program. (Sure
there's a simpler, non-recursive way to write this - I just wanted a
small example.)

Here's the program

  #!/bin/bash

  fact() {
   local -i n=$1
   ((n==0)) && echo 1 && return
   ((nm1=n-1))
   ((result=n*`fact $nm1`))
   echo $result
  }

  typeset -i n=${1:-4}
  echo fact $n is: `fact $n`

Running with line tracing and variable substitution, you get:


bashdb -B -Y fact.sh 2
Bourne-Again Shell Debugger, release bash-3.1-0.08cvs
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.

  (bashdb:277):
  level 1, subshell 0, depth -1:	  . $_source_file
          . fact.sh
  (fact.sh:11):
  level 1, subshell 0, depth 0:	typeset -i n=${1:-4}
        typeset -i n=2
  (fact.sh:12):
  level 1, subshell 0, depth 0:	echo fact $n is: `fact $n`
        echo fact 2 is: 2
  (fact.sh:12):
  level 1, subshell 1, depth 0:	echo fact $n is: `fact $n`
        echo fact 2 is: 2
  fact $n
  (fact.sh:3):
  level 1, subshell 1, depth 1:	fact() {
        fact() {
  (fact.sh:4):
  level 1, subshell 1, depth 1:	 local -i n=$1
         local -i n=2
  (fact.sh:5):
  level 1, subshell 1, depth 1:	 ((n==0)) && echo 1 && return
         ((n==0)) && echo 1 && return
  (fact.sh:6):
  level 1, subshell 1, depth 1:	 ((nm1=n-1))
         ((nm1=n-1))
  (fact.sh:7):
  level 1, subshell 1, depth 1:	 ((result=n*`fact $nm1`))
         ((result=n*1))
  (fact.sh:7):
  level 1, subshell 2, depth 1:	 ((result=n*`fact $nm1`))
         ((result=n*1))
  fact $nm1
  (fact.sh:3):
  level 1, subshell 2, depth 2:	fact() {
        fact() {
  (fact.sh:4):
  level 1, subshell 2, depth 2:	 local -i n=$1
         local -i n=1
  (fact.sh:5):
  level 1, subshell 2, depth 2:	 ((n==0)) && echo 1 && return
         ((n==0)) && echo 1 && return
  (fact.sh:6):
  level 1, subshell 2, depth 2:	 ((nm1=n-1))
         ((nm1=n-1))
  (fact.sh:7):
  level 1, subshell 2, depth 2:	 ((result=n*`fact $nm1`))
         ((result=n*1))
  (fact.sh:7):
  level 1, subshell 3, depth 2:	 ((result=n*`fact $nm1`))
         ((result=n*1))
  fact $nm1
  (fact.sh:3):
  level 1, subshell 3, depth 3:	fact() {
        fact() {
  (fact.sh:4):
  level 1, subshell 3, depth 3:	 local -i n=$1
         local -i n=0
  (fact.sh:5):
  level 1, subshell 3, depth 3:	 ((n==0)) && echo 1 && return
         ((n==0)) && echo 1 && return
  (fact.sh:5):
  level 1, subshell 3, depth 3:	 ((n==0)) && echo 1 && return
         ((n==0)) && echo 1 && return
  echo 1
  (fact.sh:5):
  level 1, subshell 3, depth 3:	 ((n==0)) && echo 1 && return
         ((n==0)) && echo 1 && return
  return
  (fact.sh:8):
  level 1, subshell 2, depth 2:	 echo $result
         echo 1
  (fact.sh:8):
  level 1, subshell 1, depth 1:	 echo $result
         echo 2
  fact 2 is: 2
  (bashdb:290):
  level 1, subshell 0, depth -1:	
  
  
Using -V (long option --trace), omits the substitution line getting
printed out. That is this would start out instead:

  (bashdb:277):
  level 1, subshell 0, depth -1:	  . $_source_file
  (fact.sh:11):
  level 1, subshell 0, depth 0:	typeset -i n=${1:-4}
  (fact.sh:12):
  level 1, subshell 0, depth 0:	echo fact $n is: `fact $n`

That very first line (bashdb:277) I'm not happy about but I don't know
how to remove it for now - and it *does* reflect what's really going
on.

Another thing to note is that the program really doesn't have deep
knowledge about what is a variable and what isn't. It is just asks
bash to expanding the source line as a string and prints the result

So in a statement like
   ((nm1-n-1)) 

nothing gets substituted. 

Similarly it's possible to have a source line like

echo "Now is \
the time"

And what will happen here is invariable the debugger will see an
open/close quote (or a back tick) without the matching one. What
happens here is that the string substitute fails and nothing gets
printed.

Still, even with these caveats, I've found this addition useful.

Things are not cast in concrete right now, so if folks want to try it
out and give feedback, now would be a good time. 

Thanks.

Re: [Bashdb-devel] Releases to bash 3.1 and 3.0 debuggers around Dec 10, 2006

[Rocky B. <roc...@gm...>]

One important thing I forgot to mention. There is a configure test for GNU
getopt that was failing on a  NetBSD box I tried. I guess it has a getopt
but it's different from from the GNU version. So I added option
--enable-getopt and the more relevant: twin --disable-getopt.

On cygwin I dont see GNU getopt installed at all and yet again the test was
failing. So one needs to manually add --disable-getopt on configure on
cygwin, assuming you don't have getopt (1) as well.

On 12/3/06, R. Bernstein <ro...@pa...> wrote:
>
> Eric Blake writes:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > According to R. Bernstein on 12/3/2006 9:51 AM:
> > > Recently I've needed to use the debugger on a computer that was
> > > running bash 3.0 and ran into a bug in the debugger. It is also
> > > present in the 3.1 debugger as well.
> >
> > Is the 3.1 release usable on bash 3.2, or do we need a 3.2 debugger
> > release as well?
>
> Hard as it is to believe, the bash API is upward compatible between
> versions 3.1 and 3.2 (I think this is the first time that's been the
> case in about 7 years.) So yes, this release will work on both.
>
> That said, it didn't necessarily mean it on either version of bash for
> *cygwin*. :-)
>
> I've just committed some changes to correct that.
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Bashdb-devel mailing list
> Bas...@li...
> https://lists.sourceforge.net/lists/listinfo/bashdb-devel
>

Re: [Bashdb-devel] Releases to bash 3.1 and 3.0 debuggers around Dec 10, 2006

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

Eric Blake writes:
 > -----BEGIN PGP SIGNED MESSAGE-----
 > Hash: SHA1
 > 
 > According to R. Bernstein on 12/3/2006 9:51 AM:
 > > Recently I've needed to use the debugger on a computer that was
 > > running bash 3.0 and ran into a bug in the debugger. It is also
 > > present in the 3.1 debugger as well.
 > 
 > Is the 3.1 release usable on bash 3.2, or do we need a 3.2 debugger
 > release as well?

Hard as it is to believe, the bash API is upward compatible between
versions 3.1 and 3.2 (I think this is the first time that's been the
case in about 7 years.) So yes, this release will work on both.

That said, it didn't necessarily mean it on either version of bash for
*cygwin*. :-)

I've just committed some changes to correct that.

Re: [Bashdb-devel] Releases to bash 3.1 and 3.0 debuggers around Dec 10, 2006

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

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

According to R. Bernstein on 12/3/2006 9:51 AM:
> Recently I've needed to use the debugger on a computer that was
> running bash 3.0 and ran into a bug in the debugger. It is also
> present in the 3.1 debugger as well.

Is the 3.1 release usable on bash 3.2, or do we need a 3.2 debugger
release as well?

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

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

iD8DBQFFcymt84KuGfSFAYARAmWlAJ9bSqvfH7glZuJ9Rh1wUBF1q2UoJQCfcTxL
BvfbwHd0N55782Ijl8u/+3Y=
=JZcO
-----END PGP SIGNATURE-----

[Bashdb-devel] Releases to bash 3.1 and 3.0 debuggers around Dec 10, 2006

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

Recently I've needed to use the debugger on a computer that was
running bash 3.0 and ran into a bug in the debugger. It is also
present in the 3.1 debugger as well.

It's been a while since I had a computer running bash 3.0 so it should
be no surprise that the version of the debugger is a little bit behind
the debugger for 3.1 in terms of features. So I've spent a little time
getting that more closely synchronized to the 3.0 and 3.1 debuggers to
a little to the benefit of both.

Of late, I've been making releases on a friend's birthday and the next
one coming up is December 10th. If you have a chance to try the
tarballs that is helpful. The candidate tarballs are in
  http://bashdb.sf.net/bashdb-3.1-0.07cvs.tar.gz and
  http://bashdb.sf.net/bashdb-3.00-0.05cvs.tar.gz

Here are the relevent portions of NEWS for each: 

Version 3.00 0.05
12-10-06

- Add "signal" and "complete" debugger commands

- Fix bug in tracking parameters $1, $2, etc

- Add --enable-getopt option to disable GNU getopt for systems that have 
  non-GNU getopt like NetBSD

- Add cd and pwd

- Allow an optional line-spec on "continue" debugger command.

- Fix bug in displaying watch when variable doesn't exist

- Add Emacs bashdbtrack to track debugging in an Emacs comint shell


Version 3.1 0.07cvs
2006-12-10

- Add gdb-like "signal" command

- Add "kill" command for those cases where "quit" doesn't work.

- Add mechanism to set up signal handlers so debugger is entered,
  or we just print the signal. 

- document how to do call line tracing from within a program, i.e.
  like the above signal handling setup, the debugger is not entered
  first.

- Allow an optional line-spec on "continue" debugger command.

- Add --enable-getopt option to disable GNU getopt for systems that have 
  non-GNU getopt like NetBSD

- Fix bug in tracking parameters $1, $2, etc

- Emacs interface bug fixes

- readarray builtin internal changes

- Document updates

[Bashdb-devel] Fwd: Re: hardwired DEBUGGER_START_FILE points to wrong location

[Nick B. <nic...@bl...>]

----------  Forwarded Message  ----------

Subject: Re: hardwired DEBUGGER_START_FILE points to wrong location
Date: Thursday 07 September 2006 18:19
From: Nick Brown <nic...@bl...>
To: bug...@gn...

Nick Brown wrote:
> Currently if the environmental variable is not set then
> DEBUGGER_START_FILE defaults to this;
>
> configure.in:  DEBUGGER_START_FILE=
> ${ac_default_prefix}/lib/bashdb/bashdb-main.inc
>
> However looking at the bashdb package Makefiles I note that
> bashdb-main.inc will be found in $(datadir)/bashdb/, thus I think
> DEBUGGER_START_FILE should default to that instead of
> ${ac_default_prefix}/lib/
>
> Simply changing this to;
>
> configure.in:  DEBUGGER_START_FILE=${datadir}/bashdb/bashdb-main.inc
>
> does not quite work as pathname.h ends up looking like this;
>
> #define DEBUGGER_START_FILE     "${prefix}/share/bashdb/bashdb-main.inc"
>
> but I'm sure someone that understands autoconf/automake better can
> correct this.

After reading section 4.7.2 "Installation Directory Variables" of the
 autoconf manual (see below), realise this is because pathnames.h is
 generated at configure time, but sould be generated at make time, by a
 makefile snippet. Does anyone know how to do this for? (or I'm going to need
 to learn autotools a lot more)

Cheers,
Nick

<--snip-->

Most of these variables have values that rely on prefix or exec_prefix. It is
deliberate that the directory output variables keep them unexpanded:
typically `@datadir@' will be replaced by `${prefix}/share', not
`/usr/local/share'.

This behavior is mandated by the GNU coding standards, so that when the user
runs:

`make'
    she can still specify a different prefix from the one specified to
configure, in which case, if needed, the package shall hard code dependencies
corresponding to the make-specified prefix.

`make install'
    she can specify a different installation location, in which case the
package must still depend on the location which was compiled in (i.e., never
recompile when `make install' is run). This is an extremely important
feature, as many people may decide to install all the files of a package
grouped together, and then install links from the final locations to there.

In order to support these features, it is essential that datadir remains
 being defined as `${prefix}/share' to depend upon the current value of
 prefix.

A corollary is that you should not use these variables except in Makefiles.
For instance, instead of trying to evaluate datadir in `configure' and
hard-coding it in Makefiles using e.g.,
`AC_DEFINE_UNQUOTED(DATADIR, "$datadir")', you should add
`-DDATADIR="$(datadir)"' to your CPPFLAGS.

Similarly you should not rely on AC_OUTPUT_FILES to replace datadir and
friends in your shell scripts and other files, rather let make manage their
replacement. For instance Autoconf ships templates of its shell scripts
ending with `.in', and uses a Makefile snippet similar to:



edit = sed \
        -e 's,@datadir\@,$(pkgdatadir),g' \
        -e 's,@prefix\@,$(prefix),g'

autoconf: Makefile $(srcdir)/autoconf.in
        rm -f autoconf autoconf.tmp
        $(edit) $(srcdir)/autoconf.in >autoconf.tmp
        chmod +x autoconf.tmp
        mv autoconf.tmp autoconf

autoheader: Makefile $(srcdir)/autoheader.in
        rm -f autoheader autoheader.tmp
        $(edit) $(srcdir)/autoconf.in >autoheader.tmp
        chmod +x autoheader.tmp
        mv autoheader.tmp autoheader

Some details are noteworthy:

`@datadir\@'
    The backslash prevents configure from replacing `@datadir@' in the sed
expression itself.

`$(pkgdatadir)'
    Don't use `@pkgdatadir@'! Use the matching makefile variable instead.

`,'
    Don't use `/' in the sed expression(s) since most likely the variables
 you use, such as `$(pkgdatadir)', will contain some.

`Dependency on `Makefile''
    Since edit uses values that depend on the configuration specific values
(prefix etc.) and not only on VERSION and so forth, the output depends on
`Makefile', not `configure.ac'.

`Separated dependencies and Single Suffix Rules'
    You can't use them! The above snippet cannot be (portably) rewritten as:



    autoconf autoheader: Makefile
    .in:
            rm -f $@ $@.tmp
            $(edit) $< >$@.tmp
            chmod +x $@.tmp
            mv $@.tmp $@

    See section 10.10 Limitations of Make, for details.

``$(srcdir)''
    Be sure to specify the path to the sources, otherwise the package won't
support separated builds.

-------------------------------------------------------

Re: [Bashdb-devel] munge_list

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

> It looks like the convention used for bash builtin help is to use lowercase
> unadorned names in the usage but UPPERCASE when describing the option
> variable names in the help text.. So something like:
> 
>  readarray [-t] [-c count] [-C callback] [-n lines] [-O origin] file
> array_variable
> 
> Copy the lines from the input file into ARRAY_VARIABLE.
> 
> Use the `-n' option to specify COUNT  number of lines to copy.   If -n is
> missing or 0 is given as the number all lines are copied.
> Use the `-O' option to specify  index ORIGIN to start the array.
>  ...
> 
> (Or suitably modified to accomodate the current parameters allowed.)

Thank you. I've updated the documentation and installed to the cvs 
repository. Could you review the documentation?

Masatake

Re: [Bashdb-devel] munge_list

[Rocky B. <roc...@gm...>]

It looks like the convention used for bash builtin help is to use lowercase
unadorned names in the usage but UPPERCASE when describing the option
variable names in the help text.. So something like:

 readarray [-t] [-c count] [-C callback] [-n lines] [-O origin] file
array_variable

Copy the lines from the input file into ARRAY_VARIABLE.

Use the `-n' option to specify COUNT  number of lines to copy.   If -n is
missing or 0 is given as the number all lines are copied.
Use the `-O' option to specify  index ORIGIN to start the array.
 ...

(Or suitably modified to accomodate the current parameters allowed.)

On 8/22/06, Masatake YAMATO <je...@gy...> wrote:
>
> Hi,
>
> > > I'm reading readarray.c.
> > >
> > > I have two questions.
> > >
> > > 1. Is the function provided by munge_list needed anyway?
> >
> > Well, it's used as the first statement of readarray_builtin. But is it
> > really, really *needed*? Gee, I don't know. One could argue that
> > readarray altogether is not needed. For example SuSE packman packages
> > bashdb, and it doesn't use readarray. :-)
> >
> > The form of that option models how head and tail work, e.g.:
> >   head -10 /etc/motd
>
> I understand the intent.
> I removed munge_list from the in-cvs version of bashdb. However, I'll
> check
> how bash's builtins handles options again.
>
> > >    I'd like to remove because this option parsing policy(function)
> > >    is not widly used in bash.
> >
> > Ok. If there's someone out there that objects, that's why there's this
> > mailling list. A guess is that there isn't much use of readarray
> > outside of bashdb. So as long as bashdb still works without my having
> > to patch it (but I don't mind if however you do the patching should
> > there need to be any), I don't mind.
>
> If readarray is a command independent of bash, I think readarray should
> have munge_list.
>
> > >
> > > 2. What does the * stand for in the following doc string:
> > >
> > >    "readarray [-t] [-c *count*] [-C callback] [-n *lines*] [-O
> *origin*] *file* *array_variable*"
> > >
> > >    `*'s are needed in *count*, *lines*, *origin*, *file* and
> *array_variable*?
> >
> > This was to indicate a variable - something which is not typed in
> > exactly but represents the kind of thing you'd type in. For example, not
> > the string "*count*" but some sort of number, like 10. The use of
> > putting a word surrounded by asterisks to indicate an italicized word
> > I think was common in mailing lists like this one (See the first
> > paragraph of my reply above) and in older forms of email before the
> > days of HTML and other encodings.
> >
> > >    I'd like to remove it because this notation is not popular
> > >    in bash.
> >
> > Sure.
> >
> > > Tell me the backgrounds if there are.
> >
> > I am not sure I understand exactly what you mean here; but with luck
> > I've done that somewhere in the above verbiage.
>
> I understand the intent of `*'. Thank you. I thinks "-C callback" is a
> kind of variable.
> So I think it should be "-C *callback*". Am I right?
>
> I removed them and updated the document string yesterday.
> However, I'll check the other bash builtins.
>
> Masatake
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Bashdb-devel mailing list
> Bas...@li...
> https://lists.sourceforge.net/lists/listinfo/bashdb-devel
>

Re: [Bashdb-devel] munge_list

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

Hi,

> > I'm reading readarray.c.
> >
> > I have two questions.
> >
> > 1. Is the function provided by munge_list needed anyway?
> 
> Well, it's used as the first statement of readarray_builtin. But is it
> really, really *needed*? Gee, I don't know. One could argue that
> readarray altogether is not needed. For example SuSE packman packages
> bashdb, and it doesn't use readarray. :-)
> 
> The form of that option models how head and tail work, e.g.:
>   head -10 /etc/motd

I understand the intent.
I removed munge_list from the in-cvs version of bashdb. However, I'll check
how bash's builtins handles options again.

> >    I'd like to remove because this option parsing policy(function)
> >    is not widly used in bash.
> 
> Ok. If there's someone out there that objects, that's why there's this
> mailling list. A guess is that there isn't much use of readarray
> outside of bashdb. So as long as bashdb still works without my having
> to patch it (but I don't mind if however you do the patching should
> there need to be any), I don't mind.

If readarray is a command independent of bash, I think readarray should 
have munge_list.

> >
> > 2. What does the * stand for in the following doc string:
> >
> >    "readarray [-t] [-c *count*] [-C callback] [-n *lines*] [-O *origin*] *file* *array_variable*"
> >
> >    `*'s are needed in *count*, *lines*, *origin*, *file* and *array_variable*?
> 
> This was to indicate a variable - something which is not typed in
> exactly but represents the kind of thing you'd type in. For example, not
> the string "*count*" but some sort of number, like 10. The use of
> putting a word surrounded by asterisks to indicate an italicized word
> I think was common in mailing lists like this one (See the first
> paragraph of my reply above) and in older forms of email before the
> days of HTML and other encodings.
> 
> >    I'd like to remove it because this notation is not popular
> >    in bash.
> 
> Sure. 
> 
> > Tell me the backgrounds if there are.
> 
> I am not sure I understand exactly what you mean here; but with luck
> I've done that somewhere in the above verbiage.

I understand the intent of `*'. Thank you. I thinks "-C callback" is a kind of variable.
So I think it should be "-C *callback*". Am I right?

I removed them and updated the document string yesterday. 
However, I'll check the other bash builtins.

Masatake

Re: [Bashdb-devel] munge_list

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

Masatake informs:
> I'm reading readarray.c.
>
> I have two questions.
>
> 1. Is the function provided by munge_list needed anyway?

Well, it's used as the first statement of readarray_builtin. But is it
really, really *needed*? Gee, I don't know. One could argue that
readarray altogether is not needed. For example SuSE packman packages
bashdb, and it doesn't use readarray. :-)

The form of that option models how head and tail work, e.g.:
  head -10 /etc/motd

>    I'd like to remove because this option parsing policy(function)
>    is not widly used in bash.

Ok. If there's someone out there that objects, that's why there's this
mailling list. A guess is that there isn't much use of readarray
outside of bashdb. So as long as bashdb still works without my having
to patch it (but I don't mind if however you do the patching should
there need to be any), I don't mind.

>
> 2. What does the * stand for in the following doc string:
>
>    "readarray [-t] [-c *count*] [-C callback] [-n *lines*] [-O *origin*] *file* *array_variable*"
>
>    `*'s are needed in *count*, *lines*, *origin*, *file* and *array_variable*?

This was to indicate a variable - something which is not typed in
exactly but represents the kind of thing you'd type in. For example, not
the string "*count*" but some sort of number, like 10. The use of
putting a word surrounded by asterisks to indicate an italicized word
I think was common in mailing lists like this one (See the first
paragraph of my reply above) and in older forms of email before the
days of HTML and other encodings.

>    I'd like to remove it because this notation is not popular
>    in bash.

Sure. 

> Tell me the backgrounds if there are.

I am not sure I understand exactly what you mean here; but with luck
I've done that somewhere in the above verbiage.

[Bashdb-devel] status

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

> 1. How do you think rename readarray to readfile?
>   
>    I think the shell script writer may be confused read -a and readarray.
>    readfile is more specific name.

I did not rename it yet. I'm still looking for a good name.

> 
>    char *readarray_doc[] = {
> 	"Copy the lines from the input file into an array variable.",
> 	"Use the `-n' option to specify a count of the number of lines to copy.",
> 	"If -n is missing all lines are copied.",
> 	"Use the `-O' option to specify an index orgin to start the array.",
> 	"If -O is missing the origin will be 0.",
> 	"Use -t to chop trailing newlines (\\n) from lines.",
> 	"To read from stdin use '-' as the filename.",
>    In stead of specifying filename, how do you think fd like 
>     "read -u fd"? You can slow away `-'.
> 

I did. The documentation is not updated but now readarray takes -u option for specify
file descriptor. The file name is not acceptable. Use redirection instead.

I'm changing the coding style(variable name conversion and
indentation) to make it similar to that of bash.

I'll use more bash functions in readarray.c.

Then I'll convert readarray.c to readarray.patch:-P

[Bashdb-devel] munge_list

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

I'm reading readarray.c.

I have two questions.

1. Is the function provided by munge_list needed anyway?

   I'd like to remove because this option parsing policy(function)
   is not widly used in bash.

2. What does the * stand for in the following doc string:
   
   "readarray [-t] [-c *count*] [-C callback] [-n *lines*] [-O *origin*] *file* *array_variable*"

   `*'s are needed in *count*, *lines*, *origin*, *file* and *array_variable*?

   I'd like to remove it because this notation is not popular
   in bash.

Tell me the backgrounds if there are.

Masatake YAMATO

Re: [Bashdb-devel] eclipse, readarray

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

Masatake YAMATO writes:
 > > As for a callback, I think that was to allow for the progress bars you
 > > had added. A callback seems generally useful and doesn't seem to
 > > signficantly slow down the program so why remove it? 
 > 
 > Weak reason:
 > I introduced callback for "read" because it is really slow.
 > However, "readarray" is fast enough. Callback may be useful
 > but it is not necessary.

This is like Bill Gates saying you will never need a computer that
uses more than 640K of memory.

Okay, so readarray is isn't currently needed for script files in the
situation that came up because they are only tens of thousands of
lines long. Nobody reads in files that are millions of lines long
because, well, it would just take forever without readarray. But
should readarray or something like that become popular, perhaps people
will use it for reading files other than script files which are orders
of magnitudes larger.

 > 
 > Strong reason:
 > When I send readarray.c.patch to the bash maintainer, I have
 > to explain what readarray is. To make the explanation I'll write
 > simple, I'd like to make readarray simple and small as possible
 > as I can. Without bashdb background, the  maintainer may not 
 > understand why callback is needed; and I may not explain well
 > the background to him.

I don't think it is all that hard to understand or explain. (I do see
this that I forgot to document this option. Don't think the background
all all that deep either. 

But that said, you're doing the work; so do it any way you are
comfortable.

Re: [Bashdb-devel] eclipse, readarray

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

> As for a callback, I think that was to allow for the progress bars you
> had added. A callback seems generally useful and doesn't seem to
> signficantly slow down the program so why remove it? 

Weak reason:
I introduced callback for "read" because it is really slow.
However, "readarray" is fast enough. Callback may be useful
but it is not necessary.

Strong reason:
When I send readarray.c.patch to the bash maintainer, I have
to explain what readarray is. To make the explanation I'll write
simple, I'd like to make readarray simple and small as possible
as I can. Without bashdb background, the  maintainer may not 
understand why callback is needed; and I may not explain well
the background to him.

Masatake

Re: [Bashdb-devel] eclipse, readarray

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

All the changes you propose look good and make sense. Go for it! Only
thing I ask is to update the bashdb sources so that they aren't left
broken :-) (It would be a pity if the thing, bashdb, this was
initially written for and probably the only use of it were broken by
improving it.)

As for a callback, I think that was to allow for the progress bars you
had added. A callback seems generally useful and doesn't seem to
signficantly slow down the program so why remove it? 


Masatake YAMATO writes:
 > > 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?
 > 
 > Before, contacting to Chet Ramey, I'd like to have some discussions.
 > 
 > 1. How do you think rename readarray to readfile?
 >   
 >    I think the shell script writer may be confused read -a and readarray.
 >    readfile is more specific name.
 >   
 > 2. I think it is better to make readarray options are similar to read.
 > 
 >    char *readarray_doc[] = {
 > 	"Copy the lines from the input file into an array variable.",
 > 	"Use the `-n' option to specify a count of the number of lines to copy.",
 > 	"If -n is missing all lines are copied.",
 > 	"Use the `-O' option to specify an index orgin to start the array.",
 > 	"If -O is missing the origin will be 0.",
 > 	"Use -t to chop trailing newlines (\\n) from lines.",
 > 	"To read from stdin use '-' as the filename.",
 >    In stead of specifying filename, how do you think fd like 
 >     "read -u fd"? You can slow away `-'.
 > 
 > 3. Do you think callback is needed?
 > 
 >    readarray is fast enough, so I think callback arguments is
 >    overkilling. I tried more than 10000 lines configure. However,
 >    it takes no time to read.
 > 
 > Masatake
 > 

Re: [Bashdb-devel] eclipse, readarray

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

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

2006-08-02  Masatake YAMATO  <je...@gy...>

	* emacs/bashdb.el: Replace `pydb' with 'bashdb'.

--- bashdb.el	28  7月 2006 08:31:58 +0900	1.16
+++ bashdb.el	02  8月 2006 22:24:43 +0900	
@@ -37,10 +37,10 @@
 
 ;; The debugger outputs program-location lines that look like this:
 ;;   (/etc/init.d/network:14):
-(defconst gud-pydb-marker-regexp
+(defconst gud-bashdb-marker-regexp
   "^(\\([-a-zA-Z0-9_/.]*\\):\\([0-9]+\\)):[ \t]?\\(.*\n\\)")
-(defconst gud-pydb-marker-regexp-file-group 1)
-(defconst gud-pydb-marker-regexp-line-group 2)
+(defconst gud-bashdb-marker-regexp-file-group 1)
+(defconst gud-bashdb-marker-regexp-line-group 2)
 
 ;; Convert a command line as would be typed normally to run a script
 ;; into one that invokes an Emacs-enabled debugging session.
@@ -91,18 +91,18 @@
   (let ((output ""))
 
     ;; Process all the complete markers in this chunk.
-    (while (string-match gud-pydb-marker-regexp gud-marker-acc)
+    (while (string-match gud-bashdb-marker-regexp gud-marker-acc)
       (setq
 
        ;; Extract the frame position from the marker.
        gud-last-frame
        (cons (substring gud-marker-acc 
-			(match-beginning gud-pydb-marker-regexp-file-group) 
-			(match-end gud-pydb-marker-regexp-file-group))
+			(match-beginning gud-bashdb-marker-regexp-file-group) 
+			(match-end gud-bashdb-marker-regexp-file-group))
 	     (string-to-int 
 	      (substring gud-marker-acc
-			 (match-beginning gud-pydb-marker-regexp-line-group)
-			 (match-end gud-pydb-marker-regexp-line-group))))
+			 (match-beginning gud-bashdb-marker-regexp-line-group)
+			 (match-end gud-bashdb-marker-regexp-line-group))))
 
        ;; Append any text before the marker to the output we're going
        ;; to return - we don't include the marker in this text.

[Bashdb-devel] source_array[0]

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

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

2006-08-02  Masatake YAMATO  <je...@gy...>

	* dbg-io.inc: Put BASH_EXECUTION_STRING
	to ${source_array}[0], not [1].

--- dbg-io.inc	20  3月 2006 10:51:36 +0900	1.8
+++ dbg-io.inc	02  8月 2006 22:57:27 +0900	
@@ -204,7 +204,7 @@
   if [[ -z $filename ]] || [[ $filename == $_Dbg_bogus_file ]] ; then 
     filevar='ABOGUSA'
     source_array="_Dbg_source_${filevar}"
-    local cmd="${source_array}[1]=\"$BASH_EXECUTION_STRING\""
+    local cmd="${source_array}[0]=\"$BASH_EXECUTION_STRING\""
     eval $cmd
 
   else 

Re: [Bashdb-devel] eclipse, readarray

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

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

Before, contacting to Chet Ramey, I'd like to have some discussions.

1. How do you think rename readarray to readfile?
  
   I think the shell script writer may be confused read -a and readarray.
   readfile is more specific name.
  
2. I think it is better to make readarray options are similar to read.

   char *readarray_doc[] = {
	"Copy the lines from the input file into an array variable.",
	"Use the `-n' option to specify a count of the number of lines to copy.",
	"If -n is missing all lines are copied.",
	"Use the `-O' option to specify an index orgin to start the array.",
	"If -O is missing the origin will be 0.",
	"Use -t to chop trailing newlines (\\n) from lines.",
	"To read from stdin use '-' as the filename.",
   In stead of specifying filename, how do you think fd like 
    "read -u fd"? You can slow away `-'.

3. Do you think callback is needed?

   readarray is fast enough, so I think callback arguments is
   overkilling. I tried more than 10000 lines configure. However,
   it takes no time to read.

Masatake

Re: [Bashdb-devel] eclipse, readarray

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

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

Of couser if my mail doesn't goto the spam trash:)
Any good way to solve this situation?