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?