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.
- 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.
- 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.
- 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.
- The use of
.to_str().unwrap() means it panic!s if the program name is not valid Unicode.
- 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.
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.Command::new("foo.exe").spawn()andCommand::new("foo.exe").env("Thing", "").spawn()uses different rules for finding the binary which seems unexpected..exe. This meansCommand::new("foo.bar").env("Thing", "").spawn()attempts to launchfoo.exefirst.Command::new("foo.bar").spawn()correctly tries to launchfoo.barasCreateProcesswill not replace the extension.%Path%. For exampleCommand::new(r"C:\foo.bar").env("Thing", "").spawn()looks forC:\foo.exeseveral times..to_str().unwrap()means itpanic!s if the program name is not valid Unicode.std::process::Command).An easy way to fix this is to just remove the hack so we just rely on the behaviour of
CreateProcesson 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.