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.

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

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.

BASH_SOURCE might be more reliable.

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.

Closes #725

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

`PYENV_FILE_ARG` is used here to make use of `abs_dirname` later in
`libexec/pyenv`.

Fixes https://github.com/yyuu/pyenv/issues/404

This is required for the shims to handle `#!/usr/bin/env python3` in a
shebang, just like `python` is handled currently: it will set
`PYENV_DIR` to the root of the invoked script, which is required for a
`.python-version` script to get picked up from there.

This was rejected for rbenv, where it does not make much sense
(https://github.com/sstephenson/rbenv/pull/735).

Ref: https://github.com/yyuu/pyenv/pull/368#issuecomment-102806837