Install bash with Homebrew

Project links

• Homepage

Commands and aliases

• bash
• bashbug

Project history

The GNU Bash manual describes Bash as the shell for the GNU operating system and explains that its name is a pun on the Bourne shell, the traditional Unix shell written by Stephen Bourne. Chet Ramey's Bash information page describes Bash as a complete implementation of the IEEE POSIX and Open Group shell specification with interactive command-line editing, job control, history substitution, brace expansion, and many other features.

Bash became the practical GNU answer to `/bin/sh`: compatible enough for shell scripts, featureful enough for interactive use, and free software under the GNU General Public License. The official Bash page identifies the Savannah repository as the main Git repository and the GNU FTP area as the archive for previous releases.

Bash history is also readline history. The package's interactive identity is built around line editing, history, completion, job control, shell variables, functions, and startup files. The official manual's startup-file section documents the familiar split between login files such as `~/.bash_profile`, `~/.bash_login`, and `~/.profile`, interactive non-login `~/.bashrc`, and non-interactive `BASH_ENV`.

Adoption history

Bash became standard infrastructure across GNU/Linux distributions. Chet Ramey's distribution notes state directly that Bash is the standard shell on GNU/Linux systems, and the batch input shows it packaged across Alpine, Homebrew, Debian, Fedora/DNF, MacPorts, Nix, Arch, Ubuntu, and openSUSE.

Its adoption also spread beyond GNU/Linux. The official Bash page documents Bash in BSD ports/packages, macOS as `/bin/sh` and `/bin/bash` beginning with Jaguar/Mac OS X 10.2, Solaris, AIX, HP-UX, Minix, Cygwin, and Windows Subsystem for Linux environments. The same page notes Apple's long-lived Bash 3.2 choice, which made Homebrew and MacPorts important for users who wanted newer Bash on macOS.

Bash also became a de facto automation substrate. Makefiles, configure scripts, release scripts, CI pipelines, container entrypoints, package build recipes, dotfiles, and system administration scripts often assume either POSIX shell behavior or Bash-specific extensions. That ubiquity is why a shell package can be both boring and critical.

How it is used

Users run Bash interactively as a login shell or terminal shell, execute scripts with `bash script`, use it as a POSIX-like `/bin/sh` implementation when invoked that way, and customize sessions through startup files. The manual documents command invocation, startup-file behavior, variables, builtins, functions, shell expansions, redirection, job control, completion, and POSIX mode.

For package managers, Bash is also build infrastructure. Formulae, ports, distro build scripts, test harnesses, and upstream install scripts routinely rely on it. Installing Bash from Homebrew on macOS is a common way to get a newer GNU Bash than Apple's system `/bin/bash`, while Linux packages keep it in the base system dependency graph.

Why package nerds care

Bash is package-nerd bedrock. It is not just a package you install; it is a package many other packages assume exists during configure, build, test, install, and runtime scripting. A broken Bash upgrade can affect interactive users, init scripts, CI jobs, package formulas, and build systems all at once.

It is also one of the clearest examples of interface stability as a cultural contract. Bash has POSIX compatibility, decades of scripts, GNU extensions, platform-specific patches, startup-file expectations, and security-sensitive parsing behavior. Package maintainers care about patch levels, default paths, shell registration, codesigning or sandbox constraints on macOS, and whether `/bin/sh` points to Bash, dash, or another shell.

Historically, Bash carries the GNU/Linux story in one executable: free replacement shell, interactive convenience layer, script language, and distribution default. It is why package nerds still argue about Bashisms, POSIX portability, shebangs, `/usr/bin/env bash`, and whether a script really needed Bash in the first place.

Timeline

• 1980s: Bash is created as the GNU Project's Bourne-Again SHell, a free software shell in the Bourne shell lineage.
• 1994: GNU FTP archive lists Bash 1.14-era release artifacts.
• 1996: GNU FTP archive lists Bash 2.0.
• 2004: GNU FTP archive lists Bash 3.0.
• 2006: Bash 3.2 appears; this line later becomes important on macOS.
• 2009: GNU FTP archive lists Bash 4.0.
• 2019: GNU FTP archive lists Bash 5.0.
• 2022: GNU FTP archive lists Bash 5.2.
• 2025: GNU FTP archive lists Bash 5.3.
• 2026: Chet Ramey's Bash page identifies Bash 5.3 as the current version and points to the Savannah Git repository for patched current sources.

Related projects

• Directly related shells and standards include the Bourne shell, POSIX `sh`, ksh, csh, zsh, dash, and fish. Bash is also tightly connected to GNU Readline, GNU coreutils-era shell scripting, Autoconf-style configure scripts, ShellCheck, shfmt, and the large ecosystem of Bash completion packages.

Sources

• Official Bash information page describes Bash as the GNU Project's Bourne Again SHell, a POSIX/Open Group shell implementation with editing, job control, history substitution, brace expansion, GPL licensing, current version, repository, release archives, and distribution notes.
• Official Bash manual documents the Bourne-Again SHell name, GNU shell role, invocation, startup files, `~/.bashrc`, login files, and `BASH_ENV`.
• Official GNU FTP archive lists historical Bash release artifacts from 1.14, 2.0, 3.x, 4.x, 5.0, 5.1, 5.2, and 5.3.
• input.source_facts.package-manager lists broad package-manager coverage across Linux distributions, BSD-adjacent package systems, Homebrew, MacPorts, and Nix.