* robbyrussell/master: (75 commits)
Update custom location command and fix code format
Fix typo.
Fix backwards logic in uninstaller once and for all
Refactor for method in plugins/rake-fast/rake-fast.plugin.zsh
Fix conditional in uninstall prompt
Fix syntax error in confirmation prompt of uninstall.sh
Fix syntax error in #4515 on certain shells
Revert "Make install script safer"
Fix "be" -> "b" typo in coffee plugin README.md.
Make install script safer
[FIX#4525]: Fix typo
Fixd bug for pyenv plugin
Fix install.sh/upgrade.sh for tput-less systems
Check for git before trying to upgrade, as per #4504
Enable pyenv rehash
Init pyenv virtualenvs too
Add option '--port' to 'rails server' alias.
Add an alias for upstream
autoenv: actually source autoenv once located
add alias to sort by version
...
This changeset wraps all of the commands in tools/install.sh in a
function and then calls that function as the last line of the
script.
The current install instructions ask the user to download the install
script using `curl` and pass the result to `sh`. This is totally
fine (as long as both the instructions and the script itself are served
using HTTPS), but the script should be written in a way such that it
doesn't start trying to actually *do* anything until the very last line.
The reason is due to the way `curl` work: if the socket drops before the
request is complete (server abruptly hangs up, client's internet flakes
out, etc.), `curl` will return the partial data that it received. Here
is an example of that:

A way this might cause issues for tools/install.sh is if the connection drops
after cloning but before the repository (L53-56). The .zshrc
configuration will not be copied and the shell will not be changed, but
if the user tries to run the install script again it will claim
oh-my-zsh is already installed (L31-39).
While this is not a particularly dangerous error condition (the user can
just delete .oh-my-zsh and re-run), it can certainly be confusing for
new users. This also helps future-proof the script for a time when it
might need to use a "dangerous" command, e.g. `rm`, and we want to make
sure it happens in the most transactional way possible.
@fcrozat's original fix assumes `which` not to output anything to STDOUT
in case the command is not found. That is not necessarily true on all
systems. A better solution is to check the return value instead.
Fixes#4376