Bernard James POPE wrote:

[Dean wrote:] > Wouldn't you want the debugger to use stdin and stdout for its interaction with the

...

user, and run the object program with stdin and stdout handles of its own creation? (In that case your question seems moot.) I've always been very confused by debuggers that try to share stdin/stdout with the debugged program. Dean

Hi Dean,

You make a good point.

One thing to note is that in my debugger the user's program is run to completion before debugging begins. This means that the debugger does not need to use stdin/stdout until after the user's program is finished with them.

In a debugger that intersperses its own I/O with that of the user's program, it would make a lot of sense to do as you say above.

I (perhaps naively) thought that it would be simpler for my debugger to reuse the stdin/stdout handles.

Were you thinking of using a system call to dup, or something else.

I am not a terminal expert, as you can probably guess, so I'd appreciate any comments that you feel are appropriate.

Thanks, Bernie.

Glynn Clements mentioned some good reasons why you shouldn't try to "reuse" stdin and stdout. For example, stdin or stdout (or both) could be connected to files, pipes, etc. If your debugger truly runs the user program to completion, there shouldn't be any problem: The operating system "reuses" "terminal"-connected stdin/stdout when a subprocess completes. So I suspect you need the user program process to stick around for post-"completion" debugging. In this case I still think the clean approach is to have the debugger create fresh stdin/stdout handles for execution of the user program. When the user program does want to do "terminal" input and/or output, on Unix I would first consider pseudo-terminals (man pty). Dean