Do not force PATH in the installer

[mpapis]

The installer forced PATH - this prevents PATH dynamically set by system, also forces any temporary user PATH that was set during installation to be recorded and used on every shell start.

It should be users conscious choice to manipulate PATH, a lot of users is not aware of this and do not even know if this good or not.

If users need to add something to PATH they should do it by adding it not overwriting system detected PATH:

PATH="$PATH:/user/custom/path"

or:

path+=( "/user/custom/path" )

[robbyrussell]

@mpapis I've not heard many people complain about this. The purpose behind retaining what was currently in the $PATH is that we're trying to avoid people having shit break when they're installing OhMyZsh for the first time (as we're assuming you're someone who is working with bash... and if you lose your PATH and/or aren't that shell savvy, you'll be confused why things aren't working)

Someone with more know can still modify this after-the-fact, no?

[robbyrussell]

Happy to discuss this further, but am not convinced yet (as we're assuming a PATH was already defined to their liking and we're just retaining that)

[mpapis]

@robbyrussell it works as long you have static environment, but for dynamic environment's it's a headache, you predefine the PATH with something that was already loaded, like selecting environment for some tools like RVM - the selected environment is recorded this way and forced only partially on user without his knowledge why his tools fail, in case of RVM that would be recorded PATH without recording GEM_PATH - they have to be set together for proper effect. I hit this issue about two times a week it's confusing as the tool is on PATH but it can not be properly initialized because of the missing GEM_PATH.

Does this forcing PATH give you any advantage - I do not understand how hardcoding PATH would help anyone, if the PATH is "broken" during installation - you would record the broken PATH.

