PATH not set post installation on OS X 10.11.4

[slayerjain]

The installer said it would set the path, after installation, but even after installation there's no sign of rustup.

[brson]

I've made some changes to this code recently, so I wonder if it broke.

For reference, here's the post-install text:

To get started you need Cargo's bin directory in your `PATH`
environment variable. Next time you log in this will be done
automatically.

To configure your current shell run `source ~/.cargo/env`.

So what's supposed to happen is that next time you log out of the OS (or reboot), the cargo, rustc, rustup etc. commands should work. Your ~/.profile file should have a line in it now modifying PATH that the OS reads during login.

Have you logged out and logged back in yet? If you do that do the commands work? Was it unclear that you needed to log out?

[mxhold]

Ah I was confused by the same thing.

I've installed other tools in the past that on post-install try to add to the PATH automatically by appending to ~/.bashrc or some other file that is read whenever a new shell is started (rather than just on login). So I opened a new shell, tried to run cargo, and it failed. I checked ~/.bashrc, ~/.zshrc, and ~/.zshenv (where I usually append to PATH), saw nothing was at the bottom, and then assumed something went wrong and rustup did not attempt to add anything to my PATH.

To make matters worse, since I'm using zsh as my shell, ~/.profile would not be loaded even if I did login again.

I think it might be clearer if the post-install text at least indicated how rustup added Cargo's bin directory to the PATH since it can be done in many ways and not all shells load ~/.profile on login. This would allow users to correct the file and add the EXPORT to the right file.

Alternatively, rustup could entirely avoid appending to any file and just alert the user on post-install that it's up to them to add the Cargo bin directory to their PATH. While this requires more effort on the user, it seems less likely to cause problems.

Thanks for your work on rustup by the way! It makes installing rust even easier. =)

[Digipom]

I can confirm this is an issue for me as well; Terminal is reading ~/.bash_profile, not ~/.profile. This seems to be true even after logging out and logging back in.

[Digipom]

I checked what MacPorts does as they need to update the path as well:

• If the shell is tcsh, then it will use setenv to update the path, otherwise, if the shell is bash, then it'll use export, otherwise the install script fails..
• If using tcsh, then it will export to .tcshrc first if it exists, otherwise .cshrc, otherwise .tcshrc if neither exist.
• If using bash, then it exports to .bash_profile if it exists, otherwise .bash_login, otherwise .profile if the first two don't exist.

I'm not as familiar with linux; would this logic make sense there, too? The man page for bash on OSX says that

After reading [/etc/profile], it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable.

I also found this helpful: http://stackoverflow.com/questions/18773051/how-to-make-os-x-to-read-bash-profile-not-profile-file

[brson]

For some reason I recall having difficulties detecting the user's preferred shell, like maybe SHELL wasn't set when piping curl | sh, not sure.

Since it doesn't hurt to append to PATH redundantly I'm still a bit in favor of appending to every relevant file we can locate that already exists, plus unconditionally appending to ~/.profile (which still seems to be the most correctish file to put this). The downside I see to this is that it could look a bit WTF for the installer to say 'I just appended the same crap to 5 files'.

[tafia]

I confirm the issue on my system as well

[Frijol]

not working for me either, on OSX 10.10.5

[durka]

On my system the installer updates ~/.profile but my shell runs ~/.bash_profile. Maybe rustup could internally start a new shell, see if the PATH modification worked, and if not back out the change and say "sorry, I tried, but you need to figure out where to put source $HOME/.cargo/env"?

[mikeyb]

In the same boat it seems. Need to write to ~/.zprofile but don't see the option to

[johnthagen]

I have the same issue on 10.11.6, .bash_profile rather than .profile needed to be updated.

[dylanmc]

I just had this problem on 10.12.3. The tools get installed in ~/.cargo/bin, and that directory is in my PATH, but the installer fails with this message.

[ColtHands]

Quick fix:

1. open terminal
2. go to preferencies
3. choose your profile (default)
4. open tab called "Shell"
5. add run command on start "source $HOME/.cargo/env"

if your terminal configured to your username and you are an admin this should work, but this is just a quick fix

My OS is 10.11.5

Also check what profile you are using, you can configure one and might end up using some other.

I see that that's the case to some people, so if you use .bash_profile instead of .profile, or the other way around (or any profile for that matter).

Just put export PATH="$HOME/.cargo/bin:$PATH" in your profile.

[haydenholligan]

This happened to me today. While a quick fix is helpful to have, this should be fixed

[workingjubilee]

So, #2387 fixes this... sortof.
You see, it fixes it on new versions of Mac, and most versions of Linux and FreeBSD as well. .bash_profile was never really the intended home for environment variables, especially not on GUIs, for bash. Mostly that is what .bashrc is for.

Old versions of Mac OSX have an aberrant behavior regarding this, compared to other versions of bash. Newer versions, I think at least since Catalina, have a more normal behavior, partly because they use zsh as their default (which favors .zshenv), but I am given to understand that new bashes for Mac are also fixed, and just in general I am not aware of anything actually stopping you from installing a new bash on an older Mac.

So, two ways forward:

1. If rustup wishes to support older versions of Mac's bash, even though they use an aberrant behavior, that will increase the code complexity. However, I would consider it reasonable to author such a fix, except that I don't have spare old Macs lying around so I am suspicious of testing it. If anyone wishes guidance in implementing this patch, I can pair with them on this. @ me on Discord or something.
2. rustup can decide that, since everyone involved admitted it was a mistake, essentially, and that this is fixable, that this is Clearly Not Their Problem.

[durka]

Can you clarify "new" and "old" versions of OSX? How long ago did the behavior change?

…

On Thu, Jun 25, 2020 at 10:55 PM Jubilee ***@***.***> wrote: So, #2387 <#2387> fixes this... sortof. You see, it fixes it on new versions of Mac, and most versions of Linux and FreeBSD as well. .bash_profile was never really the intended home for environment variables, especially not on GUIs, for bash. Mostly that is what .bashrc is for. Old versions of Mac OSX have an aberrant behavior regarding this, compared to other versions of bash. Newer versions, I think at least since Catalina, have a more normal behavior, partly because they use zsh as their default (which favors .zshenv), but I am given to understand that new bashes for Mac are also fixed, and just in general I am not aware of anything actually stopping you from installing a new bash on an older Mac. So, two ways forward: 1. If rustup wishes to support older versions of Mac's bash, even though they use an aberrant behavior, that will increase the code complexity. However, I would consider it reasonable to author such a fix, except that I don't have spare old Macs lying around so I am suspicious of testing it. If anyone wishes guidance in implementing this patch, I can pair with them on this. @ me on Discord or something. 2. rustup can decide that, since everyone involved admitted it was a mistake, essentially, and that this is fixable, that this is Clearly Not Their Problem. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#371 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAALPH7THBNUWI2VHUHWJQLRYQE2VANCNFSM4CCIDAKA> .

[workingjubilee]

After discussion and a slight shift in architecture for the patch, this might wind up fixed anyways, so posting might have been premature! ¯_(ツ)_/¯

However, for information:
My understanding is that the default "Terminal" app and a few other GUI terminals on MacOSX before Catalina would exhibit the decision of loading .bash_profile on start, while others would load .bashrc (the behavior across Linux GUI terminals), which resulted in a lot of confusion. So the complication is trying to make sure the problem is solved for both without causing unnecessary duplications inside PATH, which dramatically hoses the terminal when it happens.

However, we did land on a decision that will address that, and we decided that, because there were other things causing a similar conflict, we will have to do it anyways.

However, as of Catalina, there was a changeover to always loading .bashrc on startup of a GUI terminal, which is the convention for GUI terminals.

[BrianQueen]

To configure your current shell, run: source $HOME/.cargo/env ...this command FINALLY completed the painful installation of Rust. Uuuuugghhh!