bashdb-devel — Developer's discussion mailing list

[Bashdb-devel] Bash debugger patches integrated

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

Chet Ramey writes:

 > The integration of your patches to the mainline bash code is complete.  The
 > result passes all of the tests added to the bash suite, with a single
 > exception.  The primary difference is:

Many thanks for integrating the debugging support patches into the
mainline bash code. I look forward to the day when the sourceforge
copy can be removed! 

 >   The primary difference is:
 > 
 > 1.  The RETURN trap is executed whenever a script run with `.' or `source'
 >     finishes, not just when it calls `return'.

This is an improvement and an oversight or coding inexperience on my
part.

 > 
 > (This mirrors the behavior of shell functions.)

Great!

 > 
 > I have a couple of questions for discussion:
 > 
 > 1.  Why do scripts executed with `.' or `source' inherit the RETURN trap?
 >     Shell functions don't.
 > 
 > 2.  Why do command substitutions inherit the RETURN trap?
 > 

The code that implements this policy, I think, is this code in
execute_cmd.c:

  /* 
    Reset debug, error and return trap handlers. Set up to
    restore them on return.
  ....
  return_trap = TRAP_STRING(RETURN_TRAP);
  if (return_trap)
  ... 

versus this code in trap.c:

  /* Command substitution and other child processes don't inherit the
     debug or error traps. */
  if (!function_trace_mode)
    sigmodes[DEBUG_TRAP] &= ~SIG_TRAPPED;  

