rbenv rehash on El Capitan does not working

[alec-c4]

Hi,
After installation of gems like rails and bundle, that need to share their executables in shims directory and running rbenv rehash - nothing happens, there are no executables in shims directory :(

[mislav]

Ouch! Are there any executables when you list ls rbenv root/versions/*/bin? What's your rbenv --version?

[MatthewMDavis]

Seemingly related: my 'rbenv version' output is currently as expected: 2.2.1. But my 'ruby --version' output is 2.0.0p645, which appears to be El Capitan system ruby.

[harrigan]

Same here. After installing rbenv and ruby-build through GitHub checkout, ruby --version showed El Capitan's system Ruby. However, installing rbenv through Homebrew worked for me.

[MatthewMDavis]

For me, the problem was related to PATH variables getting screwed up after Apple moved /etc/zshenv path-setting info to /etc/zprofile.

See thoughtbot/dotfiles#421

After moving /etc/zprofile back to where it was under Yosemite, i.e., /etc/zshenv, everything went back to normal.

[purcell]

Add setopt no_global_rcs to your .zshenv to avoid Apple's global config from clobbering your path settings after your personal config has been loaded by zsh.

[mislav]

@MatthewMDavis I really don't condone any of these suggested zsh fixes. I would leave /etc/zprofile untouched on El Capitan, and instead configure rbenv in ~/.zshrc.

[MatthewMDavis]

@mislav, I've seen your spirited advocacy elsewhere on this topic, and you
obviously know more about this than I do. I won't encourage anyone to adopt
such scandalous measures. For my part, I needed to get my rbenv working
again, and I did, and until I see an industry-wide proper fix, I'll stick
with what's working.

On Thu, Oct 8, 2015 at 4:52 PM, Mislav Marohnić notifications@github.com
wrote:

@MatthewMDavis I really don't condone any of these suggested zsh fixes. I
would leave /etc/zprofile untouched on El Capitan, and instead configure
rbenv in ~/.zshrc.

—
Reply to this email directly or view it on GitHub
#781 (comment).

[mislav]

@MatthewMDavis Sure. I'm glad you solved it, I just wanted to point out to others that sudo moving a system /etc/zprofile file is not the approach I would want them to take.

[metaskills]

Maybe this is something related to the init script? When I run it, I see the following:

$ eval "$(rbenv init -)"
rbenv: no such command `sh-'

[mislav]

@metaskills Which rbenv --version do you have? Can you paste the output of rbenv init -? What is your $PATH?

[metaskills]

Well, before posting I had pulled the latest from master, I am also using ZSH too.

I did some reading on the thoughtbot link @MatthewMDavis posted and hacked my fix by commenting out the path_helper line in /etc/zprofile and then adding that same line right before my ZSH env's line for rbenv like so.

eval `/usr/libexec/path_helper -s`
eval "$(rbenv init -)"

I feel this was the least best temporary hack till I get my bearings around the issue more and learn a better way. Before and after, my output ofrbenv init- was the same, se below.:

$ rbenv init -
export PATH="/Users/kencollins/.rbenv/shims:${PATH}"
export RBENV_SHELL=zsh
source '/Users/kencollins/.rbenv/libexec/../completions/rbenv.zsh'
rbenv rehash 2>/dev/null
rbenv() {
  local command
  command="$1"
  if [ "$#" -gt 0 ]; then
    shift
  fi

  case "$command" in
  rehash|shell)
    eval "`rbenv "sh-$command" "$@"`";;
  *)
    command rbenv "$command" "$@";;
  esac
}

Thanks so much for posting back @mislav, huge fan and thanks for the work!

[metaskills]

I also want to point out that my issue was not with rehash but was with initializing rbenv and getting the path all set. Perhaps we should rename this issue's title?

[mislav]

I did some reading on the thoughtbot link @MatthewMDavis posted and hacked my fix by commenting out the path_helper line in /etc/zprofile and then adding that same line right before my ZSH env's line for rbenv like so.

Thoughbot people are also wrong about this thoughtbot/dotfiles#426

It's not that complicated. Please follow these steps and see if it fixes things:

1. Revert your /etc/zprofile to system setting (i.e. not rename it, not comment it out)
2. Do your PATH initialization in ~/.zshrc not ~/.zshenv. Don't call path_helper manually.
3. That's it!

[metaskills]

Confirmed, that was the best fix! Had to do some cleanup on my side including where I was not adding $HOME/.rbenv/bin at the right place. All in all, my kit and rbenv are working like a champ and are stronger for it :) Thanks @mislav

[MatthewMDavis]

@mislav, simply moving the rbenv init to .zshrc is working, which is great.
I remember that

a. it didn't work way back when, and
b. the zsh documentation was pretty insistent that .zshenv was the place
for path manipulation (although you've shown contrary zsh scripture in your
discussions with thoughtbot, I see)

I assume that a. is now fixed because path_helper is working in a sane
fashion and was not back then. Do you have any insight into what the zsh
people were warning about with path-setting so late in the init process,
and why it's not actually an issue?

On Sun, Oct 11, 2015 at 5:48 AM, Ken Collins notifications@github.com
wrote:

Confirmed, that was the best fix! Had to do some cleanup on my side
including where I was not adding $HOME/.rbenv/bin at the right place. All
in all, my kit and rbenv are working like a champ and are stronger for it
:) Thanks @mislav https://github.com/mislav

—
Reply to this email directly or view it on GitHub
#781 (comment).

[metaskills]

the zsh documentation was pretty insistent that .zshenv was the place for path manipulation...

I remember that too, it was one reason I had all the path stuff as part of the env.

[mislav]

zsh documentation itself fails to leave strong advice about this and the community is generally undecided. But it all makes sense if you look at the list of configuration files that zsh loads in interactive + login mode (default mode for shells in Terminal on OS X):

1. /etc/zshenv - older versions of OS X used to call path_helper here but it wasn't a good call since it runs for nested invocations of zsh as well, manging PATH within subshells/executables
2. ~/.zshenv - not a good idea to set custom PATH because see next step
3. /etc/zprofile - El Capitan calls path_helper, reorders existing PATH by putting system in front
4. ~/.zprofile
5. /etc/zshrc
6. ~/.zshrc - better place to finish up setting USER path
7. /etc/zlogin
8. ~/.zlogin

But basically for your login shell you could just as well do all your configuration in ~/.zprofile or ~/.zlogin, it doesn't make much difference. ~/.zshrc is good because it runs for all interactive shells, so for instance it sets up shell functions and aliases if a new zsh shell is spawned from a different shell — not typical usage but you should keep that in mind.

[metaskills]

@mislav Do you think moving to zshrc vs zshenv for path stuff will impact Pow? I can't seem to get rbenv to work now with it.

[mislav]

It might; I don't use Pow so I didn't notice. Pow does a hack where it executes your login shell to look for your environment variables. This is rougly what it does:

login -qf $LOGNAME "$(dscl . -read /Users/$LOGNAME UserShell | awk '{print $2}')" \
  -i -c 'env' | grep ^PATH

Can you execute that and check if rbenv shims directory appears correctly in PATH and that it has precedence over system paths?

[metaskills]

I'm not sure where I would, in my own terminal window the shims path will of course be higher up. The problem is the context of what Pow is doing. It shows that the System ruby is being used meaning it is never executing thing in my zshrc. Basically just like my terminal before moving things to zshrc vs zshenv. If I comment out eval/usr/libexec/path_helper -s``in/etc/zprofile, Pow works again. Hope that was helpful info.

[mislav]

@metaskills You can run that command in your own terminal window because it will start a new environment within and ignore the calling environment. So it doesn't matter that the PATH in your terminal is already set up.

Also, if you pass -x in the command above, you will get verbose output of everything that is executed during login shell startup. You can then inspect that (often very long) output and see exactly what was changed and when. Let us know what you find!

[metaskills]

Thanks @mislav I did indeed see the shims path way up at the top of my path above system ones. Does that tell you anything? Still can only get Pow working with my hack above.

[mislav]

Hm, not sure what's wrong in Pow then. Which version do you use?

You can always create a page in your webapp that echoes ENV["PATH"] to the browser so that you can inspect the order of paths and see if rbenv shims are there. I'm guessing that /usr/bin takes precedence over rbenv shims, but I don't know why.

[hmaack]

@mislav 👍

[meetajhu]

After installing zsh i too had issue with switching ruby version under 10.11 El capitan

I added this line into my .zshrc file

eval "$(rbenv init -)"

and restarted terminal was able to switch versions. Thanks @mislav

[mislav]

@alec-c4 I'm sorry that we hijacked your original report to talk about unrelated issues. Do you still have the original problem of running rbenv rehash and no shims get generated in the ``rbenv root/shims directory? Is it possible that you have two different installations of rbenv somehow? If there is no further info, I'll be closing this issue since there's nothing I can do about this.

[Prajna]

@mislav Sorry, I'm a newbie here. Would you please tell me how I should modify /etc/zprofile?
It's like this on my machine:

# system-wide environment settings for zsh(1)
if [ -x /usr/libexec/path_helper ]; then
    eval `/usr/libexec/path_helper -s`
fi

[mislav]

@Prajna Your /etc/zprofile is fine; you don't need to edit it! It was only necessary to rename it from /etc/zshenv on older versions of OS X. They fixed it in El Capitan.

I'm closing this issue since this is a user configuration issue and nothing I can do from rbenv.