Finally a script installed in /etc/profile.d/*.sh is allowed to change the PATH - some systems load it for both ZSH and BASH, and you just broke it because you overwrite the dynamically calculated PATH given by system.

[mpapis]

one more, the users that have issues with it explain it:

it was there - there has to be some reason why it was there, I will not remove it because something can break

I need to explain it to every of them from scratch ... at least now I can point them to this ticket

[mpapis]

@robbyrussell so the issue rvm/rvm#1351 is a real life example of the problem caused by forcing PATH - please reconsider fixing this

[mpapis]

@robbyrussell ping - so this does not get lost in history

[mpapis]

following @postmodern advice posting steps to reproduce the problem:

$ rvm use 1.9.3 --default
$ rvm use 1.8.7
$ curl -L https://github.com/robbyrussell/oh-my-zsh/raw/master/tools/install.sh | sh

open new terminal:

$ echo $PATH
/path/to/ruby-1.8.7/bin:...
$ echo $GEM_PATH
/path/to/ruby-1.9.3:...

as you can see they are inconsistent because the PATH was recorded and dynamic checking did not work

so after installing OH-MY-ZSH it is hard coded and no other tool can add itself to the PATH.

[mpapis]

a regular reminder to reopen this - just had another user with the same problem, removing the hard coded PATH fixes it always, we even had to implement a warning for it because this problem was so often - https://github.com/wayneeseguin/rvm/blob/master/scripts/notes#L160-L183

[carllerche]

I've hit this issue as well. So has @wycats.

[wycats]

Confirm. I'm surprised you don't consider this a serious issue. It's driving me crazy 😦

I have added rvm reload to my .zshrc 😦

[christophrumpel]

I am facing the same issue here =(

[rattlion]

+1

[mhumeSF]

This breaks my rvm as well. Removing hard-coded $PATH from PATH=... fixed things.

[Drewch]

I've had this problem as well, each Ubuntu server I spin up and install rvm on I have to change the PATH=/my/path/here/by/default
to:
PATH=$PATH:/my/path/here/by/default

Note that:

PATH=/my/path/here/by/default:$PATH

will NOT fix the issue, it must be the former.

Here is my path after both settings:

https://gist.github.com/Drewch/5534745

[avit]

@robbyrussell I'm thinking to submit a patch for this that will grep the user's existing ~/.bashrc ~/.profile and grab any PATH entries from there instead of the heavy-handed literal expansion we're doing here.

[drewhammond]

Ran into this problem as well on an RVM installation on OS X mavericks

[abotalov]

+1

[mcornella]

Please see pull request #2589 and see if it works for you.

[connor11528]

I'm getting this error on a fresh os x mavericks running oh-my-zsh:

Upgrade Notes:

/Users/connorleech/.zshrc:54:export PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin"

  * WARNING: Above files contains `PATH=` with no `$PATH` inside, this can break RVM,
    for details check https://github.com/wayneeseguin/rvm/issues/1351#issuecomment-10939525
    to avoid this warning append #PATH.

What do I have to change in what file? I don't want my rvm breaking

[avit]

@jasonshark In your case it looks like you can just remove that line 54 from your .zshrc. None of the paths in that error message are custom additions, so it's basically just doing the expansion of PATH="$PATH" unnecessarily.

(There's also a proposed patch to the oh-my-zsh installer in #2589 if you want to test that branch for us.)

[connor11528]

ok cool. commented out line 54 in ~/.zshrc and warning disappeared. Thank you!

[LandonSchropp]

I commented on this over at #2589 and was pointed here. I don't understand @robbyrussell's reasons for not setting the path dynamically. I spent a couple hours trying to figure out what was wrong with my rbenv install before I stumbled onto this. As @mpapis said, for those of us with dynamic environments this is a huge pain.

It seems wrong to comment out the path in the .zshrc file. That code belongs to Oh My ZSH, and by changing it I'm taking ownership of it. I'd prefer to keep all of my zsh config in the custom directory where it belongs. I wouldn't be so opposed to hardcoding $PATH if it were set in the .zshrc file before the custom config were loaded, because then I'd at least be able to add to it.

@robbyrussell, can you please elaborate a little more on why you won't consider this approach? Thanks in advance!

[jessiahr]

Looks like I am running into this issue while using RVM. Any update on a fix?

[coding-bunny]

Seeing as this is not getting fixed, uninstall oh-my-zsh till it actually works....

[apjanke]

You don't need to uninstall Oh My Zsh. Just correct the $PATH in your ~/.zshrc, possibly by just moving your old ~/.zshrc back and copying the OMZ initialization code to it. This change only happens at installation time, and OMZ is fine running with a dynamically-set $PATH.

You can also avoid the problem by doing a manual installation by cloning the OMZ repo to ~/.oh-my-zsh and adding export ZSH=~/.oh-my-zsh; source$ZSH/.oh-my-zsh/oh-my-zsh.shto your existing~/.zshrc`.

[coding-bunny]

yea, or the project could you know....be fixed and support everything as it should be.

[jairojunior]

+1

[yucombinator]

This just fixed my rails after hours of digging. +1

[gtmax]

+1.

[mpapis]

should I rebase?

[mcornella]

No need, sorry, I just reopened this again to signal that it's not solved yet.

[diegomelo182]

+1

[lasernite]

+1

[milos-v]

This one did it for me
stackoverflow

[apjanke]

This one did it for me

/etc/paths is a system-level configuration file. OMZ is more of a user-level shell customization framework; it probably shouldn't be modifying /etc/paths, or doing anything that requires modification of it.

[milos-v]

Well OMZ is not changing it. I changed the order of paths in the file like it says here:

open your /etc/paths file, put /usr/local/bin on top of /usr/bin

Not sure how it relates to the issue honestly but the issue is gone.

[apjanke]

@milos-v Right. I'm saying you shouldn't have had to do that in the first place. And also that, even if that act worked for you, OMZ shouldn't do the same thing.

But moreover, the problem in this issue report occurs when you:
a) run the OMZ installer, and then later:
b) do something that changes /etc/paths.d
or
c) share your ~/.zshrc between machines with differing /etc/paths.d states
If you didn't do these two things, you're probably not looking at quite the same issue as this bug report.

[cristophergalarce]

Works for me. Thanks

[hayesmaker]

+1

[j3rrey]

+1 found this as a workaround https://github.com/postmodern/chruby

[CodyLeeWhite]

This problem is to much trouble. uninstalling as it appears a fix will not be made. I should not have to manually edit ohmyzsh to get my path to work with it.

[dehengxu]

You should comment the rvm related lines in ~/.zshrc, it works for me.

[mcornella]

This was fixed in #4925. I don't know why I kept it open so long.