Wrong behavior when reading arguments with / in git bash

[dev-ardi]

The argument expands to git bash root folder. This doesn't happen with other commands (echo /foo works fine)
When the argument has only one letter (/a) it expands to A:/

Please complete the following tasks

• I have searched the discussions
• I have searched the open and rejected issues

Rust Version

1.73

Clap Version

4.4.6

Minimal reproducible code

#[derive(Parser, Debug)
struct Cli {
  pub foo: String
}

Steps to reproduce the bug with the above code

under git bash:
cargo run -- '/foo'

Actual Behaviour

foo = "C:/Users/user/AppData/Local/Programs/Git/foo"

Expected Behaviour

foo = "/foo"

Additional Context

chmln/sd#170

Debug Output

No response

[epage]

If you run with the debug output, as requested in the template, you'll likely see that clap is just subject to whatever std::env::args_os returns and that this problem is likely an error in something before clap gets it.

[CosmicHorrorDev]

Yeah, we've already confirmed that this is just clap using the args that it gets provided. Someone even made a demo program in C already (chmln/sd#208 (comment))

It's just some weird automagical path replacement that happens

[dev-ardi]

Yes, even in C it doesn't capture argv correctly but it would be nice if clap provided a fix.
Most Rust CLI programs depend on this and git bash is widely used in Windows so if a general fix were to be possible this would be the place for it.

[dev-ardi]

export MSYS_NO_PATHCONV=1 solves it, but I don't think it's possible to use this without making the user do it.

[epage]

Most Rust CLI programs depend on this and git bash is widely used in Windows so if a general fix were to be possible this would be the place for it.

We also don't automatically integrate wild or argfile but rely on people to do that directly. We'd need a lot more information to make the decision to unilaterally workaround this for people (if there is even a way to workaround it), like why MSYS does this and if it is universally viewed (even by MSYS maintainers) as wrong.