Always quote program name in Command::spawn on Windows #42436
Conversation
`CreateProcess` will interpret args as part of the binary name if it
doesn't find the binary using just the unquoted name. For example if
`foo.exe` doesn't exist, `Command::new("foo").arg("bar").spawn()` will
try to launch `foo bar.exe` which is clearly not desired.
|
Alternatively, we could pass the binary name as the first parameter to |
|
Looks good to me, thanks @ollie27! Would it be possible to add a test for this? Passing the binary name explicitly sounds fine as well, so it sounds like we should just do both things? |
carols10cents
added
the
S-waiting-on-author
|
It looks like using the first parameter behaves very differently:
I guess I'll try to write a run-make test for this. |
Make sure args aren't interpreted as part of the program name.
|
Right, I've added a run-make test. |
|
📌 Commit 02955f5 has been approved by |
|
So I just did a quick test and when I passed a verbatim path as the first parameter to |
|
⌛ Testing commit 02955f5 with merge 9006db1... |
Always quote program name in Command::spawn on Windows [`CreateProcess`](https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425.aspx) will interpret args as part of the binary name if it doesn't find the binary using just the unquoted name. For example if `foo.exe` doesn't exist, `Command::new("foo").arg("bar").spawn()` will try to launch `foo bar.exe` which is clearly not desired.
|
☀️ Test successful - status-appveyor, status-travis |
alexcrichton
added
the
relnotes
In rust-lang#42436 the behavior for spawning processes on Windows was tweaked slightly to fix various bugs, but this caused rust-lang#42791 as a regression, namely that to spawn batch scripts they need to be manually spawned with `cmd /c` instead now. This updates the compiler to handle this case explicitly for Emscripten. Closes rust-lang#42791
In rust-lang#42436 the behavior for spawning processes on Windows was tweaked slightly to fix various bugs, but this caused rust-lang#42791 as a regression, namely that to spawn batch scripts they need to be manually spawned with `cmd /c` instead now. This updates the compiler to handle this case explicitly for Emscripten. Closes rust-lang#42791
…, r=nikomatsakis rustc: Spawn `cmd /c emcc.bat` explicitly In rust-lang#42436 the behavior for spawning processes on Windows was tweaked slightly to fix various bugs, but this caused rust-lang#42791 as a regression, namely that to spawn batch scripts they need to be manually spawned with `cmd /c` instead now. This updates the compiler to handle this case explicitly for Emscripten. Closes rust-lang#42791
…, r=nikomatsakis rustc: Spawn `cmd /c emcc.bat` explicitly In rust-lang#42436 the behavior for spawning processes on Windows was tweaked slightly to fix various bugs, but this caused rust-lang#42791 as a regression, namely that to spawn batch scripts they need to be manually spawned with `cmd /c` instead now. This updates the compiler to handle this case explicitly for Emscripten. Closes rust-lang#42791
…, r=nikomatsakis rustc: Spawn `cmd /c emcc.bat` explicitly In rust-lang#42436 the behavior for spawning processes on Windows was tweaked slightly to fix various bugs, but this caused rust-lang#42791 as a regression, namely that to spawn batch scripts they need to be manually spawned with `cmd /c` instead now. This updates the compiler to handle this case explicitly for Emscripten. Closes rust-lang#42791
…, r=nikomatsakis rustc: Spawn `cmd /c emcc.bat` explicitly In rust-lang#42436 the behavior for spawning processes on Windows was tweaked slightly to fix various bugs, but this caused rust-lang#42791 as a regression, namely that to spawn batch scripts they need to be manually spawned with `cmd /c` instead now. This updates the compiler to handle this case explicitly for Emscripten. Closes rust-lang#42791
CreateProcesswill interpret args as part of the binary name if itdoesn't find the binary using just the unquoted name. For example if
foo.exedoesn't exist,Command::new("foo").arg("bar").spawn()willtry to launch
foo bar.exewhich is clearly not desired.