References #730

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.

No need for helper function that's gonna be used just once.

It's only supposed to be set from `version-origin` hooks, but not
inherited from environment in case it was set.

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.

Fixes #807

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.

Confirms #836

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().

ensure subcommand exists, then include --help in its completion output

- 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.

Broken in dcca61c0bc

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

I was seeing /bin being left.  This patch fixes it by anchoring the search
pattern with ':' on both sides.

The symlinks weren't correctly resolved if they were pointing to a
single path component, such as `ln -s foo bar`.

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.

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

This is useful as an indicator where it is coming from.

Commit e2173df4 (for issue #369) did not handle the fish test properly.

This renames it and fixes the assertion.

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.

This allows rbenv source code to ship with built-in hooks.

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

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

This implements removing of the shims path element via bash
substitution, instead of jumping around in all the `$PATH` elements.

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.

Allows for code to be added to the end of the script which will not
mysteriously fail to run for fish shell.

This prevents the tests from removing an existing directory.

Fixes #561 (https://github.com/sstephenson/rbenv/issues/561)

The non-extended regex pattern didn't work on OpenBSD so this switches
grep to extended pattern mode that seems to work consistenty on all
systems.

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.