Executing rustup --version (the script) behaves (mostly) as expected. Executing rustc --version returns the error
error: command failed: 'rustc': No such file or directory (os error 2)
which I think is bash’s way of saying “I have no idea how to execute such a thing.” Or, maybe it is suggesting that a shared library is missing when it tries to execute through one of the symlinks.
All this is on nixOS. OS config pulls from nixos-22.05 with some userland installs pulling from nixpkgs-unstable. Trying different commits of nixpkgs did not change the misbehavior.
I think I may have inadvertently fixed my problem by removing/rebuilding $RUSTUP_HOME and $CARGO_HOME.
When running in a new shell I get this output
eric@farm:~$ nix shell nixpkgs#rustup
eric@farm:~$ rustup --version
rustup 1.24.3 (1980-01-01)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
eric@farm:~$ rustc --version
error: no override and no default toolchain set
eric@farm:~$ which rustc
/nix/store/fc9nh6sydcs6cnkn9i83krn0ppy5ib4a-rustup-1.24.3/bin/rustc
That output seems reasonable to me.
When running in a rust project where rust-toolchain populates $RUSTC_VERSION and rustup has run at least once, I also see reasonable results.
I suspect that I had some bad binaries in $RUSTUP_HOME and $CARGO_HOME from when I was exploring use of buildFHSUserEnv to build the project. Possibly I should keep $RUSTUP_HOME and $CARGO_HOME local to the project until I know better how to ensure consistent usage across projects. Or, maybe I’ll get mkShell working well enough that I won’t be creating more problems for myself.
I’m new enough to nixOS and rust that mixing the two has been very painful. Several times I’ve considered abandoning one or the other, but I keep coming back to try to make it work as I get more experience with nix subtleties.
Nothing is going wrong; rustup is behaving as intended. This is unrelated to nix, you’re misunderstanding rustup itself.
See, those symlinks there are symlinks to rustup. Since it supports managing multiple toolchains, rustup has some clever logic to figure out which binary is intended to be called in a specific situation, and then calls it. I.e., using rustc will actually run rustup, and rustup will then find whichever rustc you configured it to run and run that.
You clearly don’t have a toolchain installed yet. Use rustup to install your toolchain and it will work - well, hopefully, assuming you don’t have problems with dynamic linkers.
This is also why your projects work when properly set up. Once you have a toolchain configured, well, rustup will work.
The shadowing you observe is just that; depending on whether rustup or rustc is added to $PATH first, you either get rustup’s fake rustc or the one from the nix package. In the former case, there is no rustup toolchain installed yet, so you get an error. In the latter, you call the rustc installed by nix, which succeeds.