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

It's not that this is a preferred way to set a global version (one
should use `rbenv global <version>` instead), but this fixes the
function purely for correctness: all parent directories should be
scanned, even the root directory.

Fixes #745

I was seeing the following occasionally in scripts:

> …/.pyenv/libexec/pyenv-version-file-read: line 12: type: write error: Broken pipe

This patch hopefully improves/fixes this, and it seems better anyway to
just use sed here.

This can be done using bash directly.

When we started to support reading `.ruby-version` files, we made a
commitment to not support fuzzy version matching. Treating "ruby-2.1.5"
as "2.1.5" is a sort of fuzzy matching, so we put in place a warning
telling you to remove the extraneous "ruby-" prefix popularly used by
other Ruby version managers to denote MRI. (Their logic is that MRI is
"ruby" and other rubies are not "ruby", apparently.)

However, people are often not able to remove the prefix in their
projects because they want to support other coworkers and tools that
sadly still require the prefix, like RubyMine.

So to restore sanity for a big portion of our users, the warning is gone.

Display the other available ones still.

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

In the event that `eval "$(rbenv init -)"` is called from a function named
rbenv (which I do to get rbenv to load lazily in my shell), evaluating the
phrase `rbenv rehash` will cause the outer function to run again (causing an
infinite loop).

This change makes it clear you want the command named rbenv and not a function
which may exist in the environment.

This is a follow-up to de5c61c.

This allows rbenv source code to ship with built-in hooks.

This was introduced when merging the rbenv upstream change
(https://github.com/sstephenson/rbenv/commit/6bb7f07d2d).

It doesn't need to be a bash array and we don't need a separate index of
shims registered. Simply keep everything in a space-separated string and
use that as an index as well.

This assumes that executable names *never* have spaces in them.

On my system that has 25 versions under rbenv, this speeds up rehash
almost 3-fold:

- before: 391 ms
- after:  134 ms

This is achieved by removing duplicate names of executables before
registering them as shims. Since most Rubies will share a lot of the
same executable names ("ruby", "rake", "bundle", ...), this is a
considerable reduction in number of shims registered.

Too many of our users have a shell initialization set up that
inadvertently duplicates some or most of the entries in their PATH,
bringing the system paths again in front of rbenv's shims. If this was a
nested shell (a typical scenario when starting up tmux), `rbenv init`
would get eval'd again but this time, shims won't get added to the front
of the PATH and would only stay and the end of the path, effectively
rendering them useless.

I tried to argue that this is a user problem rather than rbenv's, but I
can't fix everybody shell init when they report bugs. Instead, let's
revert to simpler times in rbenv where we just roll along with the
duplication and don't ask any questions.

This reverts commit 03fa148e81.

Fixes #369

Delegate to `rbenv-shims` instead of `rbenv shims` and therefore skip
going through the main `rbenv` executable again that would set up a lot
of the environment that was already set.