`which` has been deprecated in Debian's debianutils 5.0+
They suggest using `type` and `command` as replacements:
3a8dd10b45 ,
610a65c6ef

since there proved to be to many cases to fit

Arch Linux has Python is sbin as well as bin

Arch Linux has Python is sbin as well as bin

* In some cases (Ubuntu), `pyenv init -` has to be run before `pyenv init --path`.
* The warning has served its purpose by now.

PEP 394 now doesn't require `python` presence or specify what it is.
Tests that invoke it use Py3-specific code.

To facilitate migration

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

Sometimes it is convenient to be able to temporarily disable something
in a version-file. Because these files often aren't necessarily tracked
in a SCM, especially when working with virtualenvs, the SCM diffs won't
help with showing removed lines which are currently the only way to
disable something.

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

This reverts commit 438e828eb5.

# Conflicts:
#	test/pyenv_ext.bats

The test "prefix for system in /" is duplicated in test/prefix.bats.
Both tests are completely identical. This commit removes the
duplication.

It appears that the culprit is this merge from rbenv/master, from 2016:

  cf1beda362

With the current development version of bats, this leads to the
following error when running `make test`:

  Error:
  Duplicate test name(s) in file
  "/home/travis/build/pyenv/pyenv/test/prefix.bats":
  test_prefix_for_system_in_-2f

Note that the development version is what pyenv's Makefile uses. With
the latest release of bats, the duplication only leads to a warning:

  bats warning:
  duplicate test name(s) in /src/test/prefix.bats:
  test_prefix_for_system_in_-2f

* Update help docs to clarify multiple version(s) are allowed

* Tweek version(s) help description

Using `exec -a` caused Python to use $PATH to look up the full program name (for
`sys.executable`), which 314937d then tried to fix by changing $PATH
also for the system version.
This is not necessary anymore when not using the short name with `exec`.

This was rejected upstream
(https://github.com/rbenv/rbenv/pull/1089#issuecomment-394531896), since
it is not a problem with Ruby apparently.

Uses $PYENV_ROOT to check if system version is used.

Fixes https://github.com/pyenv/pyenv/issues/98.
Fixes https://github.com/pyenv/pyenv/issues/789.

This was imported semi-automatically in 0965577, but `ruby -S` is
different from `python -S`.

`ruby -S`: look for the script using PATH environment variable
`python -S`: don't imply 'import site' on initialization

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

Ref (abs_dirname in bats): https://github.com/sstephenson/bats/pull/224
Ref: https://github.com/rbenv/rbenv/pull/868

Fixes https://github.com/pyenv/pyenv/issues/580

Command `rbenv version-name > .ruby-version` will create an empty `.ruby-version` file
before running `rbenv-version-file`. This causes `rbenv-version-file` to return empty
string which in turn causes `rbenv-version-name` to return `system`.

Ensure size of `.ruby-version` is non-zero as a workaround.

Otherwise `sed` might not be found later in bats/libexec/bats-exec-test,
in case `/usr/bin` gets removed.

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

https://travis-ci.org/pyenv/pyenv/jobs/215777826

Keeping rbenv-controlled variables to RBENV_* "namespace" helps with
discoverability (and tools like rbenv-env) but also consistency and a
very minor degree of safety/isolation from env impact.

This ensures that OLD_RBENV_VERSION is never exported. This makes the
implementation a little bit more complex, since more logic needs to be
pushed down into eval'd code.