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.

This implements removing of the shims path element via bash
substitution, instead of jumping around in all the `$PATH` elements.

Running any shim (and thus `rbenv-exec`) would always execute
`rbenv-version-name` twice: once in `rbenv-exec` and another time in
`rbenv-which`, even though RBENV_VERSION variable would have already
been populated at this point.

Now RBENV_VERSION is respected within `rbenv-which`.

Allows for code to be added to the end of the script which will not
mysteriously fail to run for fish shell.

When created on Windows, .rbenv-version or .ruby-version files may have CR characters that will prevent rbenv from correctly parsing the Ruby version. Discard those characters when reading the file.

It seems that "comm" header can't be relied on cross-platform, but that
"ucomm" is more portable. I have no idea whether it's the right value to
use here, but it seems to be doing the job.

Also strip trailing whitespace because OpenBSD 5.4 `ps` output is padded
with spaces for some reason.

Fixes #489

The non-extended regex pattern didn't work on OpenBSD so this switches
grep to extended pattern mode that seems to work consistenty on all
systems.

Fish user config file `~/.config/fish/config.fish` loads for every
instance of fish shell, not just interactive ones. Since it's
unnecessary and dangerous to eval `rbenv init -` output in
non-interactive shells, wrap the invocation in a conditional that checks
if the current shell is interactive.

Fixes #501

It was supposed to fix shelling out to Ruby but it in fact broke another
kind of shelling out to Ruby: invoking the `ruby` binary directly with
the `-S` flag.

Fixes #480

This reverts commit db143bb654.

It doesn't exist as a builtin, and it doesn't seem there is a way to
detect support for a shell builtin that is portable. So, just detect
fish and don't the rehash command at all.

Fixes #478

Process substitution seems to be causing problems with some versions of
bash on specific systems.

Fixes #401

Avoids the case where shell detection would result in
`basename "-bash"` invocation, triggering the error:

    basename: illegal option -- b

fixes #462

`$SHELL` variable is a terrible way of detecting the current shell
because it's not even supposed to reflect the current shell; it's meant
for keeping the value of the default shell for programs to start.

If an explicit `<shell>` argument wasn't passed to `rbenv init`, it
tries to detect the shell by getting the name of its parent process. If
this fails, it falls back on the value of `$SHELL` as before.

Furthermore, `rbenv init` will set the RBENV_SHELL variable in the
current shell to the value of the detected shell so that `sh-shell` and
`sh-rehash` commands don't have to repeat the detection.

Have `rbenv prefix` handle the case where system Ruby is not installed,
i.e. `rbenv which ruby` doesn't find ruby in PATH.

Fixes #362

If `rbenv init -` outputs `.` in place of `source` and that gets eval'd
by the desktop manager via `~/.profile`, it chokes and prevents the user
from logging in.

Fixes #457

ksh syntax becomes:

    function rbenv {
      typeset command

`typeset` only declares a local variable if there's an explicit
`function` declaration; otherwise the variable leaks.

Other shells use this syntax:

    rbenv() {
      local command

This is for dash compatibility, which supports neither `function` nor
`typeset`.

references #205, fixes #408

Use process subtitution syntax:

    . (rbenv init -|psub)

instead of:

    eval (rbenv init -)

because the latter doesn't work well with newlines.

fixes #450

fixes #444

Enables shelling out from a ruby process started with rbenv to a ruby
process with a different RBENV_VERSION. Fixes #121

This removes the workaround created for #15 and solves `ruby -S` support
by setting RUBYPATH. PATH is never changed.

To illustrate how RUBYPATH changes in various configurations:

    PATH=~/bin:~/.rbenv/shims:/usr/bin:/bin
    RBENV_VERSION=1.8 ruby -S rake
    #=> executes ~/.rbenv/versions/1.8/bin/rake
    #=> RUBYPATH=~/bin:~/.rbenv/versions/1.8/bin:/usr/bin:/bin

    RBENV_VERSION=2.0 ruby -S rake
    #=> executes ~/.rbenv/versions/2.0/bin/rake
    #=> RUBYPATH=~/bin:~/.rbenv/versions/2.0/bin:/usr/bin:/bin

    RBENV_VERSION=system ruby -S rake
    #=> executes /usr/bin/rake
    #=> RUBYPATH=~/bin:/rbenv_shims_were_here:/usr/bin:/bin

    RBENV_VERSION=1.8 ruby -S rake
    #=> executes ~/.rbenv/versions/1.8/bin/rake
    #=> RUBYPATH=~/bin:~/.rbenv/versions/1.8/bin:/usr/bin:/bin

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

Enable JavasCript, Lua and Erlang scripts to provide completions

Fixes #344, #196

Fixes #238

In systems that use the MAWK interpreter (the default AWK installed with
Ubuntu), the output of `rbenv help <command>` would have no line breaks.
The issue is fixed by changing `gsub` to `sub` in the snippet of awk
commands that are used to extract documentation comments.

I suspect the bug is something to do with the way the '^' and '$'
characters are interpreted by different AWK interpreters (per-line vs
per-string anchors).

If I understand correctly, the purpose of trim() is to remove all line
breaks from the start and end of each sections of a command's
documentation, in which case `sub` should serve the same purpose.