fix: normalize forward slashes in paths for cmd.exe on Windows (fixes #818)

[leno23]

Summary

• On Windows, the default cmd.exe shell treats / as a switch prefix, so commands like ./target/debug/foo.exe failed while --shell=none worked.
• Normalize path-like tokens (./…, ../…, C:/…, *.exe, etc.) to use \ before passing the command line to cmd /C.
• Leave URLs (://) and non-path tokens (e.g. echo hello/world) unchanged.

Test plan

• Unit tests in util::windows_cmd (all platforms)
• cargo clippy -- -D warnings
• Windows integration test windows_forward_slashes_in_executable_path (CI)

Closes #818

Made with Cursor

[leno23]

Pushed a fix for Windows CI: shell_words::split was mangling C:\\Users\\... paths in echo >> file redirect commands. Replaced with quote-aware splitting that does not treat \\ as escapes.

[leno23]

CI is green on all targets (including Windows after the shell_words / integration-test fixes). Ready for review when you have time — thanks!

[leno23]

Friendly ping — Windows forward-slash fix is CI-green on all targets. Thanks!

[AngelicosPhosphoros]

Have you tested the form without MAX_PATH limit?
From https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#win32-file-namespaces :

For file I/O, the \\?\ prefix to a path string tells the Windows APIs to disable all string parsing and to send the string that follows it straight to the file system. For example, if the file system supports large paths and file names, you can exceed the MAX_PATH limits that are otherwise enforced by the Windows APIs.

[leno23]

Good point — this PR only rewrites / → \ in path-like tokens so cmd.exe does not treat / as a switch; it does not create extended paths or change how hyperfine opens files.

For user-supplied \\?\ paths that still use forward slashes, the normalizer now treats the \\?\ prefix explicitly (same / → \ pass as other paths). Added unit tests for:

• \\?\C:/Users/foo/very/long/path/to/tool.exe → backslashes in the path segment
• \\?\C:\Users\foo\tool.exe left unchanged when already backslash-only

I have not added a Windows CI job that constructs a real >260-character path on disk (would be environment-dependent); happy to add an integration test if you want that coverage in CI.

[AngelicosPhosphoros]

Thanks.