We should document that double-clicking rustup-init may not work properly

[katsuhiro3]

Problem

On Windows, if you run rustup-init.exe by double clicking the executable, it wouldn't detect custom paths in CARGO_HOME and RUSTUP_HOME and install to the default path.

Steps

1. Set the variables CARGO_HOME and RUSTUP_HOME via command line (setx ... /m) or Windows GUI
2. Double click the rustup-init.exe executable
3. Answer Y to the initial prompt regarding having to install additional dependencies
4. On the next screen, observe the incorrect paths being presented
5. Proceed with the installation. Choose default installation
6. Observe the absence of the installed app in the paths described by CARGO_HOME and RUSTUP_HOME
7. Observe the app being located in the default location (%USERPROFILE%\.cargo\ and %USERPROFILE%\.rustup\ respectively)

Workaround

1. Open a separate cmd instance
2. Navigate to the rustup-init.exe file and run it
3. Observe correct paths being displayed
4. Observe the app being installed into CARGO_HOME and RUSTUP_HOME properly

Notes

Windows version: Version 10.0.19042 Build 19042

[kinnison]

I'm not sure what's going on here, since presumably these variables are global environment settings in Windows.

Is there anything we could do in order to ameliorate this, or is it a question of simply documenting that if you're wanting this behaviour you must run rustup-init from the cli?

[katsuhiro3]

The decision is up to you, @kinnison. One of the reasons why I brought it to light is because I couldn't find anybody with a similar issue by googling, so if this one remains unchanged at least people might find a solution through my ticket.

[kinnison]

Well, it's not up to me if there's something we can do to improve matters. I don't understand why Windows wouldn't be setting environment variables for double-clicked things but is for running it in a cmd window.

However it ought to be fairly easy for someone to add/update docs to hilight that it's best to run rustup-init from a cmd or powershell window rather than by double-click.

[workingjubilee]

My recent Windows experience has been with the Windows Terminal app, and I have spoken to other Rust-on-Windows users who have also strongly endorsed Windows Terminal (which defaults to a PowerShell interface, but also plays well with WSL setups). The former is available on the "Microsoft Store", and I believe we should (gently) recommend it and make sure Rustup works on it in particular, as

0. It has an X11 ("MIT") Licensed codebase at https://github.com/microsoft/terminal, so even if there are certain modifications to it in a specific distribution (e.g. the MS Store one), it is easier to anticipate, inspect, program, and file bugs against.
1. It eschews certain kinds of "legacy" cmd.exe behavior that are different from, and nuisances to program around if you are expecting, semantics typical to a more Unix-y terminal. (It's still Windows and thus object-oriented though.)
2. Without such a recommendation, I have noticed users have tried to use random command prompts that may make their own modifications to the environment and which we cannot anticipate... there are actually a LOT of such command prompts, it seems, on Windows... so such a nudge may reduce the number of "not actually rustup" bug reports.
3. It appears to work well on most Windows machines, and is very nice and customizable.

[rbtcollins]

I don't think this bug had anything to do with the terminal. Rather, because the variables were set in the registry, explorers process environment block wasn't updated, double clicking on the exe doesn't run an intervening new shell process, and we only consider the peb variables. Not an entirely satisfactory hypothesis but one that is testable.

Two ways, either set the variables via setx, reboot, double click on rustup-init. Or use a batch file to invoke rustup-init via double clicking and see if that corrects the behaviour.