Many advanced users who enjoy reading detailed documentation may not really think of themselves as "neckbeards", even in a jokey way, so naming this section with a simple, familiar (and easy-to-translate!) name may encourage more people to read it. :)
Correcting instructions for installing Python versions (removing "download and unpack the source").
Fixing links to #pyenv-shell, #pyenv-local, and #pyenv-global - linking them to the appropriate sections of the COMMANDS.md page.
If `foo` didn't exist and `RBENV_VERSION=system rbenv which foo` was
called, the error message used to be misleading:
rbenv: version `system' is not installed
Instead, have the error message simply say that the command was not found.
Fixes#770
Useful in combination with `--bare` to list just the unique version
numbers without the extra directory entries that are symlinks to other
version numbers in the same directory.
This is for Linux desktop platforms that have Terminal application
configured to start shells in interactive but not login mode. Creating a
`~/.bash_profile` would also cause `~/.profile` to not run, which might
be a problem on Ubuntu which ships with a default `~/.profile`.
This avoids running `rbenv rehash` after installing libraries that don't
have executables, or after a no-op `bundle install` that didn't install
anything.
This is an attempt to work around the fact that Rubygems post_install
hooks may happen multiple times per single `bundle install` and ideally
we want `rbenv rehash` to run only once if new gems have been installed.
However, due to Bundler parallelism using `fork` on platforms that
support it, it's impossible for the child processes to communicate with
the master process to signal it to run `rbenv rehash` in the end.
This hooks into Bundler `install` command and runs `rbenv rehash` after
all gems have finished installing, but only if the install location was
system gems location and not a custom path (such as per-project
`vendor/bundle`).
This is limited because we can't tell whether any gems have been
installed at all, let alone do those gems have executables. However it's
better than having multiple `rbenv rehash` being run in parallel and
outputting confusing error messages as a result.
When `rbenv --version` is called, this now happens:
1. It changes into the directory where `libexec/rbenv--version` resides
and checks if it's a checkout of the rbenv repo (as opposed to
Homebrew checkout or something else). Then it reads the git revision.
2. If that failed, change to `$RBENV_ROOT` directory and repeat step 1.
If set by the user's environment, `git config --global` writes will go
to that destination instead of temporary $HOME. We definitely don't want
that.
Fixes#742
