Rustup doesn't play well with uppercased proxy names on Windows

[jaraco]

Verification

• I searched for recent similar issues at https://github.com/rust-lang/rustup/issues?q=is%3Aissue+is%3Aopen%2Cclosed and found no duplicates.
• I am on the latest version of Rustup according to https://github.com/rust-lang/rustup/tags and am still able to reproduce my issue.

Problem

Attempting to install Rust on Windows 11 for ARM, I was following the directions at https://www.rust-lang.org/tools/install. I downloaded the 64-bit installer, then attempted to run it from my shell/terminal that I had open, but the invocation failed with an error:

 ~ [1] # ./rustup-init
error: unknown proxy name: 'RUSTUP-INIT'; valid proxy names are 'rustc', 'rustdoc', 'cargo', 'rust-lldb', 'rust-gdb', 'rust-gdbgui', 'rls', 'cargo-clippy', 'clippy-driver', 'cargo-miri', 'rust-analyzer', 'rustfmt', 'cargo-fmt'

Invoking the command from powershell or Explorer, the command succeeds, so isn't a blocking issue, but it would be nice not to have an obscure error when trying to invoke from my preferred shell.

Steps

1. Download rustup-init, e.g. https --download -q static.rust-lang.org/rustup/dist/x86_64-pc-windows-msvc/rustup-init.exe.
2. Using a shell like zsh or xonsh, invoke ./rustup-init (or .\rustup-init or ./rustup-init.exe).

Possible Solution(s)

In GitSquared/edex-ui#1124 (comment), another user was having a similar issue, which seems to be rooted in how ARG0 is set/cleared between processes. Perhaps the same technique could be applied to rustup-init.

In #3237, a similar issue was encountered when rust-analyzer was integrated into rustup, which was seemingly fixed by adding rust-analyzer to the rustup book, but I'm unsure how that's relevant or how it would apply to rustup-init.

Notes

No response

Rustup version

~ [1] # powershell -c './rustup-init --version'
rustup-init 1.27.1 (54dd3d00f 2024-04-24)

Installed toolchains

n/a

OS version

~ # platform.uname()
uname_result(system='Windows', node='bulletproof', release='11', version='10.0.22631', machine='ARM64')

[rami3l]

@jaraco Thanks for filing this issue! We already have native Windows on ARM64 installers so there's no reason to use x64 emulation. See #3840 for more details.

TLDR: would you mind trying the installation again with https://static.rust-lang.org/rustup/dist/aarch64-pc-windows-msvc/rustup-init.exe?

[jaraco]

You bet! Same issue exists:

 ~ # https static.rust-lang.org/rustup/dist/aarch64-pc-windows-msvc/rustup-init.exe --download -q
 ~ # ./rustup-init
error: unknown proxy name: 'RUSTUP-INIT'; valid proxy names are 'rustc', 'rustdoc', 'cargo', 'rust-lldb', 'rust-gdb', 'rust-gdbgui', 'rls', 'cargo-clippy', 'clippy-driver', 'cargo-miri', 'rust-analyzer', 'rustfmt', 'cargo-fmt'

[jaraco]

FYI, I don't have any reason to think this issue is related to the ARM architecture.

[djc]

So this error comes from here:

https://github.com/rust-lang/rustup/blob/master/src/bin/rustup-init.rs#L142

It looks like it happens because for whatever reason, arg0 gets uppercased in the process of how you are running it. It seems pretty surprising in the sense that we've had not (as far as I know) seen any reports about this before. The maintainer for edex-ui suggests that zsh is doing something potentially surprising in GitSquared/edex-ui#1124 (comment), pointing at https://github.com/zsh-users/zsh/blob/00d20ed15e18f5af682f0daec140d6b8383c479a/Src/exec.c#L465, not sure how/why that would lead to uppercasing?

I suppose this could potentially be fixed by doing something like eq_ignore_ascii_case() instead of direct string match for the commands? Still, this really seems like a zsh/xonsh problem (as suggested by the fact that Powershell or Explorer can execute this problem okay).

[jaraco]

Indeed. I've confirmed that xonsh is uppercasing the command:

 ~ # import xonsh.environ as xenv
 ~ # xenv.locate_binary('./rustup-init')
'C:\\Users\\jaraco\\RUSTUP-INIT.EXE'

That 'locate_binary' is called here.

To be sure, I assumed that zsh would have the same problem based on other reports, but I didn't test it myself. It's quite possible that the issue with zsh due to a different cause (not uppercasing), so is irrelevant to the issue that brought me here in xonsh.

I've traced the issue to xonsh.commands_cache, where I see that at least some of the code acknowledges that names are stored as uppercase but should be returned in their original form.

I see other places where names are uppercased (on Windows only).

I do think I agree - xonsh should not be altering the command as entered by the user. I'll follow up with xonsh on that.

But I also believe that rustup should honor operating system conventions. That is, if the user enters .\RUSTUP-INIT, the command should succeed. In cmd.exe, the command will also fail:

 ~ # cmd /c .\RUSTUP-INIT
error: unknown proxy name: 'RUSTUP-INIT'; valid proxy names are 'rustc', 'rustdoc', 'cargo', 'rust-lldb', 'rust-gdb', 'rust-gdbgui', 'rls', 'cargo-clippy', 'clippy-driver', 'cargo-miri', 'rust-analyzer', 'rustfmt', 'cargo-fmt'

Probably rustup should be lenient to that approach.

Interestingly, Powershell seems to be smarter and resolves the wrong case to the case of the matched filename and succeeds:

 ~ # powershell -c '.\\RUSTUP-INIT' --version
rustup-init 1.27.1 (54dd3d00f 2024-04-24)

[ChrisDenton]

Shells should really not be uppercasing commands but that said rustup could use eq_ignore_ascii to workaround it.

[jaraco]

Shells should really not be uppercasing commands but that said rustup could use eq_ignore_ascii to workaround it.

Agreed. And I've filed the bug and PR to fix the issue in xonsh/xonsh#5469.

The question that remains is - should programs be lenient to the case of the command in the case the shell passes the name typed by the user (such as in the cmd.exe example above). That is, if the user types ./Rustup-Init, should the command work? I'm slightly inclined to say no, especially given that shells like Powershell will transform the command into the form as it appears on disk, allowing executable to assume that ARG0 is the same as the name on the file system, and it shouldn't be the responsibility of each and every application to normalize their ARG0 handling.

I recommend close as won't fix.

[rami3l]

@jaraco Alright, let's close it first and see whether something else will bring us back here (if anything, the fix on our side would be trivial) 🙏