bashdb-devel — Developer's discussion mailing list

Re: [Bashdb-devel] prompt is hidden

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

I was thinking about this problem and your patch some more. My mistake
before was trying to redirect stdout, not stderr. So a simple fix
would have just been to add "2>$_tty" to the "read" builtin when $_tty
is defined.

I don't think the builtin read needs to be changed at all.

Below is a patch that does just that. However.... when I run the
regression tests, test "misc" fails because lines don't appear:

  prof1.cmd called
  prof2.cmd called...
  calling prof1.cmd...
  prof1.cmd called

All of these are not printed from the shell test script, but instead
from the debugger command script which issues a debugger "print"
command for each of these.

It is then possble that _bashdb_cmd_source has bug in it, or at
minimum interacts funny with the code below. I think the problem is an
interaction between the "eval" a "read" command and the "exec" of
_bashdb_bash_source to reset the file descriptor. 

Any thoughts or suggestions? 


--- bashdb-cmds.inc.~1.72~     2002-10-21 22:04:33.000000000 -0400
+++ bashdb-cmds.inc	       2002-10-21 23:11:58.000000000 -0400
@@ -62,8 +62,16 @@
 
     # Loop over debugger commands
     IFS="$_bashdb_space_IFS";
-    while read -e -p "bashdb${_bashdb_less}$_bashdb_hi${_bashdb_greater} " \
-      _bashdb_cmd _bashdb_args <&$_bashdb_input_desc ; do
+
+    local _bashdb_redirect=''
+    if [[ -n "$_tty"  ]] ; then
+      _bashdb_redirect="2>$_tty"
+    fi
+    local _bashdb_read_cmd=\
+"read -e -p 'bashdb${_bashdb_less}$_bashdb_hi${_bashdb_greater}' "\
+"_bashdb_cmd _bashdb_args <&$_bashdb_input_desc $_bashdb_redirect"
+
+    while eval $_bashdb_read_cmd ; do 
 
      # Set default next, step or skip command
      if [[ -z $_bashdb_cmd ]]; then

Re: [Bashdb-devel] prompt is hidden

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

Sorry, I forgot to attach the new patch.
I took too many mistakes today.

Re: [Bashdb-devel] prompt is hidden

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

Thank you for comments.

> A couple of other thoughts. First, you can't assume $_tty is set. See
> the ugly code in _bashdb_msg from bashdb-io.inc. You may be inside a
> command file and not in an interactive shell in which case there is no
> tty. If you can find a cleaner way to handle _bashdb_msg the same
> would work here. If not you might have to create the read command and
> eval it - ugly.

I see. I've decided to use variables that hold -F options and output
stream for the prompt. See new patch.

>  > I've added new option -F to fource print output to stderr.
> 
> You mean to stdout, not stderr, right? 

Stderr.

See read.def::read_builtin:

  if (prompt && edit == 0)
    {
      fprintf (stderr, "%s", prompt);
      fflush (stderr);
    }

The prompt is written to stderr.

> Lastly I suppose we should create a test (in tests) and update the
> documentation in bashref.texi. However one might wait until after we
> get comments.

Before these works. I'd like to commit the code to CVS repository.
Ok?

Masatake

Re: [Bashdb-devel] prompt is hidden

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

A couple of other thoughts. First, you can't assume $_tty is set. See
the ugly code in _bashdb_msg from bashdb-io.inc. You may be inside a
command file and not in an interactive shell in which case there is no
tty. If you can find a cleaner way to handle _bashdb_msg the same
would work here. If not you might have to create the read command and
eval it - ugly.

 > I've added new option -F to fource print output to stderr.

You mean to stdout, not stderr, right? 

Lastly I suppose we should create a test (in tests) and update the
documentation in bashref.texi. However one might wait until after we
get comments.

Re: [Bashdb-devel] prompt is hidden

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

