All scripts in libexec/ (excluding pyenv) are called through pyenv,
therefore the shebang lines are not necessary. On some systems this
provides a measurable increase in performance of the shell prompt.

Related to pyenv/pyenv-virtualenv#259

Ref (abs_dirname in bats): https://github.com/sstephenson/bats/pull/224
Ref: https://github.com/rbenv/rbenv/pull/868

Fixes https://github.com/pyenv/pyenv/issues/580

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.

Otherwise `sed` might not be found later in bats/libexec/bats-exec-test,
in case `/usr/bin` gets removed.

Revert back to original quoting style used before previous commit.
Adjust init.bats to reflect changes for successful tests.

https://travis-ci.org/pyenv/pyenv/jobs/215777826

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.

I need to use release date versioning at least for now until preparing
custom version comparator for brew's formula.

`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

Use extracted create_hook helper in tests for:

- exec
- hooks
- rehash
- version-name
- version-origin
- which

Spaces in hook path is tested in test/hooks.bats

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

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