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

Handle --help flag for subcommands

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.

Removing an extra comma in "There are some systems, where the", and adding another "the" to "toward the end of shell configuration file".

Adding a tip for how to view the Homebrew package caveats again if you skipped reading them.

Directing readers to additional next steps after installing pyenv via Homebrew.

Many advanced users who enjoy reading detailed documentation may not really think of themselves as "neckbeards", even in a jokey way, so naming this section with a simple, familiar (and easy-to-translate!) name may encourage more people to read it. :)

Correcting instructions for installing Python versions (removing "download and unpack the source").

Fixing links to #pyenv-shell, #pyenv-local, and #pyenv-global - linking them to the appropriate sections of the COMMANDS.md page.

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

tests: fix path_without to handle /bin properly

add completion block for rbenv-help

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

Add miniconda*-3.18.3.

List Anaconda-style virtual environments as a version in pyenv

https://bitbucket.org/pypy/pypy/issues/2178/

The binaries of portable-pypy are not yet available, though.

Never use hardlinks. Never.

Add `rbenv versions --skip-aliases` option

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.

Closes #809, references #806

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

Avoid running `rbenv rehash` multiple times during `bundle install`

This avoids running `rbenv rehash` after installing libraries that don't
have executables, or after a no-op `bundle install` that didn't install
anything.

This is an attempt to work around the fact that Rubygems post_install
hooks may happen multiple times per single `bundle install` and ideally
we want `rbenv rehash` to run only once if new gems have been installed.
However, due to Bundler parallelism using `fork` on platforms that
support it, it's impossible for the child processes to communicate with
the master process to signal it to run `rbenv rehash` in the end.

This hooks into Bundler `install` command and runs `rbenv rehash` after
all gems have finished installing, but only if the install location was
system gems location and not a custom path (such as per-project
`vendor/bundle`).

This is limited because we can't tell whether any gems have been
installed at all, let alone do those gems have executables. However it's
better than having multiple `rbenv rehash` being run in parallel and
outputting confusing error messages as a result.

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.

http://fwierzbicki.blogspot.co.uk/2015/10/jython-271-beta2-released.html