bashdb-devel — Developer's discussion mailing list

Re: [Bashdb-devel] Status update: Auto... related changes.

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

I just took a look at the doc/Makefile.in patches and all of these
mistakes look like they are mine which were made early in CVS which
are not in the official bash 2.05b (between version 1.1 and 1.2). 

One difference I note is that I have the Info generated as bash.info
while bash 2.05b has it going in as bashref.into. I'm not sure why I
made that change and perhaps that should go back.

At any rate I think you should check that in (since after all these
are really fixes you've found) and at the same time you can test that
CVS commit works. 

Re: [Bashdb-devel] Status update: Auto... related changes.

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

On Tuesday 19 August 2003 10.25, R. Bernstein wrote:
> Mikael Andersson reports:
>  > A short status update on auto... changes:
>
> Thanks for the update.
>
>  > I'll post a patch as soon as possible, planned to do it today but
>  > stumbled upon a few more bugs. And it'll probably take me at least a few
>  > day to work it out.
>
> No hurry. The next release is basically yours. :-) My own opinion is it's
> preferable to have it done correctly or thoroughly than done soon.
>
>  > Currently working on:
>  > * Remove deprecated autoconf and automake constructs.
>
> Always good. At least until the next release of autoconf and automake
> which no doubt will change everything around again. That's what makes
> working with these so much fun and a such a devoted effort. ;-) If you
> mean renaming bash's configure.in to configure.ac, I hesitated there
> because things in the top-level directory should be merged into bash
> 2.05b and it is not clear at present no one really knows what will
> really happen. You'll find in the *debugger* directory that there is a
> configure.ac and not configure.in. The debugger directory could be
> split off as a separate package if/when bash changes are merged into
> bash.
>
>  > Pending:
>  > * Trying to install empty file (or directory). Creates an install.gz
>  > file
>
> I don't understand this is about. Why is it desired to install a empty
> file or directory?
It's not desirable but in the Makefile.in in the doc directory a lot of 
strange things happen. Check the diff attached for my changes of this file.

>
>  > Won't adress in this fix:
>  > * manpage names same as executables ( if executable names are
>  > transformed )
>
> It doesn't seem that hard to address if there other packages can deal
> with. I wonder how other packages address this?
>
I'll try to dig up some example here and see what i can find.

>  > * builtins and rbash plain text files is not generated correctly
>
> Do you mean plain text help files the builtins are generated (correctly)
> now and in the future they won't be?
>
They are not generated correctly on my system because of the ".so man1/bash.1" 
include in the groff source. For it to succed it needs ".so bash.1". But if 
the file (eg buildins.1 is installed i belive it needs ".so man1/bash.1"

>  > Done but not commited yet:
>  > * configurable package name. (Environment variable)
>  > * configurable executable names. (Standard automake/autoconf way with
>  > sed scripts)
>
> Great.
>
>  > * bootstrap.sh executed auto... commands in odd order ( Always gave me
>  > an error on first run )
>
> I think this script I had to write when I put this in CVS. There is also
> autogen.sh which runs bootstrap.sh + configure. I've never understood the
> auto system well enough, so I would not be surprised if it has
> problems/bugs. Anything you can do to improve it is welcome.
>
>  > * script files now installs in pkgdatadir. Note: Not everybody agrees on
>  > this interpretation of FHS although i belive it make sense ( and
>  > obviously also those who make emacs and perl )
>
> I don't understand what FHS stands for. As long as things are self
> consistent and those folks who have strong opinions on such matters
> can configure this (and I don't think I'm in that category), then I
> don't think there should be a problem.

It's simply a filesystem hiearchy standard which is atleast somewhat sane  :)
http://www.pathname.com/fhs/2.2/

>
>  > * No more hardcoded paths in script-files. As a consequence dbg-main.inc
>  > is to be replaced with dbg-main.inc.in
>  > * A location for bashdb specific macros (acinclude.m4)
>
> Again all good.
>
> Thanks for taking this mess on.
>
>
Diff of Makefile.in. If you generate a Makefile from the current Makefile.in, 
note the defintions of INSTALL and INSTALL_DATA. On my machine they both
contained install -c ... so it ran install -c install -c. The other fix below 
is install-info trying to install a directory instead of bashdb.info


cvs -z3 diff  "Makefile.in"
Index: Makefile.in
===================================================================
RCS file: /cvsroot/bashdb/bashdb/doc/Makefile.in,v
retrieving revision 1.13
diff -u -3 -p -r1.13 Makefile.in
--- Makefile.in	1 Jun 2003 14:36:56 -0000	1.13
+++ Makefile.in	19 Aug 2003 15:27:00 -0000
@@ -235,23 +235,23 @@ installdirs:
 
 install: info installdirs
 	@list='$(MAN1FILES)'; for p in $$list; do \
-	  $(INSTALL) $(INSTALL_DATA) $(srcdir)/$$p.1 $(DESTDIR)$(man1dir) ; \
+	  $(INSTALL_DATA) $(srcdir)/$$p.1 $(DESTDIR)$(man1dir) ; \
 	done
 # uncomment the next line to install the builtins man page
 #	-$(INSTALL_DATA) $(srcdir)/builtins.1 
$(DESTDIR)$(man1dir)/bash_builtins${man1ext}
 	@list='$(INFOFILES)'; for p in $$list; do \
-	  $(INSTALL) $(INSTALL_DATA) $(srcdir)/$$p $(DESTDIR)$(infodir) ; \
+	  $(INSTALL_DATA) $(srcdir)/$$p $(DESTDIR)$(infodir) ; \
 	done 
 # run install-info if it is present to update the info directory
 	if $(SHELL) -c 'install-info --version' >/dev/null 2>&1; then \
 	  for p in $(INFOFILES); do \
-		install-info --dir-file=$(DESTDIR)$(infodir)/dir $(DESTDIR)$(infodir); \
+		install-info --dir-file=$(DESTDIR)$(infodir)/dir $(DESTDIR)$(infodir)/$$p; 
\
 	  done ; \
 	else true; fi
 # if htmldir is set, install the html files into that directory
 	-if test -n "${htmldir}" ; then \
 	   @list='$(HTMLFILES)'; for p in $$list; do \
-f		$(INSTALL) $(INSTALL_DATA) $(srcdir)/$$p $(DESTDIR)$(htmldir) ; \
+f		$(INSTALL_DATA) $(srcdir)/$$p $(DESTDIR)$(htmldir) ; \
 	   done; \
 	fi
 

[Bashdb-devel] Status update: Auto... related changes.

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

Mikael Andersson reports: 
 > A short status update on auto... changes:

Thanks for the update.

 > 
 > I'll post a patch as soon as possible, planned to do it today but stumbled 
 > upon a few more bugs. And it'll probably take me at least a few day to work 
 > it out.

No hurry. The next release is basically yours. :-) My own opinion is it's
preferable to have it done correctly or thoroughly than done soon. 

 > 
 > Currently working on:
 > * Remove deprecated autoconf and automake constructs.

Always good. At least until the next release of autoconf and automake
which no doubt will change everything around again. That's what makes
working with these so much fun and a such a devoted effort. ;-) If you
mean renaming bash's configure.in to configure.ac, I hesitated there
because things in the top-level directory should be merged into bash
2.05b and it is not clear at present no one really knows what will
really happen. You'll find in the *debugger* directory that there is a
configure.ac and not configure.in. The debugger directory could be
split off as a separate package if/when bash changes are merged into
bash.

 > 
 > Pending:
 > * Trying to install empty file (or directory). Creates an install.gz file

I don't understand this is about. Why is it desired to install a empty
file or directory?

 > Won't adress in this fix:
 > * manpage names same as executables ( if executable names are transformed )

It doesn't seem that hard to address if there other packages can deal
with. I wonder how other packages address this?

 > * builtins and rbash plain text files is not generated correctly

Do you mean plain text help files the builtins are generated (correctly)
now and in the future they won't be?

 > 
 > Done but not commited yet:
 > * configurable package name. (Environment variable)
 > * configurable executable names. (Standard automake/autoconf way with sed 
 > scripts)

Great. 

 > * bootstrap.sh executed auto... commands in odd order ( Always gave me an 
 > error on first run )

I think this script I had to write when I put this in CVS. There is also autogen.sh which
runs bootstrap.sh + configure. I've never understood the auto system well enough, so I would
not be surprised if it has problems/bugs. Anything you can do to improve it is welcome.

 > * script files now installs in pkgdatadir. Note: Not everybody agrees on this 
 > interpretation of FHS although i belive it make sense ( and obviously also 
 > those who make emacs and perl )

I don't understand what FHS stands for. As long as things are self
consistent and those folks who have strong opinions on such matters
can configure this (and I don't think I'm in that category), then I
don't think there should be a problem. 

 > * No more hardcoded paths in script-files. As a consequence dbg-main.inc is to 
 > be replaced with dbg-main.inc.in
 > * A location for bashdb specific macros (acinclude.m4)

Again all good. 

Thanks for taking this mess on. 

[Bashdb-devel] Status update: Auto... related changes.

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

A short status update on auto... changes:

I'll post a patch as soon as possible, planned to do it today but stumbled 
upon a few more bugs. And it'll probably take me at least a few day to work 
it out.

Currently working on:
* Remove deprecated autoconf and automake constructs.

Pending:
* Trying to install empty file (or directory). Creates an install.gz file

Won't adress in this fix:
* manpage names same as executables ( if executable names are transformed )
* builtins and rbash plain text files is not generated correctly

Done but not commited yet:
* configurable package name. (Environment variable)
* configurable executable names. (Standard automake/autoconf way with sed 
scripts)
* bootstrap.sh executed auto... commands in odd order ( Always gave me an 
error on first run )
* script files now installs in pkgdatadir. Note: Not everybody agrees on this 
interpretation of FHS although i belive it make sense ( and obviously also 
those who make emacs and perl )
* No more hardcoded paths in script-files. As a consequence dbg-main.inc is to 
be replaced with dbg-main.inc.in
* A location for bashdb specific macros (acinclude.m4)

/Mikael

Re: GDFL vs GPL (Was Re: [Bashdb-devel] Upcoming changes for potential Debian release)

[James M. D. <mdu...@ya...>]

--- "R. Bernstein" <ro...@pa...> wrote:
> Matthias Klose writes:
>  > I actually proposed to relicense or dual license the docs. The
> latter
>  > would have the advantage, that it could be merged back to the bash
>  > docs which have the same license for the docs (GPL)
> 
> I've solicited the help of someone more competent at this than I. If
> there are no "Invariant Sections" then GDFL is the same as GPL. Does
> Debain have a problem with documents that are GDFL that don't have
> any
> invariant sections? 
> 
> The only invariant section I see is in the current bashdb reference
> manual is what I would call FSF boilerplate in the info
> documentation:
> 
>   Permission is granted to copy, distribute and/or modify this
> document
>   under the terms of the GNU Free Documentation License, Version 1.1
> or
>   any later version published by the Free Software Foundation; with
> the
>   Invariant Sections being ``Free Software'' and ``Free Software
> Needs
>   Free Documentation'', with the Front-Cover Texts being ``A GNU
>   Manual,'' and with the Back-Cover Texts as in (a) below.
> 
>   (a) The Free Software Foundation's Back-Cover Text is: ``You have
>   freedom to copy and modify this GNU Manual, like GNU software. 
> Copies
>   published by the Free Software Foundation raise funds for GNU
>   development.''
> 
> I'm trying to understand the objection is to this. There is a saying
> that "the freedom for you to wave your fist ends at the tip of my
> nose". With freedom comes responsibility. People are free and welcome
> to make technical improvements or even make it technically
> worse. However the philosophical stuff they are not free to change at
> present.


Yes. What is the problem here. Just view the invariant sections as
non-content. What if the document has %0 content? delete it.
make a policy that it must contain %75 content or not be allowed in the
distro.


the FSEDu project puts all of its wiki under the GDFL.

mike

=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Re: GDFL vs GPL (Was Re: [Bashdb-devel] Upcoming changes for potential Debian release)

[Matthias K. <do...@cs...>]

R. Bernstein writes:
> Matthias Klose writes:
>  > I actually proposed to relicense or dual license the docs. The latter
>  > would have the advantage, that it could be merged back to the bash
>  > docs which have the same license for the docs (GPL)
> 
> I've solicited the help of someone more competent at this than I. If
> there are no "Invariant Sections" then GDFL is the same as GPL. Does
> Debain have a problem with documents that are GDFL that don't have any
> invariant sections? 

yes, this is certainly the important point. some Debian people even
are unhappy wit the cover texts, but there's not yet a final
statement/policy.

GDFL vs GPL (Was Re: [Bashdb-devel] Upcoming changes for potential Debian release)

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

Matthias Klose writes:
 > I actually proposed to relicense or dual license the docs. The latter
 > would have the advantage, that it could be merged back to the bash
 > docs which have the same license for the docs (GPL)

I've solicited the help of someone more competent at this than I. If
there are no "Invariant Sections" then GDFL is the same as GPL. Does
Debain have a problem with documents that are GDFL that don't have any
invariant sections? 

The only invariant section I see is in the current bashdb reference
manual is what I would call FSF boilerplate in the info documentation:

  Permission is granted to copy, distribute and/or modify this document
  under the terms of the GNU Free Documentation License, Version 1.1 or
  any later version published by the Free Software Foundation; with the
  Invariant Sections being ``Free Software'' and ``Free Software Needs
  Free Documentation'', with the Front-Cover Texts being ``A GNU
  Manual,'' and with the Back-Cover Texts as in (a) below.

  (a) The Free Software Foundation's Back-Cover Text is: ``You have
  freedom to copy and modify this GNU Manual, like GNU software.  Copies
  published by the Free Software Foundation raise funds for GNU
  development.''

I'm trying to understand the objection is to this. There is a saying
that "the freedom for you to wave your fist ends at the tip of my
nose". With freedom comes responsibility. People are free and welcome
to make technical improvements or even make it technically
worse. However the philosophical stuff they are not free to change at
present.

Re: [Bashdb-devel] Upcoming changes for potential Debian release

