winpty-rs unexpectedly replaces current process IO

[rivy]

When running the example conpty_example, the executables IO handles look to be replaced by the PTY handles.

> ::WinOS
> cargo build --bin conpty_example --features conpty_example
...
    Finished dev [unoptimized + debuginfo] target(s) in 5.69s
> target\debug\conpty_example.exe >NUL 2>&1
... output is displayed ...

Output should not be displayed.

When experimenting with the example, all output prior to the PTY creation+spawn is pushed through the original IO handles, but everything after is pushed through the PTY.

Does this have to be created in some other way to avoid polluting the original IO handles?

[andfoy]

Hi @rivy, streams are being opened again in case the parent process has done any kind of redirection, i.e., on a CI session:

winpty-rs/src/pty/conpty/pty_impl.rs

Line 71 in 88977d9

let h_console_res = CreateFileW(

then they are assigned as the standard streams for the PTY:

winpty-rs/src/pty/conpty/pty_impl.rs

Line 140 in 88977d9

result = if SetStdHandle(STD_OUTPUT_HANDLE, h_console).as_bool() {S_OK} else {Error::from_win32().into()};

However, the examples are designed to print the output from the PTY:

winpty-rs/src/examples/conpty.rs

Line 23 in 88977d9

Ok(out) => println!("{}", out.to_str().unwrap()),

In this case, then the problem would be related to the output redirection on the parent process, rather from the PTY.

Could you please confirm if the same situation arises when running the tests? cargo test --features conpty --features winpty

[rivy]

@andfoy , thanks for the reply.

Ultimately, I'm trying to use this crate to drive an external executable (specifically, deno) in such a way that the external executable believes itself to be in an unredirected state (ie, stdin/stdout/stderr are all seen as TTYs and not redirected). But, I also want to send input to the executable and capture all stdout/stderr output, without any of the child's I/O spilling into the parent process.

I'm reading lots of material, but I'm not sure that I grasp all the subtleties of how to drive such a process.

From readings, it looks like I might need to open the PseudoConsole using I/O pipes and possibly use the STARTF_USESTDHANDLES flag when starting the sub-process.

ref: Intro to WinOS PseudoConsole
ref: ConPTY from process with redirected handles

To answer your question, cargo test --features conpty passes the ConPTY tests, but I don't have WinPTY installed, so that portion fails.

[andfoy]

Thanks for the linked issue @rivy, according to the issue on ConPTY, we can try to add STARTF_USESTDHANDLES to the process creation info to see if that fixes the issue