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

Use `command` to run rbenv rehash

Closes #529

If set by the user's environment, `git config --global` writes will go
to that destination instead of temporary $HOME. We definitely don't want
that.

Fixes #742

rbenv-init: do not use basename for $shell

Include gems dir in .gitignore

add proxy usage note