ohmyzsh/ohmyzsh: a remote script, a renamed .zshrc, and no release to pin

Installation pipes a remote file into sh

The basic install is one line that hands your shell to a script you have not read:

sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

The wget and fetch variants change only the download flag and point at the same path on master. The file also names a second host, install.ohmyz.sh, as a mirror, and says it may be required if you are in a country like China or India, for certain ISPs, where raw.githubusercontent.com is blocked. The way to see the code first is documented as manual inspection, which is a download and a separate run:

wget https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh
sh install.sh

Consequence: the default path executes unreviewed remote code, the documented alternative is three steps instead of one, and if the URL times out you are told to substitute the mirror, which means the copy you get can depend on which host answered.

Your previous .zshrc is renamed, not merged

The install writes over your shell configuration, and the file is blunt about what happens to the old one. Any previous .zshrc will be renamed to .zshrc.pre-oh-my-zsh, and after installation you can move the configuration you want to preserve into the new .zshrc. There is no merging step in that description, and the announcement does not enumerate what the replacement file contains. Consequence: a shell with a tuned .zshrc comes back holding two files, one renamed and one new, and anything worth keeping has to be moved across by hand after the fact. Go through the backup for PATH lines, alias definitions, completion setup, and any block that configures a specific tool before you decide the new setup is equivalent, since the backup is a single renamed file rather than a record of a shell you had assembled from several fragments.

One comma in the plugins array breaks the load

Plugins are turned on by editing the .zshrc file in $HOME:

vi ~/.zshrc

and listing them in an array:

plugins=(
  git
  bundler
  dotenv
  macos
  rake
  rbenv
  ruby
)

The entries are separated by whitespace, spaces, tabs, or new lines, and the file is explicit that you must not put commas between them or it will break. Consequence: every plugin change is a manual edit to a file that also holds your aliases and environment, and one stray comma takes down the whole plugin block rather than one entry. The README does not say which error zsh prints when that happens, so treat the first shell prompt after each edit as untested until you have read it.

No releases means the auto-updater is the only upgrade path

The repository publishes no GitHub releases, and the project description advertises an auto-update tool that makes it easy to keep up with the latest updates from the community. The table of contents splits updates into two subsections, Updates Verbosity and Manual Updates, which tells you a setting exists for how much the updater reports and a separate path you can drive yourself, though the visible sections name no flag for either one. Consequence: your installation comes from the master branch rather than a release you picked, and when an upstream plugin change alters a prompt, an alias, or a completion you depend on, there is no earlier tag to roll back to. Keep your own copy of the configuration outside the framework so you can rebuild a known good shell.

Themes are plentiful and closed to pull requests

The file admits to having gotten theme-happy early on and states that over one hundred and fifty themes are bundled, most of them with screenshots, while the project description counts 140+ themes and 300+ optional plugins. The table of contents carries a Selecting A Theme section and, further down, one headed Do Not Send Us Themes. Consequence: the theme or plugin you want may live somewhere else and never arrive here, so the expected route is the custom path rather than the contribution path. The top level of the repository carries a custom/ directory next to plugins/ and themes/, and the README has a Custom Plugins And Themes section, so anything not bundled has a home, but a contributor proposing one upstream is working against an explicit refusal.

Windows support means WSL2, and two rows are a joke

Platform support is a table of seven rows. Android, FreeBSD, Linux, macOS, and Windows through WSL2 are marked as supported, LCARS is marked with a spacecraft symbol rather than a check, and OS/2 Warp is marked as unsupported. Consequence: on Windows the supported route is the Linux compatibility layer rather than a native shell, and an install run inside it fetches the same master URL as everywhere else, so you inherit the same remote script execution. The LCARS row, marked with a spacecraft symbol for a fictional operating system, suggests the table is at least partly a joke, so do not read it as a tested support matrix. Treat Linux and macOS as the real targets and everything else as best effort.

Prerequisites give zsh a floor and git a recommendation

The stated prerequisites are short. Zsh should already be installed, v4.3.9 or more recent is fine while 5.0.8 and newer is preferred, and `zsh --version` is offered as the way to confirm which you have. curl or wget should be installed. Git should be installed, with v2.4.11 or higher recommended. Consequence: a distribution still shipping zsh 4.3.x sits at the stated minimum rather than the preferred version and will be running an older shell than the framework prefers. Because the file says git should be installed, check for git before installing rather than after.

Editorial conclusion

Take it if you want a populated shell in one command and do not mind giving up control of your own zsh configuration file, and skip it if you treat .zshrc as code you review, because the installer renames your existing .zshrc and gives you a new one. What to check before you install: that zsh is present, that git is installed rather than merely recommended, and what your current .zshrc contains, since the installer renames it to .zshrc.pre-oh-my-zsh rather than merging with it. Because the repository publishes no releases, also keep your own copy of the configuration that you care about. Themes and plugins are the parts you will actually notice on day one, and the plugin array is the part that will cost you an afternoon the first time a comma sneaks in.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository