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

...rather than login mode.

I couldn't get rid of the warning that `pyenv init -` no longer sets path until I did this. It looks like setting only on the login shell wasn't enough to hide the warning in other shells I opened. This fits with [how rbenv does the same thing](https://github.com/rbenv/rbenv/blob/master/libexec/rbenv-init#L74).

I'm way out of my depth here, so someone who knows about shell types should definitely review this.

Closes https://github.com/pyenv/pyenv/issues/1921

The $(type -p | head -1) construct expects to always get a path, so need to ignore such aliases with -P

Closes https://github.com/pyenv/pyenv/issues/1662

* Update install instructions for Bash and Zsh

* Synchronize README.md with `pyenv init`
* Add a ~/.bash_profile note
* Concatenate shims activation into installation for brevity
  (Pyenv can't be used meaningfully without shims anyway)
  Otherwise, we'd need to duplicate all the ~/.profile shenanigans in both sections
* Update based on feedback
* Proofread

Our ~/.rc logic must run after the ~/.profile one

including initial PATH and PYENV_ROOT entries.
The migration hint proved to be unclear to users without them.

E.g. for a GUI session, ~/.profile is executed by the GUI login "shell" at its startup
so one needs to fully log out and log back in.
Before that, the change would only be seen by shells explicitly started as login shells.

To facilitate migration

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

With functions, we have more leeway in what to call

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.

For example bash-5.1, bash-static.

Added --nosystem argument to skip the system environment when searching for an executable.

... by unsetting `LC_ALL` and passing `LC_CTYPE=C` to `sed`.

This commit fixes issue #1454.

It's impossible to 100% reliably extract the script argument from the command line for all and unknown Python versions and implementations

This reverts commit 493f036928.

# Conflicts:
#	libexec/pyenv

it allows to see functions as well as lines, therefore making it possible to see the control flow

"hyperfine pyenv-versions" before with my bash 4.4:

Time (mean ± σ):    81.7 ms ±   2.2 ms  [User: 67.8 ms, System: 15.7 ms]
Range (min … max):  78.3 ms …  87.2 ms  34 runs

After:

Time (mean ± σ):    70.6 ms ±   2.4 ms  [User: 55.6 ms, System: 16.9 ms]
Range (min … max):  67.9 ms …  78.9 ms  41 runs

"hyperfine pyenv-rehash" before on my bash 4.4:

Time (mean ± σ):   172.8 ms ±   8.2 ms [User: 185.0 ms, System: 24.8 ms]
Range (min … max): 164.2 ms … 198.4 ms 15 runs

After:

Time (mean ± σ):   113.8 ms ±   2.8 ms [User: 127.1 ms, System: 26.1 ms]
Range (min … max): 108.0 ms … 117.6 ms 25 runs

If pyenv doesn't find an executable for the current version/virtualenv,
then search the "system" version as a fallback.

Try for that long no matter what the sleep step available is.

... which is caused by `realpath.dylib` containing illegal UTF-8 byte sequence, and `LC_CTYPE` won't take effect if `LC_ALL` happens to be set to something other than `C`.

This commit fixes issue pyenv/pyenv#1454.

Ref: https://stackoverflow.com/a/23584470