Skip to content
New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

release: Trouble with bash/zsh finding the GOPATH #11052

Closed
stuartweir opened this issue Jun 4, 2015 · 7 comments
Closed

release: Trouble with bash/zsh finding the GOPATH #11052

stuartweir opened this issue Jun 4, 2015 · 7 comments

Comments

@stuartweir
Copy link

I just purchased a new MacBook Pro, and installed Go via the go1.4.2.darwin-amd64-osx10.8.pkg package on the downloads page. in my zshrc file, I have set the GOPATH and PATH as such:

# set Golang working directory
export GOPATH=/Users/Stuart/go
export PATH=$PATH:$GOPATH/bin

however when I am in zsh (or bash) and I type which go, I do not get a PATH printout at all for bash, and I just get go not found if using zsh.

When I check to see if /etc/paths.d/ has a file named go, it does (which apparently means everything installed correct. What I don't understand is when I set the exact same working directory shown above on my old machine, it worked without a hitch.

Lastly, if I manually do an export PATH=$PATH:/usr/local/go/bin on the zsh/bash command line and then type which go, the PATH is set until I close the terminal window.

If you have any other questions, please feel free to ask! I want to get this solved 😄

-Stu.

@davecheney
Copy link
Contributor

@adg as a bit of background, this issue arose from a conversation I had with Stuart on twitter. I've seen another report (don't have the url handy) on golang-nuts of a similar problem, so consider this issue a reminder to someone, probably me, to check that the 1.4.2 installer is working on the latest os x 10.10.x.

Specifically if /etc/paths.d/ doesn't work with zsh, I think our options are limited, but it used to work properly with the default os x shell.

@davecheney davecheney added this to the Go1.5Maybe milestone Jun 4, 2015
@davecheney davecheney self-assigned this Jun 4, 2015
@stuartweir
Copy link
Author

Thanks @davecheney for taking this on. For reference, this is OS X 10.10.3 that the new MacBook Pro is running.

@stuartweir
Copy link
Author

Actually, coming to think of it, my old MacBook Air was running OS X 10.10.3 too...so maybe it doesn't have to do with the OS?

@stuartweir
Copy link
Author

Hey @davecheney, so it seems there is a direct issue with (possibly) both bash and oh-my-zsh. I used prezto and it works! (https://github.com/sorin-ionescu/prezto) This means that if others are having issues, this may be a possible solution.

-Stu.

@stuartweir stuartweir reopened this Jun 4, 2015
@stuartweir
Copy link
Author

Leaving this open for official comment unless you wish to close it @davecheney.

@ianlancetaylor ianlancetaylor changed the title Trouble with bash/zsh finding the GOPATH release: Trouble with bash/zsh finding the GOPATH Jun 4, 2015
@apjanke
Copy link

apjanke commented Jun 8, 2015

FYI: All the shells shipped with OS X, including zsh, work fine with /etc/paths.d, and your installer is probably fine. Like Stuart says, this is an issue specifically with oh-my-zsh. The OMZ installer modifies the installing user's ~/.zshrc in a way that breaks /etc/paths.d, by clobbering $PATH with a static copy of its value as of the time of installation. The symptoms of this are that later-installed programs that use the /etc/paths.d mechanism will not be picked up for that user.

(Prezto probably "works" just by undoing the OMZ breakage. Installing OMZ or fixing the user's ~/.zshrc should work too.)

If you run in to this in the future, first thing to do is probably check for OMZ and/or a broken ~/.zshrc or other user shell rc file. The paths from /etc/paths.d are added by the system-wide /etc/zshenv, /etc/profile, or /etc/csh.login rc files. If the user's shell rc file sets the path like the following, but does not include $PATH itself, that breaks inheritance of the system-wide path definitions.

# BUG! This will break /etc/paths.d
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/usr/texbin:
# Okay:
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/usr/texbin:$PATH

I don't know what the issue with bash would be. (Unless you were getting in to bash by running a non-login bash from within a broken zsh session, which would have just inherited this ~/.zshrc breakage?)

@davecheney
Copy link
Contributor

@apjanke thanks for your detailed explanation. It sounds like oh-my-zsh has got some usability issues.

I'm closing this as there is nothing that the Go installer can or should do in this circumstance.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants