Tracking Issue for expose force_quotes in CommandExt on Win32 #82227
Labels
C-tracking-issue
Category: An issue tracking the progress of sth. like the implementation of an RFC
O-windows
Operating system: Windows
T-libs-api
Relevant to the library API team, which will review and decide on the PR/issue.
Comments
lygstate
added
C-tracking-issue
Dylan-DPC-zz
pushed a commit
to Dylan-DPC-zz/rust
that referenced
this issue
Feb 17, 2021
Expose force_quotes on Windows. On Windows, the arg quotes and not quotes have different effect for the program it called, if the program called are msys2/cygwin program. Refer to msys2/MSYS2-packages#2176 This also solve the issues comes from https://internals.rust-lang.org/t/std-process-on-windows-is-escaping-raw-literals-which-causes-problems-with-chaining-commands/8163 Tracking issue: rust-lang#82227
EliahKagan
added a commit
to EliahKagan/gitoxide
that referenced
this issue
Mar 21, 2025
- Have the `justfile` wait to run `cargo metadata` until it is running a recipe that actually needs the information from it. (Currently, that information is always the `target` directory location, in whose `debug` subdirectory some binaries are found.) This avoids a delay if `cargo metadata` has not run. The length of the delay varied but was often noticeable on Windows. Because running it again (in the absence of a clean or relevant change) is cheap, it is not a performance problem that this runs the command multiple times instead of once. This also avoids error messages from `cargo metadata` if it can't complete, unless it is actually being used. Those messages didn't prevent other recipes (besides those that used the metadata) from running. But they created the appearance of failure, and also were misleading when they didn't come from the recipe being run. - Handle errors from `cargo metadata` more robustly, by causing recipes that actually need the result of `cargo metadata` to fail if it fail -- and to fail immediately before attempting any other operations -- rather than attempting to use empty data. The metadata are piped to `jq -r .target_directory`, which actually succeeds even if it doesn't receive any data, giving empty output. Before, an attempt was made to use the empty output in building paths meant to go to debug builds of some binaries. Because the command is now running only when the output is actually needed, it is fine to make it hard error when it fails. The natural way to do this would be to `set -o pipefail`. But while it is in the newest POSIX standard, there remain otherwise largely POSIX-compatible `sh` implementations in use that don't support it (koalaman/shellcheck#2555). Our test suite requires `bash`, so the next obvious choice would be to use a shebang recipe or script recipe for `bash`. The problem is that shebang and script recipes don't usually work on Windows, because `just` passes a Windows path with `\` separators to the shell unquoted. This often results in the shell trying to run a file whose name is transformed by treating them specially, then causing them to dropped as if by quote removal. For example, on a recipe named `hello` with a `#!/usr/bin/env bash` shebang: /bin/bash: C:UsersekAppDataLocalTempjust-BVbCgphello: No such file or directory (One way this happens is by argument processing in `cygwin1.dll` or `msys-2.0.dll`, which seek to bridge the gap between the Unix expectation that the caller is responsible for all expansions and the Windows expectation that the callee is responsible for some. See rust-lang/rust#82227. Even when only globbing is attempted, `\` can be treated specially if it seems to escape a wildcard, or to escape another `\` that seems to escape a wildcard, etc.) Fortunately, in this case we can just check if the result of trying to parse out the `target` directory path gave a nonempty result, and treat the failure to do that as a hard error. - Remove the `check-mode` recipe's need for cargo metadata, by having it run the `internal-tools` binary via `cargo run` rather than looking up where the `target` directory is and finding `it` in `debug` under it. That approach is needed for the paths that are passed to the journey test runner, but `check-mode` can just use `cargo`. The preceding build command could be removed, since `cargo run` builds unless the binary is up to date. But keeping them as separate commands may make the output more readable.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Feature gate:
#![feature(windows_process_extensions_force_quotes)]This is a tracking issue for expose force_quotes in CommandExt on Win32
Forces all arguments to be wrapped in quote (
") characters.This is useful for passing arguments to MSYS2/Cygwin based
executables: these programs will expand unquoted arguments containing
wildcard characters (
?and*) by searching for any file pathsmatching the wildcard pattern.
Adding quotes has no effect when passing arguments to programs
that use msvcrt. This includes programs built with both
MinGW and MSVC.
Public API
Steps / History
Unresolved Questions
The text was updated successfully, but these errors were encountered: