zhiburt/conpty

A Rust abstraction over ConPTY https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/

conpty

A library which provides an interface for ConPTY.

It is originally developed to be a windows backend for zhiburt/expectrl.

Usage

Include the library to your Cargo.toml.

# Cargo.toml
conpty = "0.5"

Get started

Running echo and reading its output.

use std::io::{Read, Result};

fn main() -> Result<()> {
    let mut proc = conpty::spawn("echo Hello World")?;
    let mut reader = proc.output()?;

    println!("Process has pid={}", proc.pid());

    let mut buf = [0; 1028];
    reader.read(&mut buf)?;

    assert!(String::from_utf8_lossy(&buf).contains("Hello World"));

    Ok(())
}

conpty's Issues

`ProcAttr::args()` has no effect

If a user sets the arguments for a program via ProcAttr::args() or ProcAttr::arg(), the arguments will not be used when spawning the process. This affects usage of expectrl, as passing a Command with arguments to Session::spawn() will work on Unix but not on Windows.

Conpty doesn't work when run test via `nextest`

I stumbled accross the issue when working on uutils integration.
In the CI uutils uses nextest to run the unittests. (Use cargo install cargo-nextest)
For some strange reason, the read from the conpty blocks for ever, even when the child process is explicitly writing data to it.
I tried what happens if the conpty tests are executed via nextest. It happens there as well.
The following is a log from the conpty tests run via nextest, which I had to cancel after half a minute due to beeing stuck.

Do you have any idea how this could happen?
BTW, I think a similar strange thing happens to me when the debugger is attached. Is this related?

PS D:\dev\conpty> cargo nextest run
   Compiling conpty v0.5.1 (D:\dev\conpty)
    Finished test [unoptimized + debuginfo] target(s) in 2.07s
    Starting 16 tests across 4 binaries
        PASS [   0.030s] conpty process::tests::env_block_test
        PASS [   0.064s] conpty::pipe close_one_pty_input_doesnt_close_others
        PASS [   0.049s] conpty::pipe dropping_one_reader_doesnt_affect_others
        PASS [   0.659s] conpty::io write_ctrl_z
        PASS [   1.251s] conpty::io read_to_end_blocks_after_process_exit
        PASS [   1.276s] conpty::io write_ctrl_c
        PASS [   0.100s] conpty::test_process envs
   Canceling due to interrupt: 8 tests still running
       ABORT [  21.189s] conpty::io read_blocks_after_process_exit_with_no_output
     Message [         ] code 0xc000013a: {Anwendung mit STRG+C beendet}
Die Anwendung wurde mit STRG+C unterbrochen. (os error 572)
       ABORT [  20.517s] conpty::pipe non_blocking_read
     Message [         ] code 0xc000013a: {Anwendung mit STRG+C beendet}
Die Anwendung wurde mit STRG+C unterbrochen. (os error 572)
       ABORT [  19.835s] conpty::test_process test_args_1
     Message [         ] code 0xc000013a: {Anwendung mit STRG+C beendet}
Die Anwendung wurde mit STRG+C unterbrochen. (os error 572)
       ABORT [  21.194s] conpty::io read_until
     Message [         ] code 0xc000013a: {Anwendung mit STRG+C beendet}
Die Anwendung wurde mit STRG+C unterbrochen. (os error 572)
       ABORT [  21.060s] conpty::pipe non_blocking_mode_does_not_affect_all_readers
     Message [         ] code 0xc000013a: {Anwendung mit STRG+C beendet}
Die Anwendung wurde mit STRG+C unterbrochen. (os error 572)
       ABORT [  21.202s] conpty::io read_blocks_after_process_exit
     Message [         ] code 0xc000013a: {Anwendung mit STRG+C beendet}
Die Anwendung wurde mit STRG+C unterbrochen. (os error 572)
       ABORT [  21.192s] conpty::io write_and_read
     Message [         ] code 0xc000013a: {Anwendung mit STRG+C beendet}
Die Anwendung wurde mit STRG+C unterbrochen. (os error 572)
       ABORT [  19.917s] conpty::test_process test_args_0
     Message [         ] code 0xc000013a: {Anwendung mit STRG+C beendet}
Die Anwendung wurde mit STRG+C unterbrochen. (os error 572)
------------
     Summary [  21.211s] 15/16 tests run: 7 passed, 8 failed, 0 skipped
error: test run failed
PS D:\dev\conpty>

cant working on windows subsystem

I discovered conpty cant working when set #![windows_subsystem = "windows"]. the following code will get the bug。

Error Message : Windows error : Invalid handle

#![windows_subsystem = "windows"]

use std::io::Write;
fn main() {
    let proc = match conpty::spawn("cmd.exe"){
        Ok(p) => p,
        Err(e) => {
            let mut f = std::fs::File::create("error.txt").unwrap();
            f.write_all(format!("{}" ,e).as_bytes()).unwrap();
            f.flush().unwrap();
            return;
        },
    };
    proc.wait(None).unwrap();
}

Create a custom Error type or use io::Error

sticking with windows::Error might be not good decision

Async support (tokio runtime)?

Any chance the handles returned by Command::stdout() could be made async-capable? I spent a good deal of time seeing if I could somehow get them wrapped in a way that would allow tokio's AsyncReadBufExt-enabled structs to consume them, but my knowledge of futures internals is limited and it seems like conpty might be using a slightly different set of underlying types than tokio expects on Windows (HANDLE seems to be defined differently for some reason?)

hide non blocking functions behind feature `util`?

There's no reason to provide these function by default.