Windows Command regression - broken paths

[Awpteamoose]

Code

I tried this code:

fn main() {
	std::process::Command::new("folder/echo.bat")
		.args(["hello"])
		.status()
		.unwrap();
}

where folder/echo.bat is

echo %*

I expected to see this happen:

   Compiling repro v0.1.0 (D:\projects\2022-03-20-repro)
    Finished dev [unoptimized + debuginfo] target(s) in 1.03s
     Running `target\debug\repro.exe`

D:\projects\2022-03-20-repro>echo hello
hello

Instead, this happened:

   Compiling repro v0.1.0 (D:\projects\2022-03-20-repro)
    Finished dev [unoptimized + debuginfo] target(s) in 0.95s
     Running `target\debug\repro.exe`

The system cannot find the path specified.

Version it worked on

rustc --version --verbose:

rustc 1.61.0-nightly (1bfe40d11 2022-03-18)
binary: rustc
commit-hash: 1bfe40d11c3630254504fb73eeccfca28d50df52
commit-date: 2022-03-18
host: x86_64-pc-windows-msvc
release: 1.61.0-nightly
LLVM version: 14.0.0

(aka nightly-2022-03-19)

Version with regression

rustc --version --verbose:

rustc 1.61.0-nightly (8d60bf427 2022-03-19)
binary: rustc
commit-hash: 8d60bf427a4b055f464122062e76b3ec34d4f8ba
commit-date: 2022-03-19
host: x86_64-pc-windows-msvc
release: 1.61.0-nightly
LLVM version: 14.0.0

(aka nightly-2022-03-20)

[ChrisDenton]

Ah, this was caused by the switch to using verbatim paths (aka \\?\) for Command. This allows for using longer paths but isn't supported by cmd.exe. The workaround is to call cmd directly:

std::process::Command::new("cmd")
    .args(["/c", r"folder\echo.bat"])
    .arg("hello")
    .status()
    .unwrap()

The ultimate fix will be to properly support running script files. But it should be possible to fix this specific issue in the meantime.

[Awpteamoose]

I'm not sure not being able to run scripts is exactly the case as I've run into this issue initially while trying to invoke nuget.exe and having nuget crash. Also if I call echo.bat without putting it in folder it also works fine.

[wwylele]

The problem might be on /. iirc \\?\ path doesn't support the other slash.

[Awpteamoose]

The problem might be on /. iirc \\?\ path doesn't support the other slash.

/ or \\ doesn't matter

[ChrisDenton]

the case as I've run into this issue initially while trying to invoke nuget.exe and having nuget crash.

I cannot quickly reproduce this locally but I suspect that's another (though related) issue. Some applications may not be able to cope with argv[0] being a \\?\ path. The fix here will be to set argv[0] to exactly what the user entered (this is similar to how shells usually work).

Also if I call echo.bat without putting it in folder it also works fine.

Yes, if you pass in just echo.bat it will work due to an undocumented feature of CreateProcessW (the underlying function call). It automagically rewrites the command to call cmd.exe in a way that may or may not work. If instead Rust itself had proper support for running script files then it would be easier to avoid these kinds of issues.

[apiraino]

Assigning priority as discussed in the Zulip thread of the Prioritization Working Group.

@rustbot label -I-prioritize +P-medium

[messense]

Looks like std::env::current_exe() also returns UNC path on Windows which caused a breakage in cargo-zigbuild: rust-cross/cargo-zigbuild#17