Menu
▾
▴
bashdb-devel
|
From: Masatake Y. <je...@gy...> - 2002-10-21 13:48:54
Attachments:
autogen.sh
|
(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 || {
|
|
From: R. B. <ro...@pa...> - 2002-10-21 14:47:47
|
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.
|
|
From: Masatake Y. <je...@gy...> - 2002-10-21 14:50:29
|
> 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.
|
|
From: R. B. <ro...@pa...> - 2002-10-21 15:56:32
|
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
|
|
From: Masatake Y. <je...@gy...> - 2002-10-21 16:06:22
|
> 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. |
|
From: R. B. <ro...@pa...> - 2002-10-21 17:27:17
|
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. |
|
From: Masatake Y. <je...@gy...> - 2002-10-21 16:13:56
Attachments:
bashdb-prompt.patch
|
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 |
|
From: Masatake Y. <je...@gy...> - 2002-10-21 18:34:04
|
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
|
|
From: Masatake Y. <je...@gy...> - 2002-10-21 18:42:17
Attachments:
bashdb-prompt2.patch
|
Sorry, I forgot to attach the new patch. I took too many mistakes today. |
|
From: R. B. <ro...@pa...> - 2002-10-22 03:49:50
|
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
|
|
From: R. B. <ro...@pa...> - 2002-10-22 10:58:11
|
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?
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X