stdin inherits by default on unix, not on windows

[brson]

In multirust-rs I discovered that the proxy binaries must add command.stdin(process::Stdio::inherit()); to the child commad in order for stdin to work in the subprocess, but only on windows. On unix it works by default.

[alexcrichton]

Is this correct? I tested this program and it works fine on Windows/Unix:

use std::env;
use std::io;
use std::process::Command;

fn main() {
    if env::args().len() == 1 {
        let s = Command::new(env::current_exe().unwrap())
                .arg("foo")
                .status()
                .unwrap();
        assert!(s.success());
    } else {
        let mut s = String::new();
        println!("{:?}", io::stdin().read_line(&mut s));
        println!("{}", s);
    }
}

Is there perhaps another test case to try out though?

[rprichard]

That test case is using status(), which according to documentation results in an inherited stdin by default. However, there's this recent commit that changes stdin's default to Stdio::Null for status() and output(). I'm wondering whether that commit breaks a stability guarantee.

I confirmed that, with the current nightly, the test case fails on Linux -- i.e. read_line immediately returns Ok(0).

I then tried changing the call to spawn() instead, but when I did, the read_line() call failed with an I/O error. I ran the test program on Linux from a GUI terminal, so I expected stdin to be a pty. I haven't figured out why that's happening. If I change the parent to invoke head -n3, then head fails with an I/O error.

[brson]

I am pretty confused now. After going back and checking both Unix and Windows I now have to have process::Stdio::inherit() for both in order for stdin to work in the child (this code is calling .status()). The particular code I'm looking at previously did not specify how to deal with stdin at all. This is on rustc 1.9.0-nightly (c9629d61c 2016-03-10).

[rprichard]

I then tried changing the call to spawn() instead, but when I did, the read_line() call failed with an I/O error. ...

I think this part isn't Rust related; I reproduced it with Python. The parent dies before the child, making the child an orphan, and somehow that interferes with the child's access to the pty.

[brson]

@alexcrichton Ok, my scenario is actually more complicated.

This is the executable proxy code in multirust-rs. In response to cargo --run the multirust proxy sets inherit on stdin, then runs cargo. cargo runs my executable (in this case another multirust) which then can't read from stdin.

[alexcrichton]

Ah excellent diagnosis @rprichard! I think this was a bug introduced by #31618, I'll work on a fix.