bashdb-devel — Developer's discussion mailing list

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

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

Masatake YAMATO writes:
 > We can check the existence of wc at runtime.

Okay, that adds to reliability. 

 > We can use wc when if it exists. cat can be replaced with "<".

Good. I think it helps to reduce dependencies on external commands
when they are not necessary. And it looks like with a little extra
thought, it is not needed here. 

 > I should not call "wc -l < $file" when the script is under a 1,000 lines.

Good. 

 > If the lines over 1000, calling "wc -l < $file" once is just small overhead
 > against the total reading time.
 > 
 > BTW, I wrote a progress bar. Newer patch for bashdb will be based on this progress bar.

Great. 

- -

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

It always surprises and fascinates me what interests others, and what
they find and improve. Sometimes I don't initially see it, but I'm
always surprised and delighted over time at how things have become
much better with everyone's contributions, even in areas or aspects
that I didn't initially understand/appreciate. 

This is a long-winded way of saying - So go for it!

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

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

> I have some reservations about the patch below. I'm not against giving
> percentage versus lines read in per se. But here it comes with a some
> cost and perhaps reliability. The patch assumes that "wc" and "cat"
> are available commands and are in the path. (With extra work configure
> could check this and hard-code in the paths).  I don't belive the rest
> of the debugger makes use of either "cat" or "wc".  Perhaps the build
> system does, but I suppose that's okay since it is for developers. I
> don't know, I may be overly fussy here. 

We can check the existence of wc at runtime.

   if wc -l < /dev/null >/dev/null 2>&1 ; then echo ok; else echo fail; fi

We can use wc when if it exists. cat can be replaced with "<".

> And there's something I find weird about running a "cat | wc -l" just
> to get the total number of lines in a file. Right now, For the simple
> cases where the script is under a 1,000 lines, no extra work is done
> no, wc'ing no cat'ing no line printing. In those cases where one
> needs to print out status because the file is large, running 'cat | wc
> -l' slows things down more.

I should not call "wc -l < $file" when the script is under a 1,000 lines.
If the lines over 1000, calling "wc -l < $file" once is just small overhead
against the total reading time.

BTW, I wrote a progress bar. Newer patch for bashdb will be based on this progress bar.

#!/bin/sh

progress_raw_erase() {
    echo -e -n "\r\b"
}

# progress_raw_show
# $1 prefix string
# $2 max length
# $3 current length
progress_raw_show () {
    local -i i=0

    progress_raw_erase
    
    echo -n "$1: ["
    for (( i=0; i < $3 ; i++ )); do
	echo -n "="
    done
    echo -n ">"

    for (( i=0; i < $2 - $3 ; i++ )); do
	echo -n " "
    done
    echo -n "]"

}

# progress_show
# $1 prefix string
# $2 max value
# $3 current value
progress_show () {
    local title=$1
    local -i max_value=$2
    local -i current_value=$3
    local -i max_length=40
    local -i current_length

    
    if (( max_value == 0 )) ; then
	# Avoid dividing by 0.
	current_length=${max_length}
    else
	current_length=$(( ${max_length} * ${current_value} / ${max_value} ))
    fi
    
    progress_raw_show "$1" ${max_length} ${current_length}
}

# progress_done
# $1 completion message
progress_done() {
    progress_raw_erase
    echo $1
}


title="Reading a file"
progress_show "$title" 4 1
sleep 1
progress_show "$title" 4 2
sleep 1
progress_show "$title" 4 3
sleep 1
progress_show "$title" 4 4
progress_done "file is loaded."

[Bashdb-devel] reading progress...

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

Masatake YAMATO writes:
 > I've changed the reading progress notation to percentage style.
 > If we can show a progress bar, it may be the best.
 > But, I don't know how to erase written string on a terminal in a shell script.

I have some reservations about the patch below. I'm not against giving
percentage versus lines read in per se. But here it comes with a some
cost and perhaps reliability. The patch assumes that "wc" and "cat"
are available commands and are in the path. (With extra work configure
could check this and hard-code in the paths).  I don't belive the rest
of the debugger makes use of either "cat" or "wc".  Perhaps the build
system does, but I suppose that's okay since it is for developers. I
don't know, I may be overly fussy here. 

