`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.
Expose a `version-origin` hook.
It is invoked *before* the traditional `rbenv-version-file` lookup. Because `version-origin` is traditionally run immediately after `version-name`, then any plugin hooks that alter `version-name` would have done so. Thus, running `version-origin` prior to printing the origin gives those plugins a chance to alter the `version-origin` to match.
If any of the hooks set `$RBENV_VERSION_ORIGIN`, then it is used as the return value. Otherwise, the existing logic continues to return "environment variable" or "filename" as appropriate.
This change, in conjunction with the `version-name` hook, makes a clean seam by which plugins can inject their own ruby version setting logic. Using this seam, as opposed to altering `$RBENV_COMMAND_PATH` from the `which` hook, means that the version name and origin are set more reliably and so `version`, `version-name`, `version-origin` and `which` all work as expected. Indeed, even PS1 works now.
Expose a `version-name` hook.
It is invoked *after* the traditional `RBENV_VERSION` lookup. Which means hook scripts can interrogate `$RBENV_VERSION_FILE` and/or `$RBENV_VERSION` (or use the executables).
The hooks are then run, giving plugins a chance to alter `RBENV_VERSION`. Once the hooks have run, we now have (in `$RBENV_VERSION`) the actual version we want to use (or it's empty which defaults to `system` per normal). Lastly, the same logic remains for checking if the version exists, or trimming the `ruby-` prefix.
Prime example: the ruby-bundler-ruby-version plugin can select a ruby by using the `ruby` directive from the `Gemfile` if a local `.ruby-version` doesn't exist.
Can be used for `.ruby-version` file lookup in the ancestry of a
specific directory. In this mode of operation, global version files
aren't taken into consideration, and the command fails unless a local
version file was found.
This new test was creating an (intentionally invalid) .ruby-version file
in current working directory; typically the rbenv project dir.
Immediately after test runs, I had a leftover .ruby-version file.
The version-file tests create and cd into the RBENV_TEST_DIR as part of
setup(). I'm using the same directory for this test fix, but am only
using it for this particular test. None of the other exec tests seem to
need to be in a temp test dir, so no use putting it in setup().
If subcommand is provided (and exists) and its first arg is -h/--help,
go ahead and intercept the call; redirecting to rbenv-help <subcommand>
This means subcommands and plugins need not handle --help flag
themselves
- Explicitly asking for help with `-h` or `--help` exits with 0 status
and displays help on stdout.
- Not providing any arguments to rbenv results in failure status and
displays version and help on stderr.