I envisioned the RETURN trap for two purposes. The first was to be able
to implement a gdb "finish" command. (Since gdb's "return" command
means something else, the name RETURN might be confusing here. I
really don't know).

Here, the RETURN trap I think should mimic behavior of "set -o
fntrace" (or variable function_trace_mode). That is, when one requests
the facility to debug into a function, with that should also get the
ability to catch an an exit out of that function. Assuming that
philosophy, the code cited above for execute_cmd.c is flawed and
should be:

  if (!function_trace_mode && return_trap)

The second intended use for the RETURN trap was precisely to catch a
subshell exit. 

Some background. A debugger such as this one lives inside the
environment of the debugged program. But one would like to think of
the global debugger state (such as breakpoints and debugger settings)
as being outside and independent of the debugged program. There is a
problem in passing state or part of the environment from a nested bash
session (SHLVL) or a subshell out to the parent environment.

In a sense I think of this as a general POSIX shell problem. There's
an "export" command to the child but no "export" to parent.

In order to simulate "export to parent", currently the bash debugger
has to do this in a very inefficient way. Any variable that is to be
exported to the parent is written to a journal file. The file may
contain the entire history of the changes of that variable.  For
example x=1; ... x=2; ... unset x; ... x=3.

In fact, the only relevant value is the last one set/unset. Every time
DEBUG trap is called, we have to source in that journal (if it
exists); the only time it can be removed and can stop recording
changes to the journal is when we get back to the initial SHLVL and
there are no subshells.

Okay. Sorry for the long-winded background. We finally get to that
second use and what a trap RETURN routine could do to help the
export-to-parent problem. 

It would be best to have two trap calls. Just before the exit,
variables marked "export" would be saved. And just after the exit, the
parent would read in those saved values. Even if you have only one
call it'd still save a bit of the unnecessary work.  If I had a return
in the child, rather than saving the entire history of value changes,
I might be able to just save the last value of the marked
variables. (I'd still have to have a list of marked variables). If I
had a RETURN trap call in the parent, I would only have to read in
this journal file once, even though the file might contain overwritten
variable assignments.

 > Thanks for all your hard work.

My pleasure and even more thanks thanks for all of *your* hard work!

[Bashdb-devel] Getting ddd to understand breakpoints better

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

I looked a bit more at the DDD code to set/remove breakpoints. 

With quite a bit of work for what seems like a simple thing, I've been
able to get this to show that little stop sign indicator icon to
appear. However more work will probably be needed to get this to
work flawlessly, and even more work to make it release ready.

Basically the easiest thing to do is to make the "show break" output
look more like gdb, and tell ddd to use gdb's breakpoint parsing when
debugging a bash script.  I think this a better approach than
rewriting the ddd's break parsing for bash which is what is attempted
(poorly) in the existing ddd patch.

In CVS I've committed the revised breakpoint output. That portion of
reference manual will have to get revised, and there will have to be
some changes to the ddd patches. 

Finally, I'll also have to add a mode to the debugger to always report
full file names and set up ddd to ensure that that mode is in effect.
(And this probably isn't everything.)

In short, this will probably happen. Probably not soon though.  But if
others or as others start working on this it might happen sooner. You
say you have little programming ability? Okay, well there's always 
revising the reference manual...

[Bashdb-devel] -L option and DDD stop sign (Was: How can I debug called scripts?)

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

 > 1. I'm able to use ddd with bashdb by typing:
 > 
 >      ddd --bash build.sh
 > 
 >      ...but when I type:
 > 
 >      bashdb -L .  build.sh
 > 
 >      ...alone, as from the bashdb manual example, I
 > get the following error:
 > 
 >      bashdb: cannot read debugger file ./dbg-main.inc.
 >      bashdb: Perhaps bashdb is installed incorrectly.
 > 
 >      ...however, dbg-main.inc does exist in the
 > following 2 directories:
 > 
 > /home/rick/programs/bash-2.05b-debugger-0.36/debugger/dbg-main.inc
 > /usr/local/lib/bashdb/dbg-main.inc
 > 
 >  (Note: the first directory is the one in which I did
 > the build.) The file access attributes are:  -rw-r-r--
 > 1 root  root  for the file in /usr/local/lib/bashdb. I
 > executed the "make" steps as a regular user, and
 > switched to "su" for the "make install".

You don't understand the meaning of -L option. Perhaps the bashdb
manual wasn't clear, so I've expanded that section which is in CVS and
in HTML online. The relevant portions now read:

2.1.1. Command-line options for bashdb script 
  ...

  -L directory Set directory where debugger files reside to
  directory. The default location is ../lib/bashdb relative to the place
  that the bashdb script is located. For example if bashdb is located in
  /usr/local/bin/bashdb, the default library location will be
  /usr/local/lib/bashdb which may or may not exist. If it doesn't you'll
  get an error when you run bashdb. Only if the default location is
  incorrect, should you need to use the -L option.


1.1 A Sample BASH Debugger Session
  ...

  The command invocation uses the option "-L ." Here we assume that the
  bashdb script and the debugger files are in the same location. If you
  are running from the source code, this will be the case. However if
  bashdb has been installed this probably won't be true and here you
  probably don't need to use "-L ." Instead you would type simply bashdb
  fact.sh.

 > 
 > 2.  ddd breakpoint problem.
 > 
 > I am able to set a breakpoint in my script in ddd, but
 > the little "Stop Sign" is not displayed in the source
 > panel. The only way I can view breakpoints is to
 > select the menu item Source/Breakpoints...  Minor
 > problem, but still a bit bothersome.

Sorry, I don't know to change ddd so that it would handle this. You or
anyone else following this is welcome to suggest a change (or better
patches) to either the ddd source or the bashdb source.

Bash is not the only language that doesn't display a stop sign. I
tried with Perl and don't see it there either. 

Another way to view breakpoints is to type "L" or "show break" (the
former being the Perl debugger's corresponding command, and the latter
being gdb's corresponding command).

Re: [Bashdb-devel] Re: How can I debug called scripts? (Rick Horowitz)

[Rick H. <ric...@ya...>]

Hi Rocky,

Thanks for your help. I got the "deb" command working
from ddd and figured out how to display the
subscript's source while debugging -- very cool. I
have a couple of other questions though, and would
greatly appreciate some help if you can.

1. I'm able to use ddd with bashdb by typing:

     ddd --bash build.sh

     ...but when I type:

     bashdb -L .  build.sh

     ...alone, as from the bashdb manual example, I
get the following error:

     bashdb: cannot read debugger file ./dbg-main.inc.
     bashdb: Perhaps bashdb is installed incorrectly.

     ...however, dbg-main.inc does exist in the
following 2 directories:

/home/rick/programs/bash-2.05b-debugger-0.36/debugger/dbg-main.inc
/usr/local/lib/bashdb/dbg-main.inc

 (Note: the first directory is the one in which I did
the build.) The file access attributes are:  -rw-r-r--
1 root  root  for the file in /usr/local/lib/bashdb. I
executed the "make" steps as a regular user, and
switched to "su" for the "make install".

2.  ddd breakpoint problem.

I am able to set a breakpoint in my script in ddd, but
the little "Stop Sign" is not displayed in the source
panel. The only way I can view breakpoints is to
select the menu item Source/Breakpoints...  Minor
problem, but still a bit bothersome.

Thanks again for your help.

Rick

--- "R. Bernstein" <ro...@pa...> wrote:
> bas...@li... writes:
>  > Is there a way to continue debugging into a
> secondary
>  > shell script that is called by the main script?
> When I
>  > tried debugging the main script, I was able to
>  > single-step through the script (using DDD with
> bashdb)
>  > - worked great. But the script calls another
> script
>  > and bashdb simply ran that script. Is there a way
> to
>  > cause the second script to also run in the
> debugger?
> 
> You can do this with the "debug" debugger command: 
> 
>  deb [script]    Set up [script] for debugging. If
> no script is given, take
>                  the script name from the command to
> be executed.
>                  Long command name: debug.
> 
> You won't find a button for this in ddd -- probably
> the only other
> place where it might make sense is for Perl. When
> you debug into or
> out of a script in ddd, the display I think is
> messed up for a line. I
> don't know of a way to force ddd to refresh the
> display. As far as I
> can tell ddd development has been dead for 2 years.
> 
> If "debug" is something you want to create a custom
> button for, you
> can do so via the menus:
> 
>   Commands
>     Edit Buttons
>       uncheck enable supported buttons only
>       in text box add the word "debug".
> 
> - - - 
> 
> By the way, in testing the above I tried debugging
> this this on a
> script which contained the "~" character. The
> current bashdb can't
> handle this but I've just changed the CVS version to
> fix this. If
> associative arrays are added to bash or this is
> ported to ksh, this
> kind of adding funny characters won't be a problem
> since untranslated
> filenames could used as indexes.
> 
> 
>
-------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc.
> Develop an edge.
> The most comprehensive and flexible code editor you
> can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more.
> FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> Bashdb-devel mailing list
> Bas...@li...
>
https://lists.sourceforge.net/lists/listinfo/bashdb-devel


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

[Bashdb-devel] Re: How can I debug called scripts? (Rick Horowitz)

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

bas...@li... writes:
 > Is there a way to continue debugging into a secondary
 > shell script that is called by the main script? When I
 > tried debugging the main script, I was able to
 > single-step through the script (using DDD with bashdb)
 > - worked great. But the script calls another script
 > and bashdb simply ran that script. Is there a way to
 > cause the second script to also run in the debugger?

You can do this with the "debug" debugger command: 

 deb [script]    Set up [script] for debugging. If no script is given, take
                 the script name from the command to be executed.
                 Long command name: debug.

You won't find a button for this in ddd -- probably the only other
place where it might make sense is for Perl. When you debug into or
out of a script in ddd, the display I think is messed up for a line. I
don't know of a way to force ddd to refresh the display. As far as I
can tell ddd development has been dead for 2 years.

If "debug" is something you want to create a custom button for, you
can do so via the menus:

  Commands
    Edit Buttons
      uncheck enable supported buttons only
      in text box add the word "debug".

- - - 

By the way, in testing the above I tried debugging this this on a
script which contained the "~" character. The current bashdb can't
handle this but I've just changed the CVS version to fix this. If
associative arrays are added to bash or this is ported to ksh, this
kind of adding funny characters won't be a problem since untranslated
filenames could used as indexes.

[Bashdb-devel] How can I debug called scripts?

[Rick H. <ric...@ya...>]

My thanks to the author(s) of the bash debugger. I'm
still in learning mode on Linux and having a debugger
for bash scripts is a godsend.

Is there a way to continue debugging into a secondary
shell script that is called by the main script? When I
tried debugging the main script, I was able to
single-step through the script (using DDD with bashdb)
- worked great. But the script calls another script
and bashdb simply ran that script. Is there a way to
cause the second script to also run in the debugger?

Thanks,

Rick

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

Re: [Bashdb-devel] introduction (James Michael DuPont)

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

Dude!
the cvs updates made a big difference!
now l and w are working! you rock!


--- "R. Bernstein" <ro...@pa...> wrote:
> James Michael DuPont writes:
>  > ok, let me put this in another way :
>  > Is there a way to pull out all of the knowledge that you have
> about a
>  > give bash routine into a file? or at least an interator function
> that
>  > visits each node uniquly?
> 
> Not that I know of. I don't see a need for this for debugger
> operations. If you have a need for this perhaps you could write
> something.

Yes, I will. The whole problem is that a debugger is really needed,
and sometimes we need to sift through a bash script with an editor
looking for things. Or want to extract data out of a given bash script,
then you need an intermediate form for the scripts.

For me it is very important to be able to extract the data out of the
build scripts, so Make uses bash all the time, and in order to be able
to extract the data out of a makefile, we also have to be able to
extract the data out of bash.

> 
>  > 
>  > I would like to have a routine that visits all the internal
> COMMAND and
>  > WORD objects, so that I can use that as input into the
> introspector.
>  > 
>  > The thing is that, I need to see :
>  > 1. what file a node (COMMAND,WORD) comes from.
>  > 2. what type it is (unary expr, function call, function decl)
>  > 3. what line number/column it came from
> 
> The bash "declare" statement can probably give some of this
> information. "declare -F" lists all functions. "declare -a" lists all
> arrays.  

that is really cool!! I never used this before!

>A variable name can be given too. See the bash documentation
> on declare. (Note: make sure you look at the doc that comes with the
> debugger since in fact declare has been extended to give line and
> source file information for functions; it does this because the
> debugger needs that info.)

Ok, I will read the docs :)

> 
> Names that pertain to the debugger start _bashdb. But alas there are
> stll a few debugger variables however that don't start _bashdb; they
> all do start with an underscore though.
> 
>  > 
>  > I use the redland rdf lib for storing this information, and to be
> able
>  > to gather all of that out of a ./configure file would be very
> usefull.
>  > 
>  > Also, we need to figure out the sources before they are
> interpolated
>  > and afterwards.
> 
> In bashdb, the command "info files" lists all the file the debugger
> knows about - has seen so far. You can look at the code to find the
> array that stores that. _bashdb_file2var as mentioned before does the
> name mangling. From that, if you need a reverse mapping you can
> probably create it.

cool! that is really good. Now i can figure out this silly automake
libtool stuff!
 
so, happy new years again, I gotta get ready to party!

mike

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

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [Bashdb-devel] introduction (James Michael DuPont)

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

James Michael DuPont writes:
 > ok, let me put this in another way :
 > Is there a way to pull out all of the knowledge that you have about a
 > give bash routine into a file? or at least an interator function that
 > visits each node uniquly?

Not that I know of. I don't see a need for this for debugger
operations. If you have a need for this perhaps you could write something.

 > 
 > I would like to have a routine that visits all the internal COMMAND and
 > WORD objects, so that I can use that as input into the introspector.
 > 
 > The thing is that, I need to see :
 > 1. what file a node (COMMAND,WORD) comes from.
 > 2. what type it is (unary expr, function call, function decl)
 > 3. what line number/column it came from

The bash "declare" statement can probably give some of this
information. "declare -F" lists all functions. "declare -a" lists all
arrays.  A variable name can be given too. See the bash documentation
on declare. (Note: make sure you look at the doc that comes with the
debugger since in fact declare has been extended to give line and
source file information for functions; it does this because the
debugger needs that info.)

Names that pertain to the debugger start _bashdb. But alas there are
stll a few debugger variables however that don't start _bashdb; they
all do start with an underscore though.

 > 
 > I use the redland rdf lib for storing this information, and to be able
 > to gather all of that out of a ./configure file would be very usefull.
 > 
 > Also, we need to figure out the sources before they are interpolated
 > and afterwards.

In bashdb, the command "info files" lists all the file the debugger
knows about - has seen so far. You can look at the code to find the
array that stores that. _bashdb_file2var as mentioned before does the
name mangling. From that, if you need a reverse mapping you can
probably create it.

Re: [Bashdb-devel] introduction (James Michael DuPont)

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

ok, let me put this in another way :
Is there a way to pull out all of the knowledge that you have about a
give bash routine into a file? or at least an interator function that
visits each node uniquly?

I would like to have a routine that visits all the internal COMMAND and
WORD objects, so that I can use that as input into the introspector.

The thing is that, I need to see :
1. what file a node (COMMAND,WORD) comes from.
2. what type it is (unary expr, function call, function decl)
3. what line number/column it came from

I use the redland rdf lib for storing this information, and to be able
to gather all of that out of a ./configure file would be very usefull.

Also, we need to figure out the sources before they are interpolated
and afterwards.

Happy new year,
mike
--- "R. Bernstein" <ro...@pa...> wrote:
> James Michael DuPont writes:
>  > On that note, do you have a way to -save-temps like gcc does, like
> +x
>  > so that you can capture the fully post-preprocessed files?
> 
> This debugger is a little bit different in design from earlier BASH
> or
> Korn shell debuggers such the one described in the O'Reilly books.
> While the others wrote a new script with debugger routines prepended,
> 
> this one doesn't. 
> 
> Or more bluntly: there is no preprocessed source. 
> 
> Here's why.  When one changes the source code you need to have a
> mapping from the things you've changed into the the original
> text. That is you are keeping a mapping of a set of lies around so
> you
> can keep the story you tell the users straight. The more you change
> the more lying going on. This lie mapping is overhead and adds
> complexity. As in normal life, the fewer lies I have to tell the
> easier things are.
> 
> (In truth, though there are things that the debugger does lie about.
> For
> example the call stack omits the debugger routines from the top of
> the stack when reporting the contents .)
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Bashdb-devel mailing list
> Bas...@li...
> https://lists.sourceforge.net/lists/listinfo/bashdb-devel


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

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [Bashdb-devel] introduction (James Michael DuPont)

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

James Michael DuPont writes:
 > On that note, do you have a way to -save-temps like gcc does, like +x
 > so that you can capture the fully post-preprocessed files?

This debugger is a little bit different in design from earlier BASH or
Korn shell debuggers such the one described in the O'Reilly books.
While the others wrote a new script with debugger routines prepended, 
this one doesn't. 

Or more bluntly: there is no preprocessed source. 

Here's why.  When one changes the source code you need to have a
mapping from the things you've changed into the the original
text. That is you are keeping a mapping of a set of lies around so you
can keep the story you tell the users straight. The more you change
the more lying going on. This lie mapping is overhead and adds
complexity. As in normal life, the fewer lies I have to tell the
easier things are.

(In truth, though there are things that the debugger does lie about. For
example the call stack omits the debugger routines from the top of
the stack when reporting the contents .)

Re: [Bashdb-devel] introduction (James Michael DuPont)

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

Thank you very much for the detailed explaination.
Yes, I should have included the file with me,
or even a -x copy of it.

On that note, do you have a way to -save-temps like gcc does, like +x
so that you can capture the fully post-preprocessed files?

I am cvs updating and will tell you how I fare.

it is funny, but i had a feeling that those long indentifiers were
created out of some hashing scheme, I encountered similar longs ids
using hashes in shell before, just concatinating the symbols into
one...

Happy new year!

mike
--- "R. Bernstein" <ro...@pa...> wrote:
> A guess is the problem is that you have a plus (or some other
> character that isn't usually part of a BASH identifier) in the
> filename.
> 
> +2D0M2D0D6Slibtool
> ^here
> 
> Some background. For the debugger, it is very useful to have a hash
> table data structure. Hash tables are not part of bash (yet). The way
> these are implemented is to convert what in Perl would be $file{key}
> into a single identifier "file_key" making use of BASH's hashed
> symbol
> table.
> 
> But in order to do this "key" can't have any non-identifer symbols,
> like "+", "/", "." and so on. So these must either be stripped or
> replaced. We in fact, replace them to make it easier to recontruct
> the
> original name. Right now I don't list all the weird symbols that
> might
> appear in a filename. In particular, I don't have "+" listed.
> 
> Doing a reverse translation of +2D0M2D0D6Slibtool the original
> filename with a path probably contained something like
> "+2.0-2-0.6/libtool", possibly with other stuff in front. If this is
> the case, then a simple fix is to make sure we tranlate the "+" in
> _bashdb_file2var.  That is, change this line 22 of bashdb-file.inc:
> 
>   local varname=`builtin echo $filename | tr '* .?/"[]-' 'ABDQSqLRM'`
> 
> into this:
> 
>   local varname=`builtin echo $filename | tr '+* .?/"[]-'
> 'PABDQSqLRM'`
> 
> Actually, I've already made the change in CVS. 
> 
> If that works, let me know. If not, it would be helpful to understand
> not just what the error message you encountered given below, but some
> short example giving *input* that you typed to get that output.
> Better, is a short test case that causes the debugger to fail.
> 
> Thanks.
> 
> 
> James Michael DuPont writes:
>  > 
>  > --- "R. Bernstein" <ro...@pa...> wrote:
>  > > Hi there, Ho there, 
>  > > 
>  > > Okay. Thanks for the information and looking into bashdb. If you
> have
>  > > questions, comments, or problems with bashdb let us know.
>  > > 
>  > I am running this on libtool 
>  > 
>  >  /usr/local/bin/../lib/bashdb/bashdb-list.inc: line 200: local:
>  > +2D0M2D0D6Slibtool: value too great for base (error token is
>  > "2D0M2D0D6Slibtool")
>  > /usr/local/bin/../lib/bashdb/bashdb-list.inc: line 200: local:
>  > +2D0M2D0D6Slibtool: value too great for base (error token is
>  > "2D0M2D0D6Slibtool")
>  > 
>  > # the line is 
>  >    local -i max_line=`_bashdb_get_assoc_scalar_entry "_maxline_"
>  > $filevar`
>  >     #   echo "debug: -- max_line: $max_line --"
>  > 
>  > bash -x  ../libtool --mode=link i586-mingw32msvc-gcc 
>  > -DGLIB_STATIC_COMPILATION  -mms-bitfields -Wall -D_REENTRANT
>  > -I/usr/local/win32/include  -I/usr/local/win32/include/glib-2.0/
>  > -mms-bitfields -L/usr/local/win32/lib -o test-gdk-pixbuf.exe 
>  > test-gdk-pixbuf.o libgdk_pixbuf-2.0.la -L/usr/local/win32/lib/
> -lgdi32
>  > -lgobject-2.0 -lgmodule-2.0  -lglib-2.0 -lintl -liconv 
>  > 
>  > It has something to do with the size of the identfiers,
>  > i will gdb it.
>  > 
>  > mike
>  > 
>  > =====
>  > James Michael DuPont
>  > http://introspector.sourceforge.net/
>  > 
>  > __________________________________________________
>  > Do you Yahoo!?
>  > Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
>  > http://mailplus.yahoo.com


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

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [Bashdb-devel] introduction (James Michael DuPont)

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

A guess is the problem is that you have a plus (or some other
character that isn't usually part of a BASH identifier) in the filename.

+2D0M2D0D6Slibtool
^here

Some background. For the debugger, it is very useful to have a hash
table data structure. Hash tables are not part of bash (yet). The way
these are implemented is to convert what in Perl would be $file{key}
into a single identifier "file_key" making use of BASH's hashed symbol
table.

But in order to do this "key" can't have any non-identifer symbols,
like "+", "/", "." and so on. So these must either be stripped or
replaced. We in fact, replace them to make it easier to recontruct the
original name. Right now I don't list all the weird symbols that might
appear in a filename. In particular, I don't have "+" listed.

Doing a reverse translation of +2D0M2D0D6Slibtool the original
filename with a path probably contained something like
"+2.0-2-0.6/libtool", possibly with other stuff in front. If this is
the case, then a simple fix is to make sure we tranlate the "+" in
_bashdb_file2var.  That is, change this line 22 of bashdb-file.inc:

  local varname=`builtin echo $filename | tr '* .?/"[]-' 'ABDQSqLRM'`

into this:

  local varname=`builtin echo $filename | tr '+* .?/"[]-' 'PABDQSqLRM'`

Actually, I've already made the change in CVS. 

If that works, let me know. If not, it would be helpful to understand
not just what the error message you encountered given below, but some
short example giving *input* that you typed to get that output.
Better, is a short test case that causes the debugger to fail.

Thanks.


James Michael DuPont writes:
 > 
 > --- "R. Bernstein" <ro...@pa...> wrote:
 > > Hi there, Ho there, 
 > > 
 > > Okay. Thanks for the information and looking into bashdb. If you have
 > > questions, comments, or problems with bashdb let us know.
 > > 
 > I am running this on libtool 
 > 
 >  /usr/local/bin/../lib/bashdb/bashdb-list.inc: line 200: local:
 > +2D0M2D0D6Slibtool: value too great for base (error token is
 > "2D0M2D0D6Slibtool")
 > /usr/local/bin/../lib/bashdb/bashdb-list.inc: line 200: local:
 > +2D0M2D0D6Slibtool: value too great for base (error token is
 > "2D0M2D0D6Slibtool")
 > 
 > # the line is 
 >    local -i max_line=`_bashdb_get_assoc_scalar_entry "_maxline_"
 > $filevar`
 >     #   echo "debug: -- max_line: $max_line --"
 > 
 > bash -x  ../libtool --mode=link i586-mingw32msvc-gcc 
 > -DGLIB_STATIC_COMPILATION  -mms-bitfields -Wall -D_REENTRANT
 > -I/usr/local/win32/include  -I/usr/local/win32/include/glib-2.0/
 > -mms-bitfields -L/usr/local/win32/lib -o test-gdk-pixbuf.exe 
 > test-gdk-pixbuf.o libgdk_pixbuf-2.0.la -L/usr/local/win32/lib/ -lgdi32
 > -lgobject-2.0 -lgmodule-2.0  -lglib-2.0 -lintl -liconv 
 > 
 > It has something to do with the size of the identfiers,
 > i will gdb it.
 > 
 > mike
 > 
 > =====
 > James Michael DuPont
 > http://introspector.sourceforge.net/
 > 
 > __________________________________________________
 > Do you Yahoo!?
 > Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
 > http://mailplus.yahoo.com

Re: [Bashdb-devel] introduction (James Michael DuPont)

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

--- "R. Bernstein" <ro...@pa...> wrote:
> Hi there, Ho there, 
> 
> Okay. Thanks for the information and looking into bashdb. If you have
> questions, comments, or problems with bashdb let us know.
> 
I am running this on libtool 

 /usr/local/bin/../lib/bashdb/bashdb-list.inc: line 200: local:
+2D0M2D0D6Slibtool: value too great for base (error token is
"2D0M2D0D6Slibtool")
/usr/local/bin/../lib/bashdb/bashdb-list.inc: line 200: local:
+2D0M2D0D6Slibtool: value too great for base (error token is
"2D0M2D0D6Slibtool")

# the line is 
   local -i max_line=`_bashdb_get_assoc_scalar_entry "_maxline_"
$filevar`
    #   echo "debug: -- max_line: $max_line --"

bash -x  ../libtool --mode=link i586-mingw32msvc-gcc 
-DGLIB_STATIC_COMPILATION  -mms-bitfields -Wall -D_REENTRANT
-I/usr/local/win32/include  -I/usr/local/win32/include/glib-2.0/
-mms-bitfields -L/usr/local/win32/lib -o test-gdk-pixbuf.exe 
test-gdk-pixbuf.o libgdk_pixbuf-2.0.la -L/usr/local/win32/lib/ -lgdi32
-lgobject-2.0 -lgmodule-2.0  -lglib-2.0 -lintl -liconv 

It has something to do with the size of the identfiers,
i will gdb it.

mike

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

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Bashdb-devel] introduction (James Michael DuPont)

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

Hi there, Ho there, 

Okay. Thanks for the information and looking into bashdb. If you have
questions, comments, or problems with bashdb let us know.


 > Hey there,
 > Just wanted to let you know that I am starting to look into bashdb. I
 > have selected your project as a possible partner for the introspector
 > bash interface.
 > I would like to be able to dump exisiting bash scripts into rdf/xml
 > using the redland lib similar to what we are doing with the gcc.
 > 
 > also I need to debug some configure/libtool scripts, so I hope that
 > this will be a usefull tool.
 > 
 > Later,
 > mike
 > 
 > =====
 > James Michael DuPont
 > http://introspector.sourceforge.net/
 > 
 > __________________________________________________
 > Do you Yahoo!?
 > Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
 > http://mailplus.yahoo.com
 > 
 > 
 > 
 > --__--__--
 > 
 > _______________________________________________
 > Bashdb-devel mailing list
 > Bas...@li...
 > https://lists.sourceforge.net/lists/listinfo/bashdb-devel
 > 
 > 
 > End of Bashdb-devel Digest

[Bashdb-devel] introduction

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

Hey there,
Just wanted to let you know that I am starting to look into bashdb. I
have selected your project as a possible partner for the introspector
bash interface.
I would like to be able to dump exisiting bash scripts into rdf/xml
using the redland lib similar to what we are doing with the gcc.

also I need to debug some configure/libtool scripts, so I hope that
this will be a usefull tool.

Later,
mike

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

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Bashdb-devel] merging bashdb to bash

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

Two good news from Santa Claus:-)

1. Finally, I could get a contact with Chet Ramey, bash maintainer.
   He wrote me he'll start reviewing the bashdb patches next week.

2. bashdb.el has been included to GNU Emacs(Rocky's effort). 

Masatake YAMATO

Re: [Bashdb-devel] Bashdb-devel digest, Vol 1 #10 - 1 msg

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

> However, by all means perhaps you can succeed where I have not had
> success and don't have reason to believe I will have success.  So
> please do contact Chet. Two people petitioning for this at this are
> probably better than one. The fact that I've written a good deal of
> code on this is really inconsequential. If you could succeed here, I'd
> happily give up any and all claims to authorship. Really!

Ok. I'll contact Chet. Once "handshake" is established,
please, appear on the front stage.

Masatake

Re: [Bashdb-devel] Bashdb-devel digest, Vol 1 #10 - 1 msg

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

> What you should use is in fact the patched version of gud.el in
> bash/debugger/emacs. That includes bashdb.el. I am given to believe
> that in a future version of emacs this in fact will appear. (I've sent
> in FSF release papers and they should be received by now).
Great! Could you apply the patch I attached to this mail before merging to
FSF official source tree?

> I suppose this we should remove so people don't get confused. Right? 
There is no problem when the code is merged. What the user have to do
is just M-x bashdb:)

The most important thing is bashdb itself. The quality of bashdb is high enough.
It should be merged to FSF official source tree maintained by Chet Ramey.
While a go, I thought I tried to contact with him. However, I thought 
the first contact should be done by the bashdb author, so I didn't try.

Masatake

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

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

Actually, neither! Confusing, isn't it? I'll take suggestions as to
how to handle, after I explain....

What you should use is in fact the patched version of gud.el in
bash/debugger/emacs. That includes bashdb.el. I am given to believe
that in a future version of emacs this in fact will appear. (I've sent
in FSF release papers and they should be received by now).

bash/debugger/emacs/bashdb.el is sort of a temporary work around. A
loadable standalone verion. It is like gud, but it doesn't have menu
entries. 

Finally, bash/emacs/bashdb.el is what was in the BASH 2.05b
distribution, I believe it is slightly broken. 

I suppose this we should remove so people don't get confused. Right? 

[Bashdb-devel] two bashdb.el's

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

Which should we use bash/emacs/bashdb.el  or bash/debugger/emacs/bashdb.el?

Masatake

[Bashdb-devel] BASH with debug (bashdb) 0.32 - important bugs fixed, ddd GUI support available

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

Version 0.32 fixes some long-standing problems with wrong line numbers
and some other bugs. It also adds a couple new features that I think
will be of benefit to many people including patches add bashdb support
to ddd, a GUI front end. Also added was a useful examine command ("x")
analogous to the Perl5 debugger command of the same name. If you
upgrade infrequently, this is probably a version you should get.

If you ever need to debug bash code, configure scripts or understand
RedHat's init scripts with their many source includes, this is the
debugger for you. At this point, bashdb should be fairly stable.

For more information on the recent changes, see the NEWS file inside
the package (in bash-2.05b-debugger-0.32/debugger/NEWS) or the
sourceforge release notes:
http://sourceforge.net/project/shownotes.php?release_id=122434

To get the source code for bashdb: 
  http://prdownloads.sourceforge.net/bashdb/?sort_by=date&sort=desc

The above contains a huge patch file to ddd 3.3.1 to support bashdb. To get a the 
source already patched: 
  http://prdownloads.sourceforge.net/bashdb/bash-2.05b-debugger-0.32.tar.gz?download

The complete online manual can be found at:
  http://bashdb.sourceforge.net/bashdb.html

[Bashdb-devel] hacked bashdb support into ddd

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

Someone requested a non-emacs GUI. I had suggested ddd since it seemed
like the most versatile of the GUI front-ends and it seemed the easiest to do.

No rocket science here, but it was a bit more work that I had thought
it would be and the changes seemed to be pretty much scattered around
the the code.

The bad news is that ddd doesn't look like its maintained so I'm not
sure that the patches will be looked over and/or applied. I seem to be
a collector a projects which are not maintained or not maintained
cooperatively.

There's are some small loose ends and small features that could be
cleaned up. In some cases I found it expedient to change bashdb
messages to match gdb output more closely than add more code to ddd.

[Bashdb-devel] Re: other developers

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

The only folks I know of on this list are us two. But any and all are
welcome to join!

[Bashdb-devel] other developer

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

Is Gary Vaughan member of this list?
If not, I'd like to invite him to here.
Ok?

Is Chet Ramey member of this list?
If not, I'd like to let him know bashdb.
Ok? I think we have to send mail again and 
again. If bashdb is merged into bash, I believe
the version of bash should be called bash3.

Masatake

Re: [Bashdb-devel] prompt is hidden

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

I just commited a small patch to bashdb-cmds.inc to handle the bug you
just found and tracked down. Although the comment before the addition
is lengthy, the change itself is very small. Basically this line was
added:

  local _bashdb_prompt_output=${_tty:-/dev/null} # if no tty, no prompt

and a redirect of stderr appended to the debugger "read" command:

  2>$_bashdb_prompt_output

It may seem odd to set stderr and thus prompt output to /dev/null if
the debugger output is not a tty. No prompt if we don't have a tty to
read it on the other end? However the bash code for the builtin read
command does almost (but not quite) the same thing: it doesn't display
the prompt if the *input* is not a tty to read commands from. If I
knew how to test for this, probably that would be a better fix.

But it is correct to *always* set stderr. Suppose the debugged program
was:

  (autofig --version) 2>save-this-output
  # Inspect first line of output

If we were debugging this, we would add our prompt to the file
save-this-output and mess up the program.

It also is convenient from a programming standpoint that always
setting stderr makes the code more uniform than if sometimes the read
command were:

  read ... 2>$_bashdb_prompt_output

and sometimes we issued this without the 2>$_bashdb_prompt_output as
is done in _bashdb_msg(). And because if this, we don't need to use and
"if" statement as is done in _bashdb_msg() or an "eval" which I
suggested in the last message which interacts badly with that "eval"
of the "exec" command in _bashdb_cmd_source to redirect stdin.

So that brings up the point that perhaps _bashdb_msg and _bashdb_print
have bugs in them too since potentially they too could mess up the
debugged-program's output (when there is no tty to output to such as
from running say from a command file). They too should probably
unconditionally redirect their output. However I'm not sure what the
correct thing to do is there either.

Suggestions? Comments?