std::process::Command is inconsistent between platforms

[nicka101]

When using std::process::Command with a clean environment (i.e. using env_clear when building the command), the behaviour of spawn is not consistent between Windows and Unix-like OSes. On Unix-like OSes, it behaves as expected and manages to spawn the process based on its working directory, however on Windows it always returns an error with the message "other os error", which seems to be related to the fix for #15149 in src/libstd/sys/windows/process.rs on line 130, and it failing to handle a lack of PATH variable properly.

I have confirmed that simply adding a PATH variable back after env_clear (with just the working directory for contents), does resolve the issue and allows the process to spawn.

For reference my tests were run on:
Windows 10 - rustc 1.11.0-beta.1 (8dc253b 2016-07-05)
Debian Jessie - rustc 1.10.0 (cfcb716 2016-07-03)

[Aatch]

Do you have some example code? It doesn't need to be a full reproduction (since that requires extra stuff), but just to see if there are any confounding details. As far as I can tell, if there is no PATH variable set, it'll use the program you supply, which seems like the expected behaviour here.

It's more likely to be an inconsistency in the platforms itself, either with the expected environment or lookup behaviour.

[nicka101]

This is a simple reproduction of the issue:
https://gist.github.com/nicka101/a22032bcb3b5181bafc8feda5842c205
Obviously the working directory path and possibly the binary name differ between the platforms, I used echo as the binary for both, in /bin on Debian and in C:\Program Files\Git\usr\bin\ on Windows.

[durka]

Related to #31259?

[nicka101]

It does seem to be the same underlying issue, though I'd note that PATH is the only requirement for the process to start and that setting PATH to the working directory on env_clear is sufficient and would emulate *nix behaviour.

[Mark-Simulacrum]

Yeah, I'm going to close this in favor of #31259.