[Matthias K. <do...@cs...>]

Mikael Andersson writes:
> > Matthias Klose also mentioned a possible deficiency in using the GNU
> > Free Documentation License (GFDL) for the bashdb manual this link
> >   http://home.twcny.rr.com/nerode/neroden/fdl.html
> > suggests that GPL is a better thing to use. Anyone know anything about
> > this?
> 
> <warning licensing comments and opinions ahead, DON'T PANIC!>
[thanks for your informative followup]

I actually proposed to relicense or dual license the docs. The latter
would have the advantage, that it could be merged back to the bash
docs which have the same license for the docs (GPL)

> > Finally, the question has arisen here and elsewhere as to what to call
> > the bash-2.05b executable that has been modified to improve error
> > reporting and debugging support (and also now timestamps the history
> > file which I think essential if you use bash as your root shell).  I
> > suggested bash+dbg; Matthias Klose has chosen the name bash-bashdb
> > since there already is a bash-minimal and a bash-static in
> > Debian. Going in a completely different direction, some friends have
> > been urging me to call the project "rebash." I think this is a catchy
> > name.  After all, "bash" is the "Bourne-Again Shell" so this is the
> > "ReBourne-Again shell." Also sounds like "Rebok" and just the name
> > "rebash" is appropriate for the same reason that "bash" was a bash of
> > "sh".

> I think bash+dbg is good with the current scope of the project, but
> rebash if we intend on reviving bash development a bit when we're at
> it :).

ok, I'll name it bash+dbg as well.

	Matthias

Re: [Bashdb-devel] Upcoming changes for potential Debian release

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

Some part of bashdb code has been merged into bash already?
Not yet?
Should I push again?

Masatake

Re: [Bashdb-devel] Upcoming changes for potential Debian release

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

Mikael Andersson asks:
 > I'm curious about the $ac_prefix variable that is beeing used. I can't find 
 > where it's defined or what it's supposed to mean.

I looked again too. Generally things that start $ac_ are autoconf
things. $ac_default_prefix was the default prefix used and probably
the problem was that if you set this to something else that wasn't respected.
I think the right variable then is $prefix (without the ac_).

and opines: 
 > <warning licensing comments and opinions ahead, DON'T PANIC!>

No panic, just the contrary. I appreciate you taking the time give a
thoughtful reply. I need to study what you've written and the issue
itself in more detail. I am also seeking the advise and wisdom of
those I respect in such matters.

 > I think bash+dbg is good with the current scope of the project, but rebash if 
 > we intend on reviving bash development a bit when we're at it :).

Bash development has always been rather slow because basically it's
been a closed system and as far as I can tell there's only one person
who dictates what goes in. Contrast this with say Perl developement
where you have maybe 10 or so "core" developers and 100s of module
developers. (And Perl is not atypical, the GNU/Linux kernel, gcc,
apache, or php are about the same.)

I started this project in the hope that others would get interested in
aspects that others feel need improving and could
contribute. Initially the thing that irked me the most was the lack of
debugging support which has been in Perl over a decade, and a lack of
timestamped history which I've been using a decade or more in tcsh.

In this respect, I would prefer "rebash". 

Re: [Bashdb-devel] Upcoming changes for potential Debian release

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

On Monday 11 August 2003 12.59, R. Bernstein wrote:
> Folks:
>
> At my urging, Matthias Klose, a Debian bash maintainer, has been
> looking at making this project industrial-strength enough for Debian
> inclusion. As a result, there has been a flurry of activity since the
> 0.41 release. The presumption is that a number of configuration and
> build bugs have recently been (or will be) fixed.
>
> A stumbling block that most people run into in trying to make a
> distribution release is that the this project doesn't build outside of
> the source tree. A number of changes in CVS are related to that.
>

I'm curious about the $ac_prefix variable that is beeing used. I can't find 
where it's defined or what it's supposed to mean.

> Another common comment is that the debugger include files (which I had
> thought of as analogous to a script library) currently install
> somewhere under "lib", whereas I'm told a more natural convention is
> to install under "share."  The current configurability of making this
> change is lacking at least in the bashdb script if not also the bash
> program and probably inside the configuration system as well.
>
> Mikael Andersson who expressed a desire to make gentoo distribution,
> noted, and I believe he's done some work towards addressing this in
> the code.

This is correct. I'm almost done with this now i belive, although there are a 
few things with Matthias changes i don't fully understand ( the origin of 
ac_prefix beeing the 'showstopper' for me ).

