* refactor(install.sh): fix static analysis warnings
Clear all warnings and errors raised by shellcheck.net static analysis.
- Replace non-POSIX shell use of `$OSTYPE` by POSIX compliant check on `uname -o`.
- Move variables out of`printf` format string.
- Refactor/simplify string formatters for error and underline.
- Fix expansion of arguments to a single string `$*` rather than individual elements `$@` within the error and underline formatters.
* fix(uname): non-posix -o option
* fix(install.sh): non portable which
Replaced non-portable `which zsh` by portable `command -v zsh`
* Don't error on upgrade no-op
No error code is required for a non failure scenario.
* Manually check whether changes were pulled in `omz update`
Co-authored-by: Marc Cornellà <hello@mcornella.com>
This also allows the option to put extra paragraphs after the BREAKING CHANGE
message while properly displaying the breaking change message. Useful, for
example, to add signed-off or co-authored lines.
I used _ which is a convention in other languages, but in shell scripting
$_ is a special variable set by the shell, and in Zsh versions older than
5.0.6 it complains for being a `read-only variable`.
Fixes#9482
* Suppress the problematic trap output in check_upg
The newly added trap, in systems where `rm` is aliased to `rm="rm -v"`,
shows a message stating that "update.lock" has been removed each time `zsh` is called.
I simply suppressed it with directing the output to `/dev/null`.
* Use `command` instead of >/dev/null to suppress
If I have custom configs (like theme customizations) I have to stash my changes and get them back after the update.
By adding the --autostash on upgrade.sh, if I have any changes not commited they'll be reapplied after the upgrade, allowing me to have temporary customizations without any harm to the upgrade process.
If there's no `~/.shell.pre-oh-my-zsh`, don't assume the default choice
is Bash. In fact Zsh is the default shell for macOS since Catalina
(10.15) [1], yet users of other OSes have likely to have Bash as their
default.
This commit fix issue #8252
[1] https://support.apple.com/en-us/HT208050
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.
