Make ~/.cargo/env more robust by always prepending the ~/.cargo.bin path

Problem you are trying to solve

my ~/.cargo/env script (or actually in my case, ~/.local/share/cargo/env) look like this

case ":${PATH}:" in
    *:"/home/me/.local/share/cargo/bin":*)
        ;;
    *)
        # Prepending path in case a system-installed rustc needs to be overridden
        export PATH="/home/me/.local/share/cargo/bin:$PATH"
        ;;
esac

It will not prepend the path if it already exists in $PATH. I've previously used cargo install to install software, and so I've had something like export PATH="$PATH:$HOME/.local/share/cargo/bin" in my .bashrc for a long time now. When I installed rustup, I had issues due to my OS toolchain being used instead.

Solution you'd like

It would be nice (although with increased complexity) if the env script would make sure .cargo/bin is before /usr/bin.

Alternatively, I wished commands like rustup show would print a warning if which rustc does not point to rustup`s rustc.

Notes

Impact: time saved. It took me surprisingly long due to rustup show telling me the esp toolchain was active and rustup target list printing the "error: toolchain 'esp' does not support components" as-is without wrapping it (i assume, from rustc). In addition to rustup show giving me a warning, maybe rustup target list could have said

$ rustup target list
/usr/bin/rustc threw the following error:
    error: toolchain 'esp' does not support components

but this is all just ideas, I know ultimately it's my fault for not checking the $PATH.

Start by inspecting the generated ~/.cargo/env (or ~/.local/share/cargo/env) script and the behavior of rustup show and rustup target list described in the issue. Determine whether the intended result is path reordering, a rustup warning, or clearer command errors; done should be a decided behavior with coverage for the reported PATH scenario.