When `rustup self update` is invoked from inside WSL, it does nothing

Problem

I was encountering a strange problem which could potentially be explained by an out-of-date Rustup. So I ran rustup.exe self update. But the problem persisted.

One full day later, I realized that I was still running an old Rustup. I ran rustup.exe self update again , again with no effect. I realized both these invocations were invoked from inside WSL, so I opened a normal CMD.EXE window and ran rustup self update. It did the correct thing on the first try.

I have not yet attempted to see if this reproduces with a fresh Rustup install. I will attempt so after submitting this bug. (EDIT: See below, it reproduces with 1.25.1)

Steps

The steps I took in more detail:

I am running Windows 10 , 10.0.19045 Build 19045. I have a Windows Services for Linux install (WSL1 VM, Ubuntu 20.04.6 LTS). Because I greatly prefer the Linux command line tooling, but for work and other reasons I need my Rust install to be a Windows Rust which produces standard Windows executables, I have a Windows version of Rust installed and when doing development I run cargo.exe from within a WSL window. (I do not, and never have, have a Linux copy of Rust installed on the Linux side of the WSL divide on this machine.) This basically always works fine. WSL has a complicated mechanism so that invoking a Windows .exe from a WSL Bash prompt "does the right thing" and fakes out the exe into thinking it's running in a new, fresh Windows environment. For example, Linux-side environment variables are erased before invoking the Windows executable unless you opt in to a complex environment-variable-sharing arrangement. The Windows copy of Rust on this machine was installed via Rustup, apparently quite long ago.

Last night I attempted to build a particular Rust project and hit essentially an error message that my version of Rustup was too old. I tried running rustup.exe self update and rustup.exe update. At that time, the self update reported success but appears to have had no effect at all, whereas the update succeeded and successfully bumped my cargo/rustc/etc up to 1.69.0.

The next day, asking for help with this issue in a Discord channel (I had not yet at this point realized my rustup was still old), someone asked me what version I was running. I checked and got... rustup 1.11.0 (e751ff9f8 2018-02-13). That of course sounds wrong if I had done a self update the previous evening. I immediately tried self update again and got this bizarre series of prompt responses:

Andi@Alita:/mnt/c/Users/Andi/work/backup/listening-playlist$ rustup.exe self update
info: checking for self-updates
info: downloading self-update
info: rustup updated successfully to 1.25.2
Andi@Alita:/mnt/c/Users/Andi/work/backup/listening-playlist$ rustup.exe --version
rustup 1.11.0 (e751ff9f8 2018-02-13)

The Discord suggested that maybe rustup is installing, but not to where I thought it was. I was not able to figure out how to get rustup to report where it is installing. I did find this in the manual:

https://rust-lang.github.io/rustup/installation/index.html#choosing-where-to-install

rustup allows you to customise your installation by setting the environment variables CARGO_HOME and RUSTUP_HOME before running the rustup-init executable

At this point I remembered that WSL sometimes behaves strangely with Environment Variables. I did some checks:

• where rustup in CMD.EXE printed C:\Users\Andi\.cargo\bin\rustup.exe
• $CARGO_HOME and $RUSTUP_HOME were not set (echo showed them to be empty) in my WSL window.
• %CARGO_HOME% and %RUSTUP_HOME% were not set on the CMD.EXE side (did not expand when echoed)
• I did not think at this time to check which rustup.exe on the WSL side, but trying it just this second I got /mnt/c/Users/Andi/.cargo/bin//rustup.exe .
• I did not think at this time to check $WSLENV on the WSL side, but checking just this second it's WT_SESSION::WT_PROFILE_ID

I then ran rustup self update in the CMD.EXE window. This reported success and rustup --version immediately afterward reported rustup 1.25.2 (17db695f1 2023-02-01).

At this point both I and the Discord believed I had found a rustup bug worthy of filing. However, I had an outstanding question: Is this a bug in current rustup, or is the bug exclusive to the 2018 Rustup I started the day with? There was no way to test without downgrading rustup. Rustup can't downgrade itself, so I think the next test would be to install rustup 1.25.1 on a fresh system and see if the bug reproduces. Unfortunately when uninstalling rustup to test this I ran into problems. So I am posting this issue for now I will update when I have successfully attempted to reproduce with Rustup 1.25.1.

Possible Solution(s)

My "expected behavior" (which admittedly 1.25.x might comply with already) (EDIT: It doesn't) is that Windows rustup.exe should behave the same when run from an ordinary WSL Bash prompt as it does when run from an ordinary CMD.EXE prompt. Almost all Windows software behaves normally in this situation, including cargo and (if doing update instead of self update) usually rustup itself. My use case here is admittedly "weird" but I don't think it is uncommon, WSL is very popular at present. The problem (if it is present with 1.25.x) is especially problematic because Rust "fails silently" in this case (IE it does not report an error, it reports a successful install even if this is not necessarily true).

In addition, this experience makes me feel that rustup should have a way of reporting "if you were to install a new Rust, to what directory would you install it?" and "if you were to install a new rustup, to what directory would you install it?" (assuming these are meaningful questions, and assuming this feature does not already exist unbeknowst to me). That would have helped diagnosing the above problems. You could just say "well, just check what the CARGO_HOME and RUSTUP_HOME environment variables are" but in some cases (WSL) it might not be trivial to know what environment variables are set by the time rustup actually executes.

Notes

No response

Rustup version

As described above, rustup 1.11.0 (e751ff9f8 2018-02-13) when the problem first expressed and rustup 1.25.2 (17db695f1 2023-02-01) after self update finally succeeded.

Installed toolchains

C:\Users\Andi>rustup show
Default host: x86_64-pc-windows-msvc
rustup home:  C:\Users\Andi\.rustup

no active toolchain

However, this was taken after a failed uninstall messed up my system so it probably does not fully reflect the configuration during the events described above.

No source file or test is named. Start by reproducing rustup.exe self update and --version from WSL and CMD.EXE with the reported Rustup versions, then compare CARGO_HOME, RUSTUP_HOME, and WSLENV. Trace the self-update path and its tests, if present; done means the WSL invocation updates the executable it subsequently runs or reports a meaningful failure.