Rust: Command::spawn has weird rules for finding binaries on Windows

[ollie27]

The offending code is here which is apparently to have it search the child's %Path% for the binary to fix #15149. It has a few issues though.

1. It is only triggered when the child's environment has been customised. This means Command::new("foo.exe").spawn() and Command::new("foo.exe").env("Thing", "").spawn() uses different rules for finding the binary which seems unexpected.
2. It will replace any extension on the program name with .exe. This means Command::new("foo.bar").env("Thing", "").spawn() attempts to launch foo.exe first. Command::new("foo.bar").spawn() correctly tries to launch foo.bar as CreateProcess will not replace the extension.
3. If the program name is an absolute path then this is still triggered but will just try that path for every item in the child's %Path%. For example Command::new(r"C:\foo.bar").env("Thing", "").spawn() looks for C:\foo.exe several times.
4. The use of .to_str().unwrap() means it panic!s if the program name is not valid Unicode.
5. Prehaps the biggest issue, but maybe it's itentional, is that none of the logic for finding binaries seems to be documented (std::process::Command).

An easy way to fix this is to just remove the hack so we just rely on the behaviour of CreateProcess on Windows which is a least documented. The behaviour is already very different between Windows and Linux and we should probably just accept that in order to get reliable results cross-platform it's best to use absolute paths.

[retep998]

Personally I'd much rather we didn't have this hack and just accepted that Windows and Unix are different and document their differences.

[alexcrichton]

@ollie27 these all sound like bugs to me rather than weird behavior. Removing this behavior is not an option as the are plenty of programs currently relying on this behavior. Would be great to fix the issues, however!

[luser]

It would definitely be nicer if Command didn't try to be too smart here, but breaking existing usage would also suck. For sccache I contributed to the which crate, which will append an exe extension on Windows if necessary (but not replace an existing extension). One thing that the which crate doesn't implement is support for using the extensions from the PATHEXT environment variable, which on my Windows 10 machine does include .COM. (The Python which package does support this.)

[jokeyrhyme]

Another issue is that .spawn() assumes that ".exe" is the only extension that Windows' executables have: https://github.com/rust-lang/rust/blob/1.24.0/src/libstd/sys/windows/process.rs#L154
This ignores ".cmd", ".com", etc

[cuviper]

Another issue is that .spawn() assumes that ".exe" is the only extension that Windows' executables have

I just found in https://github.com/rust-lang/rust/issues/50870#issuecomment-390309938 that it's consistent with CreateProcess to only try ".exe".

[BasixKOR]

I just found a documentation about how file extensions work in Windows, and it might help since CMD finds the application to open a file with %PATHEXT% using this information (I found this on Stack Overflow answer, but it may be wrong.).

[anp]

One thing that the which crate doesn't implement is support for using the extensions from the PATHEXT environment variable, which on my Windows 10 machine _does_ include .COM.

By the way @luser, after reading through this thread I found that in the interim the which crate has gained support for other extensions through PATHEXT.