To facilitate migration

PATH manipulation should be done in ~/.profile rather than ~/.*rc since .rc can be sourced multiple times

The generated script does not take/use any arguments, so passing
/bin/zsh to it serves only to cause confusion.

This reverts commit 070e1c859fb2584c3dbe0a6fbe58cbc80938654e, reversing
changes made to 3faeda67bb.

All scripts in libexec/ (excluding pyenv) are called through pyenv,
therefore the shebang lines are not necessary. On some systems this
provides a measurable increase in performance of the shell prompt.

Related to pyenv/pyenv-virtualenv#259

Revert back to original quoting style used before previous commit.
Adjust init.bats to reflect changes for successful tests.

References #730

This seems to have not been merged properly.

A similar issue is with the test for fish, which has been submitted as a
PR for rbenv: https://github.com/sstephenson/rbenv/pull/722.

Commit e2173df4 (for issue #369) did not handle the fish test properly.

This renames it and fixes the assertion.

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.

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

It's slow and not necessary since we expect `$0` to already be expanded.

In tests this change forces us to deal with some relative paths, but
it's not a big deal. The `rbenv init -` output in the most common case
will be the same as before:

    source '/home/myuser/.rbenv/libexec/../completions/rbenv.bash'

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

The error was "bash: no such file or directory" and it was due to bash
being located in `/usr/local/bin` on OpenBSD 5.4 instead of `/bin` like
on other systems.

Fixed by keeping `/usr/local/bin` in PATH during the test run.

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

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

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

Use process subtitution syntax:

    . (rbenv init -|psub)

instead of:

    eval (rbenv init -)

because the latter doesn't work well with newlines.

fixes #444