And there's something I find weird about running a "cat | wc -l" just
to get the total number of lines in a file. Right now, For the simple
cases where the script is under a 1,000 lines, no extra work is done
no, wc'ing no cat'ing no line printing. In those cases where one
needs to print out status because the file is large, running 'cat | wc
-l' slows things down more.

But this is just my view. What do others think? If folks feel the
benefits outweigh whatever disadvantages, by all means add it.

If the patch is added, some small comments. 

 > +    local line_count=`cat $fullname|wc -l`

local -i might be better. I would be neat if there were a way to give
$fullname to wc rather than piple the whole file to wc.  Also, I think
it clear when the definition is put as close as possible to would be 
after the test on $fullname. 

 > +	  (( i==1000 )) && _Dbg_msg_nocr "Reading $filename: \n"
 > +	  _Dbg_msg_nocr "\t$(( 100 * ${i} / ${line_count} ))%..."

One should check that $line_count is not 0 before dividing. If it is
zero (perhaps something went wrong) then probably one should fall back
to giving line number counts. 

Re: [Bashdb-devel] configure.ac and .in

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

configure.in -> configure.ac patches have been applied. Thanks. 

I've also changed your sourceforge account so you can make changes
directly to the CVS repository.

[Bashdb-devel] reading progress...

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

I've changed the reading progress notation to percentage style.
If we can show a progress bar, it may be the best.
But, I don't know how to erase written string on a terminal in a shell script.

Masatake YAMATO

Index: debugger/dbg-io.inc
===================================================================
RCS file: /cvsroot/bashdb/bashdb/debugger/dbg-io.inc,v
retrieving revision 1.8
diff -u -r1.8 dbg-io.inc
--- debugger/dbg-io.inc	12 Nov 2003 11:48:51 -0000	1.8
+++ debugger/dbg-io.inc	16 May 2004 17:27:53 -0000
@@ -109,6 +109,7 @@
     i=1
   else 
     local fullname=$(_Dbg_resolve_expand_filename $filename)
+    local line_count=`cat $fullname|wc -l`
     filevar=`_Dbg_file2var $filename`
     if [[ -r $fullname ]] ; then
       for (( i=1; 1 ; i++ )) ; do 
@@ -116,8 +117,8 @@
 	local readline_cmd="read -r $source_entry; rc=\$?";
 	local -i rc=1
 	if (( i % 1000 == 0 )) ; then
-	  (( i==1000 )) && _Dbg_msg_nocr "Reading $filename "
-	  _Dbg_msg_nocr "${i}... "
+	  (( i==1000 )) && _Dbg_msg_nocr "Reading $filename: \n"
+	  _Dbg_msg_nocr "\t$(( 100 * ${i} / ${line_count} ))%..."
 	fi
 	eval $readline_cmd
 	if [[ $rc != 0 ]]  ; then 

Re: [Bashdb-devel] configure.ac and .in

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

Sorry. The last patch is no enough to build.
This is the revised patch.

Masatake YAMATO

Index: configure.ac
===================================================================
RCS file: /cvsroot/bashdb/bashdb/configure.ac,v
retrieving revision 1.1
diff -u -r1.1 configure.ac
--- configure.ac	16 May 2004 06:42:41 -0000	1.1
+++ configure.ac	16 May 2004 17:00:37 -0000
@@ -1034,7 +1034,7 @@
 # Keep old dates on these so we don't gratuitously have make do work.
 if test -e $ac_srcdir/doc/version.texi ;then
 	echo timestamp > $ac_srcdir/doc/stamp-vti
-	touch -cr $ac_srcdir/configure.in doc/version.texi $ac_srcdir/doc/stamp-vti
+	touch -cr $ac_srcdir/configure.ac doc/version.texi $ac_srcdir/doc/stamp-vti
 fi
 ]],[[]])
 AC_OUTPUT
