The three process approach is interesting if not also a bit heavyweight and prone to the problems of the kind you mention. However it is general.
Another approach which stays within one process is gdb annotations or its follow on. Debugger output is in a different annotation from program output so you know where you are. I'm not sure how waiting for input is handled though. One thing people who use shells miss in a debugger shell is command completion. Python's stock debugger doesn't have it (at least not for 2.5.1) although ipython does; Ruby's shell, irb, can add this easily too. In pydb there is a "complete" command which lists possible completions for at least commands and subcommands. As with readline, this is often bound to the <tab> key. Complete returns a list of possible completions and then it is up to the front-end to figure out the best way to display this. It's kind of hard to describe this so you may get a better sense by trying say pydb. The last release of pydb doesn't have gdb annotations but what is in CVS does. And even here it lags a little behind what is in ruby-debug's SVN. In particular ruby-debug is tagging program output, while in pydb this still is more inferential since it appears somewhere around the prompt which is tagged. However if this is of interest and it is of interest, let me know and I can try to bring the code more in line with the Ruby debugger code. On Dec 11, 1:07 pm, cthoday <[EMAIL PROTECTED]> wrote: > On Dec 11, 11:11 am, "[EMAIL PROTECTED]" > > <[EMAIL PROTECTED]> wrote: > > On Dec 10, 11:05 am, cthoday <[EMAIL PROTECTED]> wrote: > > . > > > There is a Smart Terminal that allows interactive shells to operate > > > within a wx.TextCtrl. On Unix such programs need to be connected to a > > > pseudo terminal if they are to operate in interactive rather than > > > batch mode. However, the easy way to connect a Python program to > > > another process is by pipes. I have solved this by writing a small C > > > program to copy to and from the subprocess via the pseudo terminal. > > > ddd and Emacs typically work this way - using a subprocess via a > > pseudo terminal. > > Python has a pseudo tty module but I could not get it to do what I > wanted. The basic problem is that the shell thinks it is controlling a > VDU terminal but the application program cannot find out what mode the > shell is working in. If it is working in canonical mode then the line > is composed in the application before being sent to the shell. In raw > mode the application must send individual characters and compose the > line from the responses it gets. There may be no response if the input > was a password. Some responses do not work as might be expected. For > example the response to Backspace is Backspace, Space, Backspace. The > first Backspace moves the cursor to the left, the Space replaces the > character to be erased (provided it is not in Insert mode) and the > second Backspace move back over the Space. > > There is no means for the application program to determine whether or > not the shell is waiting for input. The shell assumes that the > terminal has displayed the prompt but it may be waiting in a buffer. > If it assumed that no buffering is used then multiple lines of output > from the program running in the shell may be painfully slow to display > in the application. The solution uses three processes: one copies from > the pipe to the tty, another copies from the tty to the pipe and the > third runs the shell. This works well except that it sometimes leaves > zombie processes if a process terminates abnormally. > > Shells that use GNU readline operate in raw mode but those that do not > have this facility provide a very poor experience for the user. In > this case I implement some basic line editing so that the user can at > least correct mistakes with Backspace. Shells that do not have line > editing include PHP and OCaml but, in the latter case, the shell comes > with the "ledit" command which solves the problem.
