TTY not defined when Stdio::piped()

[heaths]

printenv was incorrectly writing VT sequences unconditionally, but when switching to anstream::println!() and anstream::eprintln!() color was no longer emitted. This is because the piped IO handles don't inherit (obviously) the FD so IsTerminal::is_terminal() returns false.

There are some crates out there like https://github.com/dtolnay/faketty that create a PTY, which might also help solve #22 better and, perhaps, is how Go's os/exec package is making all this work in op.

[heaths]

See https://cs.opensource.google/go/go/+/refs/tags/go1.24.0:src/os/exec/exec.go;l=574 as well as os.Pipe() implementations e.g.,

• Unix: https://cs.opensource.google/go/go/+/refs/tags/go1.24.0:src/os/pipe_unix.go;l=13
• Windows: https://cs.opensource.google/go/go/+/refs/tags/go1.24.0:src/os/file_windows.go;l=217

[heaths]

We can create a PTY in nix with posix_openpt and friends (see crate pty-process, which is nix-only) and CreatePseudoConsole on Windows.

The problem in either case is not being able to separate stdout and stderr. I can create separate PTYs for each stream, but then we're back to #22 and not able to interleave stdout and stderr exactly in the order they were written.

[heaths]

Something like this does work:

        let (pty, pts) =
            pty_process::blocking::open().map_err(|err| akv_cli::Error::new(ErrorKind::Io, err))?;


        let mut args = self.args.iter();
        let program = args.next().ok_or_else(|| {
            akv_cli::Error::with_message(ErrorKind::InvalidData, "command required")
        })?;
        let mut cmd = pty_process::blocking::Command::new(program).args(args);


        // If stdout or stderr is already redirected, redirect the same streams for the PTY.
        if !std::io::stdout().is_terminal() {
            cmd = cmd.stdout(std::io::stdout());
        }
        if !std::io::stderr().is_terminal() {
            cmd = cmd.stderr(std::io::stderr());
        }


        let mut process = cmd
            .spawn(pts)
            .map_err(|err| akv_cli::Error::new(ErrorKind::Io, err))?;
        let reader = BufReader::new(pty);
        let mut lines = reader.lines();
        while let Some(Ok(line)) = lines.next() {
            let masked = mask_secrets(&line, &secrets);
            println!("{masked}");
        }

But there doesn't seem to be any good cross-platform PTY support. Out of somewhat active, well-downloaded crates, sty-process is nice but only supports linux specifically and most POSIX systems. portable-pay may require starting commands using its CommandBuilder, which is rather simplistic and already launches processes (at least on Windows that I saw) under a shell unnecessarily.

What I really want is something that just creates a PTY. For POSIX - optimization on linux to use /dev/ptmx notwithstanding - is fairly easy using libc::openpt, libc::grantpt, and friends.

It's a bit more involved on Windows, but still pretty straight-forward. Indeed, Windows does require preparing the child process to use a PTY, but it looks like we can do that if we target nightly and use std::os::windows::process::CommandExt::spawn_with_attributes.

Thus, I could create a crate that just allocates a PTY and perhaps provides a helper on windows to set the attribute list accordingly. It does require nightly to enable an experimental feature, but it seems pretty active: rust-lang/rust#114854

Thus, I don't need to write yet another process abstraction. And because I'm using a PTY, I really don't need async from tokio::process::Command and, therefore, not tokio-util either.