>
> Something else I guess I will address sooner than later is the lack of
> a manual page. Right now my plan is to write one in perlpod (rather
> than troff). A suggestion was use texi2pod and then pod2man, but I'd
> rather just write in perlpod and skip the texi2pod step. If someone
> has another tool or suggestion, let me know.
>
> Matthias Klose also mentioned a possible deficiency in using the GNU
> Free Documentation License (GFDL) for the bashdb manual this link
>   http://home.twcny.rr.com/nerode/neroden/fdl.html
> suggests that GPL is a better thing to use. Anyone know anything about
> this?

<warning licensing comments and opinions ahead, DON'T PANIC!>
There could be issues with this, albeit the problem of being unable to extract 
text between source and documentation seems vague since quoting of text in 
3rd-party manuals must have been done for years and being established as fair 
use. It can't be automated though, but i don't know if thats' an important 
issue.  The translation requirements are a bit extreme though. If someone 
purposefully retranslates a invariant section erroneously i don't think 
they'll care to include the english version even if the license mandates it. 
And for all other situations having english text in a translated document is 
strictly a nuisance.

The issues about a refernce-card having to carry it's own copyright could 
actually be considered to be the case with GPL-2 also. Since any modified 
copy (sect 2 in GPL) is governed by section 1 which demands that "... in any 
medium, provided that you conspicuously and appropriately publish on each 
copy an appropriate copyright notice and disclaimer of warranty; keep intact 
all the notices that refer to this License and to the absence of any 
warranty; and give any other recipients of the Program a copy of this License
along with the Program."
And as a reference card would be a modification ( a subset, not the entire 
program ) it too should have to carry it's own license under the GPL. So if 
you plan to make truckloads of reference-cards to distribute to the world i 
suggest you include a licence flyer GFDL or GPL alike ;)
The invariant section isn't that controversial in my view. If the document 
creator has any non-technical (ie no on the topic), maybe ideological 
standpoints that he/she feel important to attach to the documentation. Other 
people shouldn't be allowed to remove/alter these sections. This is one of 
the reasons why the GPL also states that all changes must be prominently 
marked as such in the files.

My personal view is that either GPL or GFDL is workable but as noted by fsf 
(http://www.gnu.org/licenses/fdl.html#SEC4)
"If your document contains nontrivial examples of program code, we recommend 
releasing these examples in parallel under your choice of free software 
license, such as the GNU General Public License, to permit their use in free 
software.".

The difference with GFDL (from GPL) is that:
"The GNU Free Documentation License is a form of copyleft intended for use on 
a manual, textbook or other document to assure everyone the effective freedom 
to copy and redistribute it, with or without modifications, either 
commercially or noncommercially."
That is: It's intended for both non-commercial _and_ commercial use and thus 
have a slightly different scope.

If you want people to be able to publish a commercial book based on bashdb 
manuals you could probably release it under GPL + GFPL, selectable at the 
users discretion. This would (IANAL) lead to that all non-commercial 
publisher/distributors would be free to choose GPL or GFPL but that a 
commercial publisher would be forced to use GFPL and as such preserve all 
invariant sections. Effectively it should allow a joint development of a 
document, including it's invariant sections (as we choose GPL when doing whis 
work). If you choose this i belive you should get a second opinion on it, 
either from lic...@op... or from anyone more familiar with 
licensing than me. Albeit GFDL isn't on their list of approved licenses it's 
not unlikely that they can give a more clearcut reasoning as why to select 
either license than i can.

>
> Finally, the question has arisen here and elsewhere as to what to call
> the bash-2.05b executable that has been modified to improve error
> reporting and debugging support (and also now timestamps the history
> file which I think essential if you use bash as your root shell).  I
> suggested bash+dbg; Matthias Klose has chosen the name bash-bashdb
> since there already is a bash-minimal and a bash-static in
> Debian. Going in a completely different direction, some friends have
> been urging me to call the project "rebash." I think this is a catchy
> name.  After all, "bash" is the "Bourne-Again Shell" so this is the
> "ReBourne-Again shell." Also sounds like "Rebok" and just the name
> "rebash" is appropriate for the same reason that "bash" was a bash of
> "sh".

I think bash+dbg is good with the current scope of the project, but rebash if 
we intend on reviving bash development a bit when we're at it :).

>
> As always, I solicit comments and thoughts of any of the matters
> above.
>
> Thanks.
>
/Mikael

[Bashdb-devel] Upcoming changes for potential Debian release

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

Folks: 

At my urging, Matthias Klose, a Debian bash maintainer, has been
looking at making this project industrial-strength enough for Debian
inclusion. As a result, there has been a flurry of activity since the
0.41 release. The presumption is that a number of configuration and
build bugs have recently been (or will be) fixed.

A stumbling block that most people run into in trying to make a
distribution release is that the this project doesn't build outside of
the source tree. A number of changes in CVS are related to that.

Another common comment is that the debugger include files (which I had
thought of as analogous to a script library) currently install
somewhere under "lib", whereas I'm told a more natural convention is
to install under "share."  The current configurability of making this
change is lacking at least in the bashdb script if not also the bash
program and probably inside the configuration system as well.

