re-opening a closed stdin?

[Dean Herington]

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