Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Do not force PATH in the installer #1359

Open
wants to merge 1 commit into
from

Conversation

Projects
None yet

mpapis commented Oct 15, 2012

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" )
@mpapis mpapis Do not force PATH in the installer
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" )
b049410
Owner

robbyrussell commented Dec 1, 2012

@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?

Owner

robbyrussell commented Dec 1, 2012

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 commented Dec 1, 2012

@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 commented Dec 1, 2012

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 commented Dec 3, 2012

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

mpapis commented Dec 9, 2012

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

mpapis commented Feb 8, 2013

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 commented Apr 6, 2013

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

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

wycats commented Apr 9, 2013

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 😦

@envygeeks envygeeks referenced this pull request in rvm/rvm Apr 10, 2013

Closed

rvm install error #1785

I am facing the same issue here =(

mrevd commented Apr 12, 2013

+1

mhumeSF commented May 5, 2013

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

Drewch commented May 7, 2013

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

Contributor

avit commented Mar 8, 2014

@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.

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

+1

Collaborator

mcornella commented May 25, 2014

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

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

Contributor

avit commented Jul 16, 2014

@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.)

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

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!

+1

got the same issue while using RVM , had to comment the PATH in .zshrc file.

pgray commented Apr 3, 2015

Soooo, I tried commenting the PATH line and commands like "bundle" and such wouldn't work.

However, adding "source /home/user/.rvm/scripts/rvm" to the end of my .zshrc seems to have fixed the problem.

@dgcliff dgcliff added a commit to NEU-Libraries/cerberus that referenced this pull request Apr 26, 2015

@dgcliff dgcliff A solution that appears to actually work, found here - robbyrussell/o… 2d2aade
Contributor

apjanke commented Jun 8, 2015

This caused #3960.

On OS X, the /etc/paths.d directories are picked up by the systemwide /etc/* shell rc files and added to $PATH before the user's shell rc file gets called. Grabbing a static copy of the $PATH at OMZ installation time breaks /etc/paths.d; programs using /etc/paths.d that are installed later, or upgraded so that their path changes, are not visible on the path.

This will affect Ruby, golang, XQuartz, and TeX.

lingceng commented Jul 2, 2015

This problem bite me too! Why not merge the request?

Yeah, this is not cool. This causes Macs to ignore /etc/paths.d, which is where new apps are supposed to add paths.

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

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

Contributor

apjanke commented Oct 19, 2015

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`.

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

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

gtmax commented Mar 25, 2016

+1.

@mcornella mcornella reopened this Mar 31, 2016

mpapis commented Apr 1, 2016

should I rebase?

Collaborator

mcornella commented Apr 4, 2016

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

+1

milos-v commented Jun 7, 2016

This one did it for me
stackoverflow

Contributor

apjanke commented Jun 8, 2016

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 commented Jun 12, 2016

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.

Contributor

apjanke commented Jun 12, 2016

@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.

Works for me. Thanks

@mcornella mcornella referenced this pull request Jun 16, 2016

Open

[WIP] Refactor installer #5169

7 of 18 tasks complete

j3rrey commented Sep 21, 2016 edited

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

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment