When running `eval "$(pyenv init -)"` to initialize `pyenv`, the command
generates a shell script to be executed. When not using the `fish`
shell, this script contains a `case` statement where the first case
matches against the output of `pyenv-commands --sh` and the second case
handles everything else. However, if no commands are returned, then the
matching expression will be only `)`, which is invalid Bash.
I have solved this (on the advice of @ native-api) by using the string
`/` if there are no commands to include. `/` is the only character in
Linux/POSIX besides `\0` that a filename cannot contain, so it is safe
to use as a pattern that will never match. To catch any regressions, I
have added a test to catch unexpected changes in the generated `case`
statement. I copied the `create_executable` function from `latest.bats`
because I needed to shim `pyenv-commands`.
I do not know if `pyenv-commands --sh` can ever return nothing under
normal conditions, but it happened to me due to completely unrelated
problems in underlying Unix utilities called by `pyenv`. Although this
bug will rarely occur, I feel that this increased robustness will be
useful.
* Support ksh versions
Korn shell had two major versions: ’88 and ’93. Some systems have
ksh installed under the name `ksh93`. A few systems (maybe only
Solaris now) also have a `ksh88`. A few others use the `pdksh` (’88)
or `mksh` (’93) implementations, originated before ksh was open source.
Limit to currently-used versions
---------
Co-authored-by: Kevin Schoedel <kps@datatravelandexperiments.com>
In some advanced shell setups, the order of custom-added PATH entries is important.
We disregard it by default, always pushing shims to the front of PATH,
to ensure that Pyenv works even in poorly maintained shell environments
and with minimal hassle for non-export users
(an attempt to do the opposite (#1898) has ended in a disaster).
Some advanced users are however ready and able to carefully maintain their environment
and deal with breakages and inconvenience. This option is for them.
We're going to eliminate the need to mandatorily use `pyenv init --path`.
We can't delete it yet for backward compatibility.
Besides, there's one other use case for it: to enable shims but without
shell integration, e.g. for noninteractive shells.
To be a full-fledged replacement for `pyenv init -` however,
it needs to do rehashing.
Now the setup is to add to both rc and profile:
1) set PYENV_ROOT
(can do it unconditionally -- since if you change it,
you need to update all places anyway since any of them can be run first)
2) Add `pyenv` to PATH if not already there
3) eval "$(pyenv init -)"
Not a breaking change, old setup will continue to work.
...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.
* 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
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.
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