Mikael Andersson who expressed a desire to make gentoo distribution,
noted, and I believe he's done some work towards addressing this in
the code.

Something else I guess I will address sooner than later is the lack of
a manual page. Right now my plan is to write one in perlpod (rather
than troff). A suggestion was use texi2pod and then pod2man, but I'd
rather just write in perlpod and skip the texi2pod step. If someone
has another tool or suggestion, let me know.

Matthias Klose also mentioned a possible deficiency in using the GNU
Free Documentation License (GFDL) for the bashdb manual this link
  http://home.twcny.rr.com/nerode/neroden/fdl.html
suggests that GPL is a better thing to use. Anyone know anything about
this?

Finally, the question has arisen here and elsewhere as to what to call
the bash-2.05b executable that has been modified to improve error
reporting and debugging support (and also now timestamps the history
file which I think essential if you use bash as your root shell).  I
suggested bash+dbg; Matthias Klose has chosen the name bash-bashdb
since there already is a bash-minimal and a bash-static in
Debian. Going in a completely different direction, some friends have
been urging me to call the project "rebash." I think this is a catchy
name.  After all, "bash" is the "Bourne-Again Shell" so this is the
"ReBourne-Again shell." Also sounds like "Rebok" and just the name
"rebash" is appropriate for the same reason that "bash" was a bash of
"sh". 

As always, I solicit comments and thoughts of any of the matters
above.

Thanks.

[Bashdb-devel] Bug fix, release 0.41 this weekend?

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

The bug recently reported by Mikael Andersson has been fixed.  The
line number in multi-line assignments had been the line number where
the assignment ends, not the beginning. Thus assignments with
backticked subshells gave the wrong line number.

Folks are encouraged to test out what's in CVS. Sometime over the
weekend I plan to make a release. Consult debugger/NEWS file for recent
changes.

If there's a problem let me know. 

Thanks. 

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

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

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

Many thanks. Will look at later.

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

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

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

Probably, will double check.

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

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

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

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

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

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

Good. 

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

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

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

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

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

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

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

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

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

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

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

On Wednesday 06 August 2003 05.30, you wrote:
> I applied the patch and ran the debugger regression tests via:
> make check
>

