Shell integration is not enabled by default. This means that, from all the
commands from `rbenv commands`, only "shell" won't work right away.

Replace "no such command" with a more descriptive message that points to
`rbenv init` instead.

Forwarded from https://github.com/pyenv/pyenv/pull/606.

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

The setenv function in fish shell has changed dramatically in
75600b6b53
It now conforms to the csh version, which takes at most two arguments.
In this init script, the form
    setenv PATH prepend_something $PATH
had been used, which had too many arguments.
Since setenv isn't a native command in fish, a suitable replacement is
to use the "set -gx" command, which can consume multiple arguments.

This prevents CDPATH from becoming an issue.

Closes #866.

- some versions of bash (e.g. 4.3.11) complain about clobbering
  /dev/null, use bash's explicit >| operator to ignore noclober
- not sure if the original #759 report has the same cause
- https://github.com/rbenv/rbenv/issues/759#issuecomment-289326891

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.

The literal tilde in a PATH entry (e.g. `~/.rbenv/shims`) doesn't seem
to be supported by system `which` utility, but *does* seem to be
supported by `command -v` (used in `rbenv-which`) and `type -p`.

Therefore, we must strip away `~/.rbenv/shims` from PATH when looking up
executables for system Ruby, lest we risk infinite loop. We do so by
substituting any occurence of `~` in PATH with the value of `HOME`.

Per [the fish documentation for "source"](file:///usr/local/Cellar/fish/2.2.0/share/doc/fish/commands.html#source) - ". (a single period) is an alias for the source command. The use of . is deprecated in favour of source, and . will be removed in a future version of fish."

`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

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

Handles situation when the output is `/bin/shell- args...`. First strip
away the arguments, then the trailing dash.

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.

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.

fail helper prints message to stderr and exits 1
(prefixes 'rbenv: ' if given a string arg)

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

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

Without it, it falls back to `--version` being executed as a subcommand,
which works but isn't obvious

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