Considerations:
- `./libexec/rbenv` executable is the entrypoint to the program;
- BASH_SOURCE might be the path to a symlink that has activated `./libexec/rbenv`;
- We must resolve the symlink to learn where rbenv's libexec directory is;
- It's not guaranteed that rbenv commands will always remain directly under their own "libexec" directory, since a package maintainer can change that, e.g. rbenv commands are sometimes placed into `/usr/libexec/rbenv/*`;
- Resolving symlinks might fail and in that case we just assume rbenv project layout.
The rehash process will now discover executables in additional locations:
- `~/.gem/ruby/<version>/bin/*`
- `$GEM_HOME/bin`
The `rbenv which` (and thus `rbenv exec`) command will also search these locations when looking up a command. This enables shims to dispatch calls to executables added by `gem install --user-install`.
Note that this support is limited:
- It will only work with C Ruby, as it's difficult to guess the `~/.gem/<engine>/<version>` directory for other Rubies without actually loading Ruby;
- It will only work for RBENV_VERSION values in the format `X.Y.Z` and not "system".
This speeds up subsequent `rbenv init -` executions for the user who
followed these instructions because the shell will no longer have to be
detected each time.
A malicious `.ruby-version` file in the current directory could inject
`../../../` into the version string and trigger execution of binaries
outside of `RBENV_ROOT/versions/`.
Fixes#977 OVE-20170303-0004
This suppressed any output when using RBENV_DEBUG=1 and does not really
hurt to have in the unlikely case that it should fail; you would get
two error messages now:
rbenv: ruby: command not found
rbenv: system version not found in PATH
Command `rbenv version-name > .ruby-version` will create an empty `.ruby-version` file
before running `rbenv-version-file`. This causes `rbenv-version-file` to return empty
string which in turn causes `rbenv-version-name` to return `system`.
Ensure size of `.ruby-version` is non-zero as a workaround.
Keeping rbenv-controlled variables to RBENV_* "namespace" helps with
discoverability (and tools like rbenv-env) but also consistency and a
very minor degree of safety/isolation from env impact.
This ensures that OLD_RBENV_VERSION is never exported. This makes the
implementation a little bit more complex, since more logic needs to be
pushed down into eval'd code.
`rbenv shell -` allows you to switch to the previously activated ruby
version. Similar to `cd -` or `git checkout -`.
This tries to implement `rbenv shell -` as proposed in #854. However,
adding support seemed to break the "shell change version" test. I'm not
very good at Bash programming, can someone tell me what is wrong with
what I'm doing? I'd like to add a bit more functionality to this, but
I'm really just cargo cult programming Bash.
Thank you!
fix tests
`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`.
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.
