It is possible to redirect bashdb's output to a pseudoterminal with option -t. I can't find an option to similarly redirect bashdb's input (in fact, I am wondering why -t does not redirect both the output AND input). This makes it difficult to implement a frontend with a console which would emulate the debugged script's terminal, but should NOT send any commmands to bashdb. Am I overlooking something?
To redirect bashdb's input you would use the long option --cmdfile or short option -x.
The -t option or -tty was supposed to model gdb's --tty option (or "tty" or "set inferior-tty") which does change both input and output. But not the debugger's input/output, the debugged PROGRAM's input and output. The debugger output stays the same. In this respect, what bashdb currently does is totally wrong -- even for output. I'll put this on a todo list so it doesn't get lost, but I have no idea when I'll ever have time to get around to it. However if you feel motivated to fix this, by all means submit a patch.
Thanks for the explanations. I think that the -x/--cmdfile option would be insufficient for the purpose of controlling the debugger backend from a frontend application. However, reimplementing -t/--tty to match gdb would help. I think I'll look into that on the weekend. The question is whether the meaning of -t/--tty should be changed or a new option introduced, as such a change would not be backwards-compatible.
After pondering bashdb's source code, I came up with a hack which does not require patching bashdb and achieves what I want:
1) To redirect bashdb's output, I can use the already implemented option -t
2) To read bashdb's input, I run the following command on startup:
e exec 999</dev/pts/3; _Dbg_input_desc=999
where /dev/pts/3 is the pseudoterminal from which the debugger's commands will be coming.
It's a hack because it exploits bashdb's internals and also upsets handling of the "source" command in the debugger, but it's simple, it seems to work, and if I needed "source", I suppose I could work around it.