*Bangs head on desk*, not literally though... 
Messed up a bit when switching to work with cvs. (redid some changes manually 
and forgot to test) it should be 'set' instead of shopt... An updated patch 
is attached (vcd-CVS-002.patch.

> The failure that bothers me is this one:
>
> --- /tmp/misc.check 2003-08-05 23:22:23.000000000 -0400
> +++ ./misc.right    2003-08-02 19:11:44.000000000 -0400
> @@ -550,9 +550,3 @@
>  *** Testing prompt and set tty...
>  bashdb's prompt is:
>         "bashdb${_Dbg_greater}$_Dbg_hi${_Dbg_less}$_Dbg_space".
> -noglob			off
> -../dbg-cmds.inc: line 556: shopt: +o: invalid shell option name
> -../dbg-cmds.inc: line 556: shopt: noglob: invalid shell option name
> -noglob		  off
> -../dbg-cmds.inc: line 556: shopt: +o: invalid shell option name
> -../dbg-cmds.inc: line 556: shopt: noglob: invalid shell option name
> --- /tmp/misc-output.check  2003-08-05 23:22:24.000000000 -0400
> +++ ./misc-output.right	    2003-08-02 15:37:35.000000000 -0400
> @@ -19,5 +19,3 @@
>   41:
>  dq_args="dq*"
>  dq_cmd="V"
> -dq_args="variables dq*"
> -dq_cmd="info"
> FAIL: run-misc
>
> Alas, I don't have time to investigate this right now.

As far as i understand the other tests was ok (some linenumbers were wrong
for me thou ) and that:
dq_args="variables dq*"
dq_cmd="info"
Should be the proper output from infor variables dq* if i understand it 
correctly. Attaching a patch whis updates tests with new line-numbers
and info variables output ( test-CVS-001.patch )

Also cvs seems to lack check_common.in in tests directory. I copied mine from
the v0.40 distribution.


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

Mostly adding som substitution variables so that you
can move things around freely with --prefix etc. Also moved .inc files to 
/usr/share/$package as this should be the proper location as they are arch 
independant. Not all packages do like this, but perl and emacs seems to do it 
that way. And FHS [1] seems to agree also.
Further i have enabled --program-transform-* (AC_ARG_PROGRAM macro) and added
an ALT_PACKAGE_NAME variable to be able to decide on what package name to use 
when installing.

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

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

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


/Mikael

[1] http://www.pathname.com/fhs/2.2

[Bashdb-devel] Multiline command substitution in subshell bug (Mikael Andersson)

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

Mikael Andersson reports:

 > The shell-script below gives the following output in bashdb. 

You've found a slight bug in bash 2.05b. I've found several like this
in the past.  When I try the following on an unmodified bash 2.05b

#!/bin/bash
trap 'echo $LINENO' DEBUG
s=`(
         echo This is
         echo not visible
         echo while debugging
)`
echo $s #This line should not be displayed until later
# Didn't expect to see me
# And not me either
# Or me either.

The output I get is:
7
8
This is not visible while debugging

I think I have seen this kind of behavior before in other
contexts. What I think is going on is that the parser has to scan to
the to the end of the `( ... )` initially. There is a global variable
inside the parser for the current line number -- that's line 6 in your
example (7 in mine since I added the trap statement). It is not reset
when going into the subshell echo's. After each echo this global
counter is incremented. Here, fortunately, 6+1, and 6+1+1 appear in
comments so you know it's totally bogus. I write "fortunately" because
if it had been real code it would have been extremely confusing.

In other places when I saw I was going inside a subshell, I had to
save an restore this global line counter. I looked in CVS for what I
recall running into with substitutions. I can't find it right now, but
a similar example to give you an idea is between version 1.13 and 1.14
of execute_cmd.c where you have to do the same thing with say a case
statement. The diff you can look at in CVS such as:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/bashdb/bashdb/execute_cmd.c.diff?r1=1.13&r2=1.14&sortby=date

If this guess is correct, we need to find the place this is getting
run and do something similar to what's done with working
substitutions.

Again, alas I don't have much time to investigate further.

[Bashdb-devel] Bugfix patch for V cmd.

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

I applied the patch and ran the debugger regression tests via:
make check

The failure that bothers me is this one:

--- /tmp/misc.check 2003-08-05 23:22:23.000000000 -0400
+++ ./misc.right    2003-08-02 19:11:44.000000000 -0400
@@ -550,9 +550,3 @@
 *** Testing prompt and set tty...
 bashdb's prompt is:
        "bashdb${_Dbg_greater}$_Dbg_hi${_Dbg_less}$_Dbg_space".
-noglob			off
-../dbg-cmds.inc: line 556: shopt: +o: invalid shell option name
-../dbg-cmds.inc: line 556: shopt: noglob: invalid shell option name
-noglob		  off
-../dbg-cmds.inc: line 556: shopt: +o: invalid shell option name
-../dbg-cmds.inc: line 556: shopt: noglob: invalid shell option name
--- /tmp/misc-output.check  2003-08-05 23:22:24.000000000 -0400
+++ ./misc-output.right	    2003-08-02 15:37:35.000000000 -0400
@@ -19,5 +19,3 @@
  41:   
 dq_args="dq*"
 dq_cmd="V"
-dq_args="variables dq*"
-dq_cmd="info"
FAIL: run-misc

Alas, I don't have time to investigate this right now.

[Bashdb-devel] Multiline command substitution in subshell bug

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

It's nothing serious but a bit confusing. The shell-script below gives the 
following output in bashdb. 
A clarification: my bash executable is renamed to bashdb and the bashdb script 
to bash-debugger.


------- output
snikkt> -bashdb --debugger multiline.sh
(multiline.sh:6):
6:      )`
bashdb<0> s
(multiline.sh:7):
7:      echo $s #This line should not be displayed until later
bashdb<((1))> s
(multiline.sh:8):
8:      #Didn't expect to see me ?
bashdb<((2))> s
(multiline.sh:9):
9:      #And not me either ?
bashdb<((3))> s
(multiline.sh:7):
7:      echo $s #This line should not be displayed until later
bashdb<4> s
This is not visible while debugging
(multiline.sh:10):
10:
bashdb<5> s
Debugged program terminated normally. Use q to quit or R to restart.
bashdb<6> q

----------- script
#!/bin/bash
s=`(
        echo This is
        echo not visible
        echo while debugging
)`
echo $s #This line should not be displayed until later
#Didn't expect to see me ?
#And not me either ?

[Bashdb-devel] Bugfix patch for V cmd.

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

Small patch (against pserver sourceforge cvs, 24 hour delay still i belive) 
that resolves a few issues i've found.

The first problem surfaced a bug in bash leading to a segfault on line 655 in 
glob.c. Haven't really looked in to it much. But trying to expand a 87K 
configure script obviously wasn't to bash's liking :)
I'm not sure if noglob a good way or if simply adding some quoting would be 
better.

The second problem was that i attempted a brace expansion on _Dbg_source ... 
with predictable result in runtime ... _slow_


/Mikael

Re: [Bashdb-devel] Re: 'V' command augmentation (Mikael Andersson)

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

On Saturday 02 August 2003 22.25, R. Bernstein wrote:
>  > Here is a small patch (attached) that adds wildcard matching for the V
>  > command. Also it fixes what i feel is a bug with V in that it also
>  > reports all functions in the scope.
>
> Many thanks. It's encouraging when folks submit patches and
> improvements like this. And improving V was on the TODO list!
>
> The patch has now been applied to CVS with some small changes;
> changes to update help and the documentation have been made.
>
>  > I'm not a seasoned bash scripter so there are probably some things that
>  > can be fixed. But for now it seems to be quite robust.
>
> I don't consider myself a seasoned bash scripter either. I know I'm
> not suppsed to ask, but well what does this do?
>
>   # Uhmn, well, yes... don't ask !
>   _Dbg_cmd=`echo -e _Dbg_var=\\${_Dbg_var//\\\n/\\\\\\\\\\\\\\\\\\\\\\\\n}`

Short answer: The wrong thing :)

