This early return made it so the lock wasn't removed, therefore locking out
the upgrade script from ever entering the upgrade routine.
Fixes#6138
Note: the logic needs some rework.
* Updating Oh My Zsh shop URLs
Linking directly to the Oh My Zsh inventory vs the top-level store with non-OMZ items.
* Updating link to Oh My Zsh products in the install script
* Updating link to Oh My Zsh shop products in the upgrade script
* Getting rid of 't-' in shirts for now
`[Oh My Zsh] Would you like to check for updates? [Y/n]: ` does not make sense,
since answering yes will download/apply the new updates instead of checking for them.
When the user is asked to update oh-my-zsh it says "[Oh My Zsh] Would
you like to check for updates? [Y/n]:". When the user agreed to update
the next text would say "Upgrading Oh My Zsh" which is inconsistent
with the question.
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
* Balk at incompatible Windows/MSYS git
* Test for chsh presence before trying to use it
* Replace non-portable `[[ ... ]]` and `[ x = *pattern* ]` constructs
