The README details `eval`ing `rbenv init -`, but for some shells (such as fish) there's a difference in what should be run. It turns out that `rbenv init` on its own will print correct instructions, so we should point users to running that command instead.
It seems rbenv now comes with ruby-build. I have not investigated fully, but the previously shown command: `brew install rbenv ruby-build` caused issues on my machine. After uninstalling both and simply running `brew install rbenv` everything worked fine.
```
/home/yyuu/.pyenv/versions/3.2.6/lib/python3.2/site-packages/pkg_resources/__init__.py:85: UserWarning: Support for Python 3.0-3.2 has been dropped. Future versions will fail here.
warnings.warn(msg)
```
`default` was made legacy back in 2011 with
5be66da9f4 (the command was renamed from
`rbenv-default` to `rbenv-global`, and so the global file was renamed
from `$RBENV_ROOT/default` to `$RBENV_ROOT/global` (the latter taking
precedence)
`global` was then made legacy about a month later in Sep 2011 when the
preferred filename was changed to `$RBENV_ROOT/version`.
This compiles the `realpath` dynamic extension for bash which speeds up
symlink resolution. If the extension doesn't compile due to
cross-platform issues, rbenv will still work normally, although not as fast.
When invoked from a shell script, `$(rbenv init -)` did not get the
shell name correct.
It needs to look at the `args` value from `ps`.
Ref: https://github.com/yyuu/pyenv/issues/373
The `../libexec` dance isn't necessary here. It was only necessary in
main `rbenv` command because that one might have been pointed to
directly via a symlink.
It doesn't try to chdir into RBENV_ROOT anymore because that might be
a location of an unrelated rbenv install that might have a different
version than the current one that is installed e.g. via a package
manager such as Homebrew.
Now just tries the repo where the source files (`libexec/*`) are
located, and if that isn't a valid rbenv repo, bail out early.