Please, evaluate my patch for the issue.
I`ve bind output channel of read command to _tty as you suggested.
I've added new option -F to fource print output to stderr.

Masatake

Re: [Bashdb-devel] prompt is hidden

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

> Will look at when I get a chance... Perhaps others can su
Yes! 
Probably, I solved this issue.
I'm doing cvs-diff now.
Please wait.

[Bashdb-devel] prompt is hidden

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

I now understand the problem. It however doesn't mean I know how to
fix properly. When you run this: 

 > 4:      (autofig --version) < /dev/null > /dev/null 2>&1 || {

you are stopping *inside* in a subshell which has had stdin and stdout
redirected to /dev/null. The debugger is using stdout in the subshell
environment to print the prompt on line; but stdout has beeen redirected to
/dev/null.

The faulty code is probably on line 65 of bashdb-cmds.inc: 

    while read -e -p "..."  _bashdb_cmd _bashdb_args <&$_bashdb_input_desc ...

We should redirect output to the debugger's output rather than take
the default stdout which may be nulled. bashdb has a variable $_tty,
(see _bashdb_msg or _bashdb_printf) but a small test and that didn't
work.

Will look at when I get a chance... Perhaps others can su

[Bashdb-devel] Re: prompt is hidden

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

> Masatake YAMATO writes:
>  > (We should use the name of commands: configure, autogen.sh, libtool to 
>  >  advertise bashdb. These are too big sh scripts to debug bashdb.)
Sorry. I wrote wrong. What I should write:

            These are too big sh scripts to debug without bashdb.

[Bashdb-devel] prompt is hidden

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

Masatake YAMATO writes:
 > (We should use the name of commands: configure, autogen.sh, libtool to 
 >  advertise bashdb. These are too big sh scripts to debug bashdb.)

Yes, debugging many configure or autogen.sh or libtool scripts would
really get lots of bugs out of bashdb. The debugger could stand a lot
of debugging itself. 

 > 
 > When I run bashdb with targeting autogen.sh attached to this mail,
 > bashdb didn't show its prompt. Is this known problem?

I wasn't aware of the problem before you gave this example. 

 > (autogen.sh:4):
 > 4:      (autofig --version) < /dev/null > /dev/null 2>&1 || {
                                           ^^^^^^^^^^^

The problem seems to be the output redirect above. Don't know how to
fix right now, perhaps someone else has a suggestion. The problem is
probably somewhere in bashdb-sig.inc the call to
_bashdb_print_source_line or _bashdb_print_source_line in
bashdb-list.inc.

[Bashdb-devel] prompt is hidden

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

(We should use the name of commands: configure, autogen.sh, libtool to 
 advertise bashdb. These are too big sh scripts to debug bashdb.)

When I run bashdb with targeting autogen.sh attached to this mail,
bashdb didn't show its prompt. Is this known problem?

[jet@chuf frontline]$ bashdb autogen.sh
Bourne-Again Shell Debugger, release bash-2.05b
Copyright 2002 Rocky Bernstein
This is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.

(autogen.sh:4):
4:      (autofig --version) < /dev/null > /dev/null 2>&1 || {

Re: [Bashdb-devel] Re: About the screenshot bashdb-devel list...

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

Forgive me my wrong quotation in the last mail.

I've just added a screenshot that shows bashdb's backtrace
function.

[Bashdb-devel] Re: About the screenshot bashdb-devel list...

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

I've added new screenshots to the web page.

Please, check.

> I just looked at bashdb-devel just now and just subscribed to
> it. Shame on me. Also I'm going hiking for a week starting Monday (and
> have a wedding to attend on Sunday).
> 
> Do you still have "make check" problems? It looks like the difference
> is just in the file names. This probably needs to be tracked down as
> to why the file appears as xxx for you and ./xxx for me (or vice
> versa).
> 
> As for tracking changes in the unmodified bash, yes it sort of is my
> intention that we'll have to track the changes in releases and this is
> not going to be fun. Given the situation I don't know what else to do. 

[Bashdb-devel] Time for another small release 0.26

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

Here's the NEWS entry: 

-  Document "break" command. 

-  Change "line" to "linespec" in online help where 
   appropriate.

-  Add commands "tbreak" (one-time break) and "display" (automatic display).

-  Add provision to debug into a script ("debug" command), and leave
   script without going back into debugger command loop
   (BASHDB_QUIT_ON_QUIT environment variable). 

-  Document "tbreak", "enable" and "disable" in manual.

[Bashdb-devel] Re: Misc replies and my apologies for not replying to the bashdb-devel list...

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

> By the way, the screen shot looks truncated when I looked at. 
Sorry. I just put new one.

[Bashdb-devel] Misc replies and my apologies for not replying to the bashdb-devel list...

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

I just looked at bashdb-devel just now and just subscribed to
it. Shame on me. Also I'm going hiking for a week starting Monday (and
have a wedding to attend on Sunday).

Do you still have "make check" problems? It looks like the difference
is just in the file names. This probably needs to be tracked down as
to why the file appears as xxx for you and ./xxx for me (or vice
versa).

As for tracking changes in the unmodified bash, yes it sort of is my
intention that we'll have to track the changes in releases and this is
not going to be fun. Given the situation I don't know what else to do. 

It's possible if there is not enough help or everyone is busy that we
just have patches on the major releases whatever that may mean.

As for the problem with index.html. Really this is a copy of
bashdb/htdocs/index.html. I create this file without g+w which was a
mistake. I tried deleting the file and recreating it to see if I could
make it g+w. Of course, before I scp it to
/home/groups/b/ba/bashdb/htdocs I could make it g+w which is what I
just did. However I know if the future I am going to forget. We may
need to open a ticket to force this file g+w. I tried adding the
link. If you wnat to change index.html (and by all means do it - it is
really very plain), please change the CVS version and check it in and
then do the copy. 

By the way, the screen shot looks truncated when I looked at. 

Again, I apologize for not being more on the ball with the mailing
list I set up. Gimme time to get used to all this newfangle
technology.

[Bashdb-devel] make check

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

All make check's test fails on my thinkpad.
Do you know already?
Or something wrong?

[Bashdb-devel] Re: autotools boot strap

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

> You mean the current bash maintainer, not the original other. I think
> so. But it is hard to know what the maintainer knows and doesn't since
> he seems often to be uncommunicative often. Two years ago, I submitted
> some patches and received no word on it - whether it was received,
> needed changes or whatnot. Before starting this I sent info on what
> the changes were to get to the first version of this. Again nothing. 

I see. However, we have to make efforts ANYWAY.
I could help you in these political hacking.

To be useful, bashdb should handle any bash syntax. If the bash
development and bashdb development become branched, finally
bashdb could not handle all bash syntax. I believe this is the most 
important point of bashdb project.

Masatake

[Bashdb-devel] Re: autotools boot strap

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

Hi,

>  > I cannot do much things, however, I could do some small things.
>  > Please, add me. My sourceforge account name is "masata-y".
>  > First my task is putting a bashdb.el screenshot to the project
>  > web page:)
> 
> Great. Yet Again, thanks!

I've put bashdb.sourceoforge.net:/home/groups/b/ba/bashdb/htdocs/bashdb.png.
It seems that index.html is not writable for me. So

   1. do chmod g+w index.html or
   2. add a link to bashdb.png to index.html.

Do you know evenyone loves screenshots:)

Masatake YAMATO

[Bashdb-devel] Re: autotools boot strap

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

> You mean the current bash maintainer, not the original other. I think
> so. But it is hard to know what the maintainer knows and doesn't since
> he seems often to be uncommunicative often. Two years ago, I submitted
> some patches and received no word on it - whether it was received,
> needed changes or whatnot. Before starting this I sent info on what
> the changes were to get to the first version of this. Again nothing. 

I see. However, we have to make efforts ANYWAY.
I could help you in these political hacking.

To be useful, bashdb should handle any bash syntax. If the bash
development and bashdb development become branched, finally
bashdb could not handle all bash syntax. I believe this is the most 
important point of bashdb project.

Masatake

[Bashdb-devel] Re: autotools boot strap

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

Hi,

>  > I cannot do much things, however, I could do some small things.
>  > Please, add me. My sourceforge account name is "masata-y".
>  > First my task is putting a bashdb.el screenshot to the project
>  > web page:)
> 
> Great. Yet Again, thanks!

I've put bashdb.sourceoforge.net:/home/groups/b/ba/bashdb/htdocs/bashdb.png.
It seems that index.html is not writable for me. So

   1. do chmod g+w index.html or
   2. add a link to bashdb.png to index.html.

Do you know evenyone loves screenshots:)

Masatake YAMATO

[Bashdb-devel] Re: autotools boot strap

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

Masatake YAMATO writes:

 > I write what I know. In Autotools book written by Gary V. Vaughan, et
 > al., bootstrap.sh and autogen.sh are introduced for this purpose. The
 > difference between bootstrap.sh and autogen.sh is runnint configure at
 > the end of script or not; autogen.sh runs and bootstrap.sh does not.
 > I cound find autogen.sh in many projects. However, bootstrap.sh is
 > good for cross compiling.

Thanks for the information! I guess then the best thing to do is to
make it so cvscompile.sh, bootstrap.sh and autogen.sh all work. 

By the way I've set up a mailing list
bas...@li....  (I'm copying that list to see if
it *really* works.)

If in the past there has been private mail, it's not been by intention
but just a lack of getting an open discussion list set up. Your mail
has been very helpful to this project and perhaps others will find the
information you write useful too.

 > > The idea of putting this in an open CVS was to encourage multiple
 > > developers. (Personally, I'm not a big fan of bash. However I am too
 > > often forced to use it.) If you would like write access work on
 > > development and make changes to this project let me know.
 > 
 > I cannot do much things, however, I could do some small things.
 > Please, add me. My sourceforge account name is "masata-y".
 > First my task is putting a bashdb.el screenshot to the project
 > web page:)

Great. Yet Again, thanks!

 > The buggiest question is: does the bash author know this project?

You mean the current bash maintainer, not the original other. I think
so. But it is hard to know what the maintainer knows and doesn't since
he seems often to be uncommunicative often. Two years ago, I submitted
some patches and received no word on it - whether it was received,
needed changes or whatnot. Before starting this I sent info on what
the changes were to get to the first version of this. Again nothing.