This facilitates testing of changes to the core installation code: you'll be
able to do a roundtrip test of install and uninstall using the working code on
your branch.
Controlled by passing $REPO and $BRANCH environment variables to install.sh.
This changes the behavior to default to the binary found first in $PATH,
then checking it's actually in the shells file (/etc/shells).
If that fails go back to the previous behavior, but actually check that
the path obtained exists in the filesystem.
Co-authored-by: Joel Kuzmarski <leoj3n@gmail.com>
This replaces the currently running process with the new one using `exec`
instead of creating a new process. This way, when the user `exit`s out of
the new shell it will not pop them back into the shell from which ohmyzsh
was installed from.
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.
