Installs binaries into $PATH that may not work

Problem
When using rustup, a binary is installed into ~/.cargo/bin regardless of whether there is a suitable implementation for that binary. As a consequence, the standard Unix approach of checking for a binary before using it of running which rustfmt or command -v rustfmt falsely succeeds, leading the user to think the binary is installed, when executing it only fails with an error. This differs from the way almost all other tools and package managers (e.g., rvm) behave and makes scripting difficult.

Apple does the same thing with their git binary, and this has caused untold angst and confusion among programmers and scripters.

rustup should ensure that a binary exists in PATH (i.e., in ~/.cargo/bin) if and only if it is fully functional. If the user switches to a different toolchain (or installs a toolchain) that does not contain the component in question, ~/.cargo/bin should not contain a binary.

Steps

1. curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y
2. command -v cargo-miri && cargo-miri
3. Notice command fails with an error message.

Possible Solution(s)
rvm handles this by installing binaries into a different location and creating symlinks, which should be fine on Unix. Windows may be trickier due to symlinks requiring either developer mode or administrator privileges, but copying files or installing and removing a stub could be a possibility.

Notes

Output of rustup --version:

rustup 1.21.1 (7832b2ebe 2019-12-20)

Output of `rustup show`:

Default host: x86_64-unknown-linux-gnu
rustup home: /home/bmc/.rustup

stable-x86_64-unknown-linux-gnu (default)
rustc 1.44.1 (c7087fe00 2020-06-17)

Start by reproducing the documented installation and command -v cargo-miri && cargo-miri steps on the stated toolchain. Investigate how rustup places component binaries in ~/.cargo/bin, including toolchain switching and installation; done means PATH checks fail when a component is unavailable without breaking supported platforms.