* perf: replace a series of if statements with a case block. Add error
handling for case where unknown option is provided.
Same setup as rbenv-init for reading arguments.

* perf, docs: Recommend users to specify the shell for `pyenv init -`
Speeds up the startup by about 40% (in local testing, from ~50ms to ~30ms).
Reflect this in `pyenv init` hint text.

* style: remove unnecessary `root` variable in pyenv-init
* style: remove unnecessary variable declarations at the top of file in pyenv-init.

* perf: replace `cat <<` calls with `echo`
The builtin `echo` is about 100x faster. In tests, saves about 2-3ms.

* docs: document the `pyenv init - <shell>` performance boost in the Advanced Configuration section.

* style: test_helper.bash: avoid unnecessary ".." in produced PATH

* docs: fix a false statement about completions location in the Advanced Configuration section.

Addendum to #3134 as per https://github.com/pyenv/pyenv/pull/3134#issuecomment-2545710044

Requested in https://github.com/pyenv/pyenv/issues/2680
for deployments with a stock `.pyenv-version` that can use any
of a number of Python versions
and for compatibility with `uv`.

* Support `pyenv local --force`
* Support `pyenv-version-file-write --force`
* Support `pyenv version-name --force`
* Ignore missing versions when searching for executables
* Display "commmand not found" even when there are nonexistent versions

* exec.bats: replace `python` and `rspec` with something that doesn't exist globally, either
in Ubuntu Github CI, `python` exists globally

Since 3.13, CPython is provided in 2 flavors: regular and
free-threaded, with the 't' suffix.

An incomplete prefix ending with '[0-9]t'
resolves only among versions that also end with '[0-9]t'

Fixes use of version specifiers like `python-3.12`, which:
- have an explicit `python-` prefix
- are using a major version alias that has to be resolved
  to an exact version.

Also simplified the conditional for the already
working case, since it had two branches that were virtually identical.

The directory /usr/etc is an optional directory and used by
Fedora, RHEL 9, and openSUSE. The purpose of /usr/etc is to store
distribution-provided configuration files that can be overridden
by user-modified files in /etc.

/usr/etc is not in FHS. However, as Torsten stated in his comment
(https://github.com/thkukuk/atomic-updates_and_etc/issues/2#issuecomment-524848666)
"[FHS] is currently nearly as dead as LSB, we can only ignore it
if we don't want to stop and kill all innovation."

Drop the failing test in favor of a better-written test
that also tests the same

More tailored for the emergent internal use cases

by adding an internal flag

This adds the free-threaded (without GIL) version of 3.13.0b3.

Co-authored-by: Ivan Pozdeev <vano@mail.mipt.ru>

In exceptional cases (custom installation, malfunctions elsewhere), `pyenv-commands --sh` may return nothing.
In non-Fish, this would cause "syntax error near unexpected token `)'" in `pyenv()`.

Bash does not allow to specify a `case` option that would never match.
This works around it by defaulting to `/`. Commands, being filenames, can never match it.
In Fish, nothing needs to be done: it apparently does interpret a `case` without argument as one that never matches.

* Change other tests to use the newly-created convenience function

* Add test, exclude alphas as well

* Resolve version name that hooks see
* Avoid a 2nd iteration over configured versions

Co-authored-by: Ivan Pozdeev <vano@mail.mipt.ru>

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.

* Fixes #2430 while still preventing CVE-2022-35861
* Adds a skipped version message to stderr

Co-authored-by: Ivan Pozdeev <vano@mail.mipt.ru>

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.

Required for diagnostics

`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