Index: bootstrap.sh
===================================================================
RCS file: /cvsroot/bashdb/bashdb/bootstrap.sh,v
retrieving revision 1.5
diff -u -r1.5 bootstrap.sh
--- bootstrap.sh	12 Sep 2003 02:17:16 -0000	1.5
+++ bootstrap.sh	16 May 2004 17:00:37 -0000
@@ -11,7 +11,7 @@
 srcdir=`dirname $0`
 test -z "$srcdir" && srcdir=.
 
-(test -f $srcdir/configure.in) || {
+(test -f $srcdir/configure.ac) || {
     echo -n "*** Error ***: Directory "\`$srcdir\'" does not look like the"
     echo " top-level directory"
     exit 1
Index: Makefile.in
===================================================================
RCS file: /cvsroot/bashdb/bashdb/Makefile.in,v
retrieving revision 1.14
diff -u -r1.14 Makefile.in
--- Makefile.in	14 May 2004 04:14:01 -0000	1.14
+++ Makefile.in	16 May 2004 17:00:38 -0000
@@ -624,7 +624,7 @@
 	$(SHELL) ./config.status --recheck
 
 # comment out for distribution
-$(srcdir)/configure:	$(srcdir)/configure.in $(srcdir)/aclocal.m4 $(srcdir)/config.h.in
+$(srcdir)/configure:	$(srcdir)/configure.ac $(srcdir)/aclocal.m4 $(srcdir)/config.h.in
 	cd $(srcdir) && autoconf
 
 # for chet

[Bashdb-devel] configure.ac and .in

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

bootstrap.sh still uses "configure.in".

My sourceforge account is changed to "myamato". So I cannot install
the change by myself. Please, install. 

2004-05-17  Masatake YAMATO  <je...@gy...>

	* bootstrap.sh (srcdir): s/configure.in/configure.ac/

*** bootstrap.sh.old	2003-09-12 11:17:16.000000000 +0900
--- bootstrap.sh	2004-05-17 01:32:45.000000000 +0900
***************
*** 11,17 ****
  srcdir=`dirname $0`
  test -z "$srcdir" && srcdir=.
  
! (test -f $srcdir/configure.in) || {
      echo -n "*** Error ***: Directory "\`$srcdir\'" does not look like the"
      echo " top-level directory"
      exit 1
--- 11,17 ----
  srcdir=`dirname $0`
  test -z "$srcdir" && srcdir=.
  
! (test -f $srcdir/configure.ac) || {
      echo -n "*** Error ***: Directory "\`$srcdir\'" does not look like the"
      echo " top-level directory"
      exit 1

[Bashdb-devel] Preparation for 0.43 release

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

It's been a while since the last release and there are a couple of
bugs I've found since then. So I've been planning on another release
soon. 

If there's interest I can post a candidate tarball. If not, people who
pick up the release can test. And of course there's what is currently
in CVS.

Re: [Bashdb-devel] Debugging bashdb

[Tobias C. R. <tc...@fr...>]

On Wednesday, November 26, 2003 at 11:22:34 AM,=20
    Erhy Happ <erh...@ho...> wrote:

> Platform: Cygwin under Windows 2000
> [...] I want to debug bashdb with gdb.
> But with this tricky programming like =93code =3D setjmp (top_level);=94=
,
> Bashdb loops invisible from gdb.

What exactly do you mean with "loops invisible from gdb"?

gdb should be able to handle setjmp's and longjmp's, at least on Linux
(and other unices very probably too). `maint info breakpoints' should
give you a line with a "longjmp resume" as type and a negative number.


-- tcr (tc...@fr...)  ``Ho chresim'eidos uch ho poll'eidos sophos''

[Bashdb-devel] Debugging bashdb

[Erhy H. <erh...@ho...>]

Platform: Cygwin under Windows 2000
Hello,
  because I get no or no ending output by using the bashdb command V ,
I want to debug bashdb with gdb.
But with this tricky programming like “code = setjmp (top_level);”,
Bashdb loops invisible from gdb.

Please tell me something about this concept of programming, and how to debug 
bashdb.
Thanks,
Erhy

_________________________________________________________________
Messenger  -  Wer in Echtzeit kommunizieren will, lädt den MSN Messenger. 
Cool, kostenlos und mit 3D Emoticons:  http://messenger.msn.at

[Bashdb-devel] Bashdb-devel digest, Vol 1 #44 - 1 msg

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

Erhy Happ reports:
 >   my computer is running with Windows 2000 and because my UNIX interests
 > I installed mingw und msys.
 > Is there any chance to compile and/or run bashdb like sh.exe of msys ?

sh in msys is bash version 2.04; rebash, the debugger-enabled bash, is
based on bash 2.05b. Since version 2.04 is a bit old, I've always
assumed that there was a reason the mingw folks decided to use 2.04
instead of 2.05x. Perhaps bash 2.04 has fewer dependencies.

rebash does compile and run under cygwin. So that's one way to get
bash debugging in Windows 2000.

As for whether there is a chance to compile and run bashdb under
sh.exe or msys, it requires someone to take the interest to do
so. Given that it works under cygwin (well, actually some of the
regression tests fail), I don't have interest undertaking
this. However if someone else does (perhaps yourself), I don't see any
reason not to include it, provided things are done in a relatively
clean way.

 > 
 > I'm also not able to compile the sources of sh.exe in the msys project.
 > It seems the reason are the same like:
 >     eval.c:252: `SIGALRM' undeclared (first use in this function)

I think you'd probably have to ask the mingw about that. 

[Bashdb-devel] with WIN32

[Erhy H. <erh...@ho...>]

Hello,
  my computer is running with Windows 2000 and because my UNIX interests
I installed mingw und msys.
Is there any chance to compile and/or run bashdb like sh.exe of msys ?

I'm also not able to compile the sources of sh.exe in the msys project.
It seems the reason are the same like:
    eval.c:252: `SIGALRM' undeclared (first use in this function)

Thank you for an answere.

Erhy

_________________________________________________________________
Hotmail  -  Absolut kostenfrei! Der weltweit größte E-Mail-Anbieter im Netz: 
  http://www.msn.at/hotmail  Jetzt kostenlos downloaden!

[Bashdb-devel] bash 3.0

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

bash 3.0 is in alpha (or maybe it's beta by now). It has most of the
debugging support from this project, although I'm not certain it has
all of it.

The reason I'm not certain is just that a lot of stuff has been moved
around. What is "set -o fntrace" or "set -d" in rebash is in bash 3.0
"set -o functrace" or "set -T". You have to add "shopt -s extdebug" in
bash 3.0 to get any sort of debugging.

And in the code various declarations have been moved around or renamed
slightly: "the_printed_command_sans_trap" is now
"the_printed_command_except_trap".

Where I put: 
  subshell_level++;
  USE_VAR(user_subshell);
  USE_VAR(invert);
  USE_VAR(tcom);
  USE_VAR(asynchronous);

is in bash 3.0:

  USE_VAR(user_subshell);
  USE_VAR(invert);
  USE_VAR(tcom);
  USE_VAR(asynchronous);

  subshell_level++;

Some things I'm sure are improvements. Most of these things however,
probably semantically don't amount to much. Renaming
"the_printed_cmmand_sans_trap" I'm pretty sure doesn't change things
semantically, but I'm hard pressed to understand if there is a
semantic difference is in moving subshell_level above.

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

Omissions to me that are of some concern me are those made by other
folks such as to the auto stuff that done't appear in bash 3.0. The
project in contrast to bash 3.0 was intended as a vehicle whereby
others can find something they want changed discuss and fix and I
don't want to discourage that.

So here's what I'm thinking of doing. Create a split in the CVS tree
for bash 3.0 since there are just lots of changes and 2.05b and 3.0
can't be compatible from the debugger standpoint. For bash 3.0, the
debugger part I guess I'd try to have work both in bash 3.0 alpha and
in whatever additions we currently do and might have.

The good news is that bash 3.0 will have debugger support built
in. Will vanila bash have all of what's there? Don't know.

I welcome thoughts, comments, advice on how to proceed.

[Bashdb-devel] gud.el for emacs20, bash 3.0

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

Matthias Klose writes:
 > Please could you have a look at http://bugs.debian.org/bashdb ?
 > Could you make it to work with emacs20 as well?
 > 
 > Thanks, Matthias

Support for bashdb is I believe in the current emacs CVS, so starting
with emacs 21.4, presumably, this won't be needed.

I've added a test for to see that emacs version is in the range 21.0
.. 21.3 and that's in rebash CVS right now. Here's the diff in case
you want to apply separately until a release:

[Bashdb-devel] Re: Bash 3.0 duck-hunting season opens [Masatake YAMATO <jet@gyve.org>]

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

R. Bernstein wrote:
> Thanks for the information on bash 3.0. I've ftp'd
> bash-3.0-alpha.tar.gz and made a preliminary scan. I'm absolutely
> delighted that the timestamped history is there (I found that very
> helpful when a friend's server was hacked into in determining who did
> what.)
> 
> I'm in the middle of another project right now, but I hope next week
> to compile the bash 3.0 alpha and test with the current debugger CVS
> sources that live outside of the bash execuable.

Read the changelog carefully.  The changes I made are not identical
to the ones in your sources.  Most notably, the `set' options differ,
and some of the more incompatible debugger behavior is enabled with
a new `extdebug' option.

Chet

[Bashdb-devel] Bash 3.0 duck-hunting season opens [Masatake YAMATO <jet@gyve.org>]

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

Thanks for the information on bash 3.0. I've ftp'd
bash-3.0-alpha.tar.gz and made a preliminary scan. I'm absolutely
delighted that the timestamped history is there (I found that very
helpful when a friend's server was hacked into in determining who did
what.)

I'm in the middle of another project right now, but I hope next week
to compile the bash 3.0 alpha and test with the current debugger CVS
sources that live outside of the bash execuable.

Some small things that come to mind: 

- a recent change was made to be able to customize where the debugger
gets installed. The prevailing opinion seems to be that default
location should be $prefix/share rather than $prefix/lib.

- In CVS, the debugger is installed in "debugger" so it would be
helpful to have the directory called that. 

- I've been improving the regression-testing scripts to use
information from configure so that spurious messages (e.g. this test
may fail if job control or arrays are not around) are removed and to
make them more easily runnable as a standalone routine.

Again, thanks.


Chet Ramey writes:
 > own...@po... wrote:
 > 
 > > Date: Sat, 27 Sep 2003 15:40:19 +0900 (JST)
 > > From: Masatake YAMATO <je...@gy...>
 > > Subject: bashdb
 > > In-reply-to: <030...@ni...>
 > > To: bas...@cw...
 > > Cc: ro...@pa...
 > 	[...]
 > > 
 > >>The first alpha release of bash-3.0 is now available with the URL
 > >>
 > >>ftp://ftp.cwru.edu/hidden/bash-3.0-alpha.tar.gz
 > >>
 > >>This tar file does not include the formatted documentation (you
 > >>should be able to generate it yourself).
 > > 
 > > 
 > > I've just gotten bash-3.0-alpha.tar.gz.
 > > I have some questions.
 > > 
 > > Is new bashdb suported in this version?
 > > 
 > > configure.in:
 > > if test -z "${DEBUGGER_START_FILE}"; then
 > > 	DEBUGGER_START_FILE=${ac_default_prefix}/lib/bashdb/bashdb-main.inc
 > > fi
 > > I cannot find ${srcdir}/lib/bashdb in the tar ball. Only a little explanation 
 > > about debugger in the documents.
 > > 
 > > It means only C code of debugger is included in bash-3.0?
 > 
 > In my alpha version, it is.  I am assuming that Rocky will perform the
 > necessary work to integrate his code into bash-3.0, since the changes
 > I made are not identical to the ones he submitted, and by the time
 > bash-3.0 hits the street the two will be in sync.
 > 
 > Rocky, feel free to either replace examples/bashdb or add a bashdb
 > subdirectory directly in the source directory.
 > 
 > Chet

[Bashdb-devel] bash-2.05b-rebash-0.43 release candidate

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

I've put a release candidate for bash-2.05b, rebash-0.43 at
  ftp://ftp.netwinder.org/users/r/rocky/bash-2.05b-rebash-0.43.tar.gz

I'll be testing this on the various hardware I have available. Others
are encouraged to do so also. 

Known problems and things deferred to next release:
-  running two "info variable dq*" seems to work wrong on Darwin
   (a regression test in misc.cmds has been commented out)
-  making sure texinfo pod2man are not used gratuitously on a build
   Mikael Andersson has been looking at this.

[Bashdb-devel] Another release coming up?

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

I was thinking about having another release which address these things:

- fixes to make Cygwin and OS X work

- configurable package and executable names

- Changes for Debian inclusion

- Bug: a comment line in the history was taken as a timestamp and we 
  dumped core. Non-timestamp comment lines should appear in the history now.

As always, it would be nice if folks tried out what was in CVS the
release to make sure that there are no bugs. 

Thanks!

[Bashdb-devel] Some remaining autostuff suggestions done

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

I've put into CVS some of the suggestions Mikael Andersson suggested
earlier.

bashdb-pre.inc is now created from debugger rather than the top-level
directory and acinclude.m4 now lives in debugger rather than the
top-level directory.  (bootstrap.sh picks acinclude.m4 up in its
aclocal via "-I debugger").

The package names are now bash-2.05b-rebash-xxx and
bash-2.05b-debugger-xxx.  I couldn't figure out how to make the
executable install by default under the name "rebash".

Also I couldn't figure out how to move the creation of
debugger/doc/version.texi into debugger without getting the following
Makefile warnings:

Makefile:135: warning: overriding commands for target `version.texi'
Makefile:132: warning: ignoring old commands for target `version.texi'

Finally, to placate Matthias Klose and presumably Debian folks while
they decide whether or not it's okay to have GNU philosophical sections
unmodifiable (and the whole issue of whether an author can declare
parts of a document unchangable as a representation of his work), I've
removed the requirement that these sections remain unmodified:

``Free Software'' and ``Free Software Needs Free Documentation'', with
 the Front-Cover Texts being ``A GNU Manual,''
 

Re: [Bashdb-devel] Re Autostuff patches.

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

Mikael Andersson writes:
 > 
 > Maybe we should remove the files build in debugger by the bash configure also ?
 > More specifically: debugger/dbg-pre.inc and debugger/doc/version.texi.

Yes, that would be a good thing to do. 

 > I understand that those are there to use the version in bash for the version 
 > in debugger. But if we accept updating version number in both directories we 
 > can move building those files into debugger also. 

I accept this. The bash version change on the order of once every
couple of years. 2.05b hasn't changed all that often. In fact, it
hasn't so far :-).

 > We could also remove most 
 > of the debugger specific configure things from the bash directory if we note 
 > in the README/INSTALL that running ./configure --help=recursive is a good 
 > idea if you want to know the options available.

Fine by me. By not changing things in (re)bash that aren't needed, we
limit the changes that will be needed when the next release comes out
and that would be a good thing.

 > The naming conventions are a bit confusing and if anything can be done to make 
 > clearer what the different packages is, so much better. 

Is rebash-2.05b-xxx and bash-2.05b-bashdb-xxx (or
rebash-2.05b-bashdb-xxx) clearer?

 > Why not have acinclude.m4 only in debugger and copy it to the
 > top-level dir ? In this way debugger is almost completely self-contained with 
 > the above mentioned fixes regarding files built by top-level but used by the 
 > debugger build.

Another great idea. The top-level directory could include via "aclocal
-I debugger" Although debugger can't always assume rebash will be
there, rebash can probably assume that debugger will be around. 

If you can, I'd appreciate it if you make these great
suggestions. Many thanks.

Re: [Bashdb-devel] Re Autostuff patches.

[Mikael A. <sn...@te...>]

On Tuesday 26 August 2003 05.29, R. Bernstein wrote:
> I hvave made some small additions to the recent good autostuff work.
>
> A little background. The debugger directory I view as an independent
> unit. Right now it needs the bash program from the parent directory
> but hopefully it might not in the future. So I've been trying to keep
> things under debugger self-contained.
>

My we should remove the files build in debugger by the bash configure also ?
More specifically: debugger/dbg-pre.inc and debugger/doc/version.texi.
I understand that those are there to use the version in bash for the version 
in debugger. But if we accept updating version number in both directories we 
can move building those files into debugger also. We could also remove most 
of the debugger specific configure things from the bash directory if we note 
in the README/INSTALL that running ./configure --help=recursive is a good 
idea if you want to know the options available.

> When I did a "make distcheck" in the debugger directory, the tarball
> crated was bash-2.05b.tar.gz. This would be the name for an unmodified
> bash rather than the debugger portion of an enhanced bash. I've
> changed the distribution tarball to bash-2.05b-bashdb-xxx.tar.gz. I
> realize this is a little confusing given the parent directory tarball
> which includes this is bash-2.05b-debugger-xxx.tar.gz. Perhaps that
> tarball name should change to rebash-2.05b-xxx-tar.gz.

The naming conventions are a bit confusing and if anything can be done to make 
clearer what the different packages is, so much better. 

> Another problem in the debugger directory was the fact that if
> autoconf chose to run again it couldn't find acinclude.m4 since that's
> only in the top-level directory, not the debugger directory. 
> What I've
> done here is have the top-level configure.in copy this file to
> debugger; acinclude.m4 is also added to the bashdb tarball:
> bash-2.05b-bashdb-xxx.tar.gz. I considered adding it to bootstrap.sh,
> but then changes in the top-level acinclude.m4 wouldn't get reflected
> below. Another possibility would be to set the ac macro directory with
> -I to include the top-level directoyr. But again this makes the debugger
> less independent.
>

Why not have acinclude.m4 only in debugger and copy it to the
top-level dir ? In this way debugger is almost completely self-contained with 
the above mentioned fixes regarding files built by top-level but used by the 
debugger build.

> Finally, I've removed debugger/dbg-main.inc from CVS (although it's
> still in the Attic for CVS) since this is now derived from
> dbg-main.inc.in.
>

Naturally

> As always if you have improvments, problems with this, comments, or
> suggestions, let me know.
>

/Mikael

Re: [Bashdb-devel] Re Autostuff patches.

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

I hvave made some small additions to the recent good autostuff work.

A little background. The debugger directory I view as an independent
unit. Right now it needs the bash program from the parent directory
but hopefully it might not in the future. So I've been trying to keep
things under debugger self-contained.

When I did a "make distcheck" in the debugger directory, the tarball
crated was bash-2.05b.tar.gz. This would be the name for an unmodified
bash rather than the debugger portion of an enhanced bash. I've
changed the distribution tarball to bash-2.05b-bashdb-xxx.tar.gz. I
realize this is a little confusing given the parent directory tarball
which includes this is bash-2.05b-debugger-xxx.tar.gz. Perhaps that
tarball name should change to rebash-2.05b-xxx-tar.gz.

Another problem in the debugger directory was the fact that if
autoconf chose to run again it couldn't find acinclude.m4 since that's
only in the top-level directory, not the debugger directory. What I've
done here is have the top-level configure.in copy this file to
debugger; acinclude.m4 is also added to the bashdb tarball:
bash-2.05b-bashdb-xxx.tar.gz. I considered adding it to bootstrap.sh,
but then changes in the top-level acinclude.m4 wouldn't get reflected
below. Another possibility would be to set the ac macro directory with
-I to include the top-level directoyr. But again this makes the debugger
less independent.

Finally, I've removed debugger/dbg-main.inc from CVS (although it's
still in the Attic for CVS) since this is now derived from
dbg-main.inc.in.

As always if you have improvments, problems with this, comments, or
suggestions, let me know.

Re: [Bashdb-devel] Re Autostuff patches.

[Mikael A. <sn...@te...>]

On Friday 22 August 2003 22.39, R. Bernstein wrote:
>  > Here they are for everyones amusement ... have a look if you dare .)
>  > Haven't got around to fixing manpages yet, but i thought i'd solicit
>  > some comment and commit these fixes first.
>
> Over all things I think this is a big big improvement. Many thanks!
>
> I would like to suggest one change to a comment to configure.ac which
> I'll send privately. And when I cd into the debugger directory and try
> "make distcheck",  I get this error which I don't believe was there before:
>
> ./config.status: line 1: cd: ../../emacs: No such file or directory
> config.status: creating emacs/Makefile
> config.status: error: cannot find input file: emacs/Makefile.in
>

