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.
If set by the user's environment, `git config --global` writes will go
to that destination instead of temporary $HOME. We definitely don't want
that.
Fixes#742
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.
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
This is the remaining part of
c69d9a1128.
commit c69d9a1128
Author: Mislav Marohnić <mislav.marohnic@gmail.com>
Date: Mon Oct 13 12:39:47 2014 +0200
Isolate rbenv-which tests from any `.ruby-version` file on the system
Having a `.ruby-version` file in any of the parent directories of the
local clone of rbenv could cause the test suite to fail because it
wasn't expecting a local version to be set.
Having a `.ruby-version` file in any of the parent directories of the
local clone of rbenv could cause the test suite to fail because it
wasn't expecting a local version to be set.
Fixes#533
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`.
The previous Makefile only worked on OS X. The dynamically generated
Makefile (from `Makefile.in`) should now work on multiple platforms
(tested on OS X and Ubuntu).
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'
With `realpath` extension, hooks tests on OS X will output
`/private/tmp` instead of `/tmp` because the latter is an actual symlink
to the former.
Avoid this mistmach in output assertions by expanding BATS_TMPDIR if
`realpath` extension is compiled.
On other systems, we expected to find system Ruby in `/usr/bin`, but in
OpenBSD 5.4 it will be found in `/usr/local/bin`.
This replaces the limited USRBIN_ALT hack with a more generic
`path_without` function that will ensure that the given executable is
not present in the resulting PATH even if it's found in multiple
system paths.
The error was "bash: no such file or directory" and it was due to bash
being located in `/usr/local/bin` on OpenBSD 5.4 instead of `/bin` like
on other systems.
Fixed by keeping `/usr/local/bin` in PATH during the test run.
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
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