I really wanted to do: _Dbg_var=${_Dbg_var//
/\\n}
And tried to insert a \n escape sequence for the \n first, couldn't get it to 
work. But then i tried doing eval to get a  \n there and that would have 
worked if i had used the right number of '\' on the left side of the 
expression. And after that i found out the obvious way: Put the linebreak
right there in the script :)


>
> I notice that in the output embedded blanks in a variable string comes out
> \n.
>
> Again, thanks
>
>
/Mikael

[Bashdb-devel] Re: 'V' command augmentation (Mikael Andersson)

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

 > Here is a small patch (attached) that adds wildcard matching for the V 
 > command. Also it fixes what i feel is a bug with V in that it also reports 
 > all functions in the scope.

Many thanks. It's encouraging when folks submit patches and
improvements like this. And improving V was on the TODO list!

The patch has now been applied to CVS with some small changes;
changes to update help and the documentation have been made.

 > I'm not a seasoned bash scripter so there are probably some things that can
 > be fixed. But for now it seems to be quite robust. 

I don't consider myself a seasoned bash scripter either. I know I'm
not suppsed to ask, but well what does this do? 
  
  # Uhmn, well, yes... don't ask !
  _Dbg_cmd=`echo -e _Dbg_var=\\${_Dbg_var//\\\n/\\\\\\\\\\\\\\\\\\\\\\\\n}`

I notice that in the output embedded blanks in a variable string comes out
\n. 

Again, thanks

[Bashdb-devel] Ooops ...

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

Forgot to mention the patch is against bash-2.05b-debugger-0.40 ....

/Mikael Andersson

[Bashdb-devel] 'V' command augmentation

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

Here is a small patch (attached) that adds wildcard matching for the V 
command. Also it fixes what i feel is a bug with V in that it also reports 
all functions in the scope.

I'm not a seasoned bash scripter so there are probably  some things that can
be fixed. But for now it seems to be quite robust. 

A few intersting points to consider.
I chose to call  declare -p <var> for each var to be able to weed out any 
false positives the previous functions could have let through. For example 
the function:
strange() {
	echo "This is an
}
odd=but still legal
construct"
}
could fool the code unless declare -p was called on the name odd. declare -p 
will only put a closing bracket at the far right if it's part of a string. 
And thus the function detection will work well for all cases except those but 
they should be quite rare and if they occur the declare -p disqualifies them.
You could get a variable output several times in extreme cases. But i'm not
sure those few cases warrant adding some code to ensure each variable is 
printed only once since it will slow down the variable listing additionally.


/regards Mikael Andersson

[Bashdb-devel] Timestamps to history added

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

I've added timestamps to the history lists. 

I haven't made a release for this yet as this is all a bit
new. However you can compile this from CVS sources: 

  cvs -d:pserver:ano...@cv...:/cvsroot/bashdb login
  cvs -z3 -d:pserver:ano...@cv...:/cvsroot/bashdb co bashdb

The format of the timestamp shown in a command history is controlled
by the $HISTTIMEFORMAT environment variable via strftime; the default
value is '%a %T ' (abbreviated weekday name and 24-hour time with
seconds). Note the trailing blank. See strftime(3) for a list of time
conversion specifiers.

[Bashdb-devel] Time stamp history added to bash

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

I've added a timestamp in the history file. This was something on my
to-do list for a while. (This can be useful helping to figure out when
changes have been made such as if your computer has been hacked into.)

I haven't made a release for this yet as this is all a bit
new. However you can compile this from CVS sources: 

  cvs -d:pserver:ano...@cv...:/cvsroot/bashdb login
  cvs -z3 -d:pserver:ano...@cv...:/cvsroot/bashdb co bashdb

The format of the timestamp shown in a command history is controlled
by the $HISTTIMEFORMAT environment variable via strftime; the default
value is '%a %T ' (abbreviated weekday name and 24-hour time with
seconds). Note the trailing blank. See strftime(3) for a list of time
conversion specifiers.