Homebrew places the rbenv executable in a location such as
`/usr/local/bin/rbenv`, which is in PATH. However, that is a symlink to
`/usr/local/Cellar/rbenv/<VERSION>/bin/rbenv`, which is itself a symlink to
`/usr/local/Cellar/rbenv/<VERSION>/libexec/rbenv`. Upon executing, rbenv
will add its own directory to PATH so that it can easily invoke its
subcommands.
When generating shims during `rbenv rehash`, rbenv will try to put the
absolute path to itself inside each shim so that shims would work even
if rbenv itself isn't in PATH. Under Homebrew, rbenv's directory will be
the versioned directory in Homebrew's Cellar. However, due to Homebrew's
auto-cleanup functionality, shims generated this way will be broken
after upgrading rbenv because of the versioned Cellar path.
This changes how rbenv discovers itself in PATH: it will look at the
original PATH, not in the one modified by rbenv, with the intention of
excluding results under rbenv's own `libexec/`. If rbenv wasn't found in
PATH, return the absolute path to rbenv's own `bin/rbenv`.
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.
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
- 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.
readlink comes from GNU coreutils. On systems without it, rbenv used to
spin out of control when it didn't have readlink or greadlink available
because it would re-exec the frontend script over and over instead of the
worker script in libexec.
Fixes#389
