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.
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.
If `foo` didn't exist and `RBENV_VERSION=system rbenv which foo` was
called, the error message used to be misleading:
rbenv: version `system' is not installed
Instead, have the error message simply say that the command was not found.
Fixes#770
Useful in combination with `--bare` to list just the unique version
numbers without the extra directory entries that are symlinks to other
version numbers in the same directory.
This is for Linux desktop platforms that have Terminal application
configured to start shells in interactive but not login mode. Creating a
`~/.bash_profile` would also cause `~/.profile` to not run, which might
be a problem on Ubuntu which ships with a default `~/.profile`.
When `rbenv --version` is called, this now happens:
1. It changes into the directory where `libexec/rbenv--version` resides
and checks if it's a checkout of the rbenv repo (as opposed to
Homebrew checkout or something else). Then it reads the git revision.
2. If that failed, change to `$RBENV_ROOT` directory and repeat step 1.
It's not that this is a preferred way to set a global version (one
should use `rbenv global <version>` instead), but this fixes the
function purely for correctness: all parent directories should be
scanned, even the root directory.
Fixes#745
When we started to support reading `.ruby-version` files, we made a
commitment to not support fuzzy version matching. Treating "ruby-2.1.5"
as "2.1.5" is a sort of fuzzy matching, so we put in place a warning
telling you to remove the extraneous "ruby-" prefix popularly used by
other Ruby version managers to denote MRI. (Their logic is that MRI is
"ruby" and other rubies are not "ruby", apparently.)
However, people are often not able to remove the prefix in their
projects because they want to support other coworkers and tools that
sadly still require the prefix, like RubyMine.
So to restore sanity for a big portion of our users, the warning is gone.
In the event that `eval "$(rbenv init -)"` is called from a function named
rbenv (which I do to get rbenv to load lazily in my shell), evaluating the
phrase `rbenv rehash` will cause the outer function to run again (causing an
infinite loop).
This change makes it clear you want the command named rbenv and not a function
which may exist in the environment.
It doesn't need to be a bash array and we don't need a separate index of
shims registered. Simply keep everything in a space-separated string and
use that as an index as well.
This assumes that executable names *never* have spaces in them.
On my system that has 25 versions under rbenv, this speeds up rehash
almost 3-fold:
- before: 391 ms
- after: 134 ms
This is achieved by removing duplicate names of executables before
registering them as shims. Since most Rubies will share a lot of the
same executable names ("ruby", "rake", "bundle", ...), this is a
considerable reduction in number of shims registered.
Too many of our users have a shell initialization set up that
inadvertently duplicates some or most of the entries in their PATH,
bringing the system paths again in front of rbenv's shims. If this was a
nested shell (a typical scenario when starting up tmux), `rbenv init`
would get eval'd again but this time, shims won't get added to the front
of the PATH and would only stay and the end of the path, effectively
rendering them useless.
I tried to argue that this is a user problem rather than rbenv's, but I
can't fix everybody shell init when they report bugs. Instead, let's
revert to simpler times in rbenv where we just roll along with the
duplication and don't ask any questions.
This reverts commit 03fa148e81.
Fixes#369
Delegate to `rbenv-shims` instead of `rbenv shims` and therefore skip
going through the main `rbenv` executable again that would set up a lot
of the environment that was already set.
Running any shim (and thus `rbenv-exec`) would always execute
`rbenv-version-name` twice: once in `rbenv-exec` and another time in
`rbenv-which`, even though RBENV_VERSION variable would have already
been populated at this point.
Now RBENV_VERSION is respected within `rbenv-which`.
It's slow and not necessary since we expect `$0` to already be expanded.
In tests this change forces us to deal with some relative paths, but
it's not a big deal. The `rbenv init -` output in the most common case
will be the same as before:
source '/home/myuser/.rbenv/libexec/../completions/rbenv.bash'
On systems that support both C compiling and dynamic loading, we can
speed up `realpath()` (where most time in rbenv is spent) by replacing
it with a dynamically loaded bash builtin.
When `make -C src` is called in the project's root,
`libexec/rbenv-realpath.dylib` will be created. If it exists, rbenv will
attempt to load it as a builtin command. If it fails, execution will
fall back to the old `realpath()` shell function.
When created on Windows, .rbenv-version or .ruby-version files may have CR characters that will prevent rbenv from correctly parsing the Ruby version. Discard those characters when reading the file.
finding_local_version_file is extremely slow, when working directory is under the UNC path.
Because //host/.rbenv-version and //.rbenv-version do not exist, but testing them is so slow.
It's the reason to make a serious delay of the response, when the Ruby runs with a current working directory under the UNC path under Cygwin environment.
A response of before applying this patch.
//somehost/somedir $ time ruby -e "exit"
real 0m13.922s
user 0m0.168s
sys 0m0.287s
A response of after applying this patch.
//somehost/somedir $ time ruby -e "exit"
real 0m0.721s
user 0m0.153s
sys 0m0.319s
It seems that "comm" header can't be relied on cross-platform, but that
"ucomm" is more portable. I have no idea whether it's the right value to
use here, but it seems to be doing the job.
Also strip trailing whitespace because OpenBSD 5.4 `ps` output is padded
with spaces for some reason.
Fixes#489
Fish user config file `~/.config/fish/config.fish` loads for every
instance of fish shell, not just interactive ones. Since it's
unnecessary and dangerous to eval `rbenv init -` output in
non-interactive shells, wrap the invocation in a conditional that checks
if the current shell is interactive.
Fixes#501
It was supposed to fix shelling out to Ruby but it in fact broke another
kind of shelling out to Ruby: invoking the `ruby` binary directly with
the `-S` flag.
Fixes#480
This reverts commit db143bb654.
It doesn't exist as a builtin, and it doesn't seem there is a way to
detect support for a shell builtin that is portable. So, just detect
fish and don't the rehash command at all.
Fixes#478
`$SHELL` variable is a terrible way of detecting the current shell
because it's not even supposed to reflect the current shell; it's meant
for keeping the value of the default shell for programs to start.
If an explicit `<shell>` argument wasn't passed to `rbenv init`, it
tries to detect the shell by getting the name of its parent process. If
this fails, it falls back on the value of `$SHELL` as before.
Furthermore, `rbenv init` will set the RBENV_SHELL variable in the
current shell to the value of the detected shell so that `sh-shell` and
`sh-rehash` commands don't have to repeat the detection.
If `rbenv init -` outputs `.` in place of `source` and that gets eval'd
by the desktop manager via `~/.profile`, it chokes and prevents the user
from logging in.
Fixes#457
ksh syntax becomes:
function rbenv {
typeset command
`typeset` only declares a local variable if there's an explicit
`function` declaration; otherwise the variable leaks.
Other shells use this syntax:
rbenv() {
local command
This is for dash compatibility, which supports neither `function` nor
`typeset`.
references #205, fixes#408
Enables shelling out from a ruby process started with rbenv to a ruby
process with a different RBENV_VERSION. Fixes#121
This removes the workaround created for #15 and solves `ruby -S` support
by setting RUBYPATH. PATH is never changed.
To illustrate how RUBYPATH changes in various configurations:
PATH=~/bin:~/.rbenv/shims:/usr/bin:/bin
RBENV_VERSION=1.8 ruby -S rake
#=> executes ~/.rbenv/versions/1.8/bin/rake
#=> RUBYPATH=~/bin:~/.rbenv/versions/1.8/bin:/usr/bin:/bin
RBENV_VERSION=2.0 ruby -S rake
#=> executes ~/.rbenv/versions/2.0/bin/rake
#=> RUBYPATH=~/bin:~/.rbenv/versions/2.0/bin:/usr/bin:/bin
RBENV_VERSION=system ruby -S rake
#=> executes /usr/bin/rake
#=> RUBYPATH=~/bin:/rbenv_shims_were_here:/usr/bin:/bin
RBENV_VERSION=1.8 ruby -S rake
#=> executes ~/.rbenv/versions/1.8/bin/rake
#=> RUBYPATH=~/bin:~/.rbenv/versions/1.8/bin:/usr/bin:/bin
readlink comes from GNU coreutils. On systems without it, rbenv used to
spin out of control when it didn't have readlink or greadlink available
because it would re-exec the frontend script over and over instead of the
worker script in libexec.
Fixes#389
In systems that use the MAWK interpreter (the default AWK installed with
Ubuntu), the output of `rbenv help <command>` would have no line breaks.
The issue is fixed by changing `gsub` to `sub` in the snippet of awk
commands that are used to extract documentation comments.
I suspect the bug is something to do with the way the '^' and '$'
characters are interpreted by different AWK interpreters (per-line vs
per-string anchors).
If I understand correctly, the purpose of trim() is to remove all line
breaks from the start and end of each sections of a command's
documentation, in which case `sub` should serve the same purpose.