It was emacs missing in subdirs list in debugger/Makefile.am

> I have a feeling $srcdir is inherited when it shouldn't be. Otherwise
> things look very good.
>
>  > As for autoconf/automake versions I have a AC_PREREQ(2.57) , but it
>  > probably needs to be relaxed a bit (2.53 was previous value).
>
> Yes, please. And the value in debugger was 2.50.
>

I set it to 2.53 in both places as it seemed as the most sensible thing to do.

>  > It was set by autoupdate which i used to do a first pass of getting
>  > the autoconf files somewhat up to date.
>
> It's very generous of the autoupdate folks to coerce everyone to into
> getting new (and sometimes incompatible) versions of
> autoconf/automake.  But let's not take advantage of this fabulous
> offer when it is not needed as is the case here.
>
> Please go ahead and check this all back into CVS taking into account
> the above changes as you see fit.
>
>

It's now commited, with a log comment which (unfortunately) lacks all kind of 
formatting since i managed to loose the linefeeds in it. So here it is in all 
it's glory, or at least - with - linefeeds: 

Mikael fixed: 
	* removed deprecated Autoconf constructs 
	* bootstrap.sh execution order and include location 
	* install into pkgdatadir instead of libdir 
	* use AC_SUBST to configure all paths instead of hardcoding 
And added: 
	* configurable package name using env. var. ALT_PACKAGE_NAME 
	* configurable executable names 
	* dbg-main.inc is genereated from dbg-main.inc.in now 
	* local m4 macros now reside in acinclude.m4

/Mikael

[Bashdb-devel] Re Autostuff patches.

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

 > Here they are for everyones amusement ... have a look if you dare .)
 > Haven't got around to fixing manpages yet, but i thought i'd solicit some 
 > comment and commit these fixes first.

Over all things I think this is a big big improvement. Many thanks! 

I would like to suggest one change to a comment to configure.ac which
I'll send privately. And when I cd into the debugger directory and try
"make distcheck",  I get this error which I don't believe was there before:

./config.status: line 1: cd: ../../emacs: No such file or directory
config.status: creating emacs/Makefile
config.status: error: cannot find input file: emacs/Makefile.in

I have a feeling $srcdir is inherited when it shouldn't be. Otherwise
things look very good.

 > As for autoconf/automake versions I have a AC_PREREQ(2.57) , but it probably 
 > needs to be relaxed a bit (2.53 was previous value). 

Yes, please. And the value in debugger was 2.50. 

 > It was set by autoupdate which i used to do a first pass of getting
 > the autoconf files somewhat up to date.

It's very generous of the autoupdate folks to coerce everyone to into
getting new (and sometimes incompatible) versions of
autoconf/automake.  But let's not take advantage of this fabulous
offer when it is not needed as is the case here.

Please go ahead and check this all back into CVS taking into account
the above changes as you see fit.

[Bashdb-devel] Autostuff patches.

[Mikael A. <sn...@te...>]

Here they are for everyones amusement ... have a look if you dare .)
Haven't got around to fixing manpages yet, but i thought i'd solicit some 
comment and commit these fixes first.
As for autoconf/automake versions I have a AC_PREREQ(2.57) , but it probably 
needs to be relaxed a bit (2.53 was previous value). It was set by autoupdate 
which i used to do a first pass of getting the autoconf files somewhat up to 
date. 

I split the changes into 3 patchfiles.
* new files
* changed files
* changed testcases ( bashdb.in got a few lines more )

/Mikael