fish shell: install, configure and decide if it replaces bash or zsh

What fish replaces, and for whom

fish targets the interactive prompt, not the scripting layer. The README describes it as a shell for macOS, Linux and the rest of the family that includes syntax highlighting, autosuggest-as-you-type and tab completions that work with no configuration required. That last clause is the product claim: a fresh install already behaves like a heavily configured bash or zsh.

The audience is people who live in a terminal but do not want to maintain a plugin manager, a prompt framework and a completion package just to get coloured commands and history hints. If your shell usage is mostly running commands, moving around directories, and reading output, fish is aimed at you. If your shell usage is mostly writing portable scripts that run on machines you do not control, it is not. The README points readers to a tutorial and to a phrase to search for, unlike other shells, which is a candid admission that the syntax diverges from the POSIX family rather than a footnote.

How the interactive features are wired

fish ships the pieces that other shells expect you to install. The README lists specific optional dependencies behind specific features: the builtins with a --help option need man to display usage, the fish_config web configuration tool needs Python 3.5 or later plus a browser, the alt-o binding needs the file program, and the default Ctrl-V and Ctrl-X clipboard bindings need xsel, xclip, wl-copy/wl-paste or pbcopy/pbpaste depending on the platform. That list is a useful map of where fish delegates to the system instead of reimplementing it.

Completion generation is the other half. The README states that automated completion generation from manual pages requires Python 3.5 or later, and that full completions for yarn and npm require the all-the-package-names NPM module. So completion coverage is not uniform: some of it is generated from man pages, some is hand-written and shipped in the repository, and some depends on a separate package being installed. The repository layout supports this reading. There is a share/ directory for shipped functions and completions, and the Rust workspace under crates/ holds the engine, with crates/widecharwidth and crates/wcstringutil handling character width and string measurement, which is the kind of detail that decides whether a prompt lines up correctly with wide characters.

On the build side, the project is a Rust workspace with edition 2024 and rust-version 1.85 in Cargo.toml, plus a CMake path that drives the same build. The README notes that PCRE2 headers and libraries are optional because they will be downloaded if missing, and that an Internet connection is needed because other dependencies are downloaded automatically. That is a real constraint for offline or air-gapped builds.

Installing fish and running it for the first time

On macOS the README gives Homebrew as the shortest route. After the command finishes, the fish binary is on your PATH and you can start it without changing your login shell:

brew install fish

MacPorts users have an equivalent, and the README also lists an installer and a standalone app from fishshell.com. The README states the minimum supported macOS version is 10.12.

On Ubuntu, fish publishes a PPA rather than relying on the distribution package. The README gives these three commands in order:

sudo apt-add-repository ppa:fish-shell/release-4
sudo apt update
sudo apt install fish

For Debian, Fedora, openSUSE and Red Hat Enterprise Linux/CentOS, the README points to packages from the openSUSE Build Service and says instructions for other distributions are on fishshell.com. On Windows 10 and 11 the documented route is WSL, using the Linux instructions for the distribution you install, or Cygwin, or MSYS2.

Once installed, the README is explicit about the first step: run fish from your current shell to try it out. That matters because it does not touch your login shell configuration. You get a fish prompt inside your existing session, and closing it returns you to bash or zsh. Only after that trial is it worth deciding whether to make fish the default shell for your account.

Building from source, and why the README warns against it

The README does not present source builds as the normal path. It says that rather than building from source, you should consider a packaged build, and that the steps below make fish difficult to uninstall or upgrade. That is an unusually direct warning. If no package exists for your platform, GPG-signed tarballs are available from fishshell.com and from the GitHub releases page.

Compiling requires Rust 1.85 or later including cargo, CMake 3.15 or later, a C compiler for system feature detection and the test helper binary, and an Internet connection for automatically downloaded dependencies. PCRE2 and gettext are optional. Sphinx is optionally needed to build documentation from a cloned git repository. The CMake build exposes options such as CMAKE_INSTALL_PREFIX, WITH_DOCS, FISH_USE_SYSTEM_PCRE2 and WITH_MESSAGE_LOCALIZATION, plus Rust_COMPILER, Rust_CARGO and Rust_CARGO_TARGET for cross-compilation. There is also a Cargo path, and the README's example uses uv to install Sphinx and notes you can install Sphinx another way and drop the uv run --no-managed-python prefix.

Running the full test suite, per the README, additionally requires diff, git, Python 3.5 or later, pexpect, less, tmux and wget. That is a heavier environment than the shell itself needs, and it is the part most likely to break in a minimal container.

The POSIX boundary is the real limitation

fish is not a drop-in bash replacement and does not try to be. The README's own framing, that fish generally works like other shells with a few important differences documented under the phrase unlike other shells, is the honest summary. The practical consequence is that any script whose shebang is #!/bin/sh or #!/bin/bash is unaffected, but anything that assumes your interactive shell's syntax will break.

This shows up in three places. First, scripts that people source into an interactive session, such as environment setup files, need fish syntax. Second, tools that shell out and expect POSIX behaviour need to be told which interpreter to use. Third, documentation and snippets written for bash will not paste cleanly into fish. None of this is a defect; it is the price of a syntax that the project considers clearer. But it does mean the migration is not symmetric: moving to fish is easy for interactive use and disruptive for anything that treats the shell as a scripting runtime.

The second limitation is dependency drift. Optional features degrade quietly when their dependency is absent. If man is missing, --help output is affected. If no clipboard utility is installed, the default Ctrl-V and Ctrl-X bindings have nothing to call. If Python 3.5 or later is absent, fish_config and man-page completion generation do not work. The README documents these, but nothing in the shell forces you to notice before you hit the missing feature.

fish versus zsh, and the difference that matters

The comparison people actually make is fish against zsh, and the distinction is architectural rather than cosmetic. zsh is broadly compatible with POSIX shell syntax and reaches a comparable interactive experience through configuration: a framework or a hand-written rc file, a prompt theme, a completion system, and plugins for highlighting and suggestions. The defaults are sparse and you build up.

fish inverts that. The README states the features work with no configuration required, so the highlighting, autosuggestions and completions are present on first launch. The cost is that fish's language is its own, and the README points to a tutorial rather than claiming compatibility. So the choice is not which shell has better completions; it is whether you want to pay configuration effort or compatibility. If you have years of bash snippets and sourced scripts, zsh keeps them working and asks you to configure. If you want the behaviour immediately and your scripts already declare their own interpreter, fish gives it to you and asks you to leave those scripts alone.

A second axis is packaging. zsh is typically available from the base repositories of most distributions. For Ubuntu, fish's documented install path is a PPA, which is an extra source to add and trust. That is a small but real operational difference.

Maintenance, releases and licensing

The repository is not archived, and the last push was on 2026-09-09. Releases are frequent: 4.9.1 on 2026-09-04, 4.9.2 on 2026-09-05 and 4.9.3 on 2026-09-08. That cadence is worth knowing before you pin a version, because a pinned package will fall behind quickly and the project does not appear to be in a slow-release phase.

The licence is the part that needs care. The repository metadata reports NOASSERTION, and Cargo.toml spells out the workspace licence as GPL-2.0-only AND LGPL-2.0-or-later AND MIT AND PSF-2.0, with a comment pointing to doc_src/license.rst for details and a reminder to keep COPYING and debian/copyright in sync. A multi-licence expression like that usually means different components carry different terms, and the GPL-2.0-only component is the one that constrains redistribution. If you are embedding fish in a product or shipping a modified binary, read doc_src/license.rst and COPYING rather than relying on the short identifier. This is not legal advice; it is a pointer to where the project says the answer lives.

Editorial conclusion

Adopt fish as an interactive login shell if you want completions, highlighting and autosuggestions without assembling a plugin stack, and you are willing to keep POSIX scripts in bash or sh. Do not adopt it as the interpreter for existing shell scripts or CI steps that assume POSIX syntax, and do not assume a package exists for your distribution. Before switching, verify three things: that your platform has a package or that you can build from source with Rust 1.85 or later and CMake 3.15 or later, that your scripts are invoked with an explicit bash or sh shebang rather than inherited from your shell, and that any tooling which sources shell files can read fish's syntax. Then run fish from your current shell before making it the default.

Frequently asked questions

Official sources

1. fish-shell/fish-shell on GitHub
2. Issues
3. Project website
4. README
5. Releases