macOS has shipped zsh as the default login shell since Catalina, yet /bin/bash on a current Mac is still version 3.2. Explain both facts and what they mean for shell scripts you ship to Macs.

## Fact one: the default login shell is zsh Starting with macOS Catalina (10.15, 2019), new user accounts get `/bin/zsh` as their login shell. Accounts that existed before an upgrade keep whatever they had, which is why on a long-lived machine you still meet people whose Terminal opens bash. macOS nudges them: an interactive bash session prints a notice saying zsh is now the default, suppressible with `BASH_SILENCE_DEPRECATION_WARNING=1`. Changing your own login shell is `chsh -s /bin/zsh`, and the target must be listed in `/etc/shells` — which is exactly why a Homebrew-installed bash or fish has to be added to that file before `chsh` will accept it. For a Linux engineer arriving on a Mac, the practical differences at the prompt are mild — zsh is close enough to bash for interactive use that most muscle memory survives — but zsh is a *different language* for scripting, with its own array indexing and its own word-splitting rules. That is why nobody writes portable scripts against zsh, and it does not affect scripts at all as long as they carry a shebang. ## Fact two: /bin/bash is frozen at 3.2 bash 4.0 was relicensed under GPLv3, and Apple does not ship GPLv3 software. So macOS's bundled bash stopped at 3.2, released in 2007, and it is still 3.2 on current macOS. The same licensing decision explains the wider shape of the macOS command line: a BSD userland instead of GNU coreutils, an ancient bundled bash, and no bundled GNU toolchain. Apple's own path forward was zsh, which is permissively licensed and could be updated freely. bash remains for compatibility with the enormous number of existing `#!/bin/bash` scripts. ## What bash 3.2 does not have This is the part that produces real bugs, because the script *starts* and then fails somewhere in the middle: - **Associative arrays** — `declare -A map` is bash 4. On 3.2 you get an error, and the workaround is usually a different data structure entirely. - **`mapfile` / `readarray`** — bash 4. Read a file into an array with a `while read` loop instead. - **Case-conversion parameter expansion** — `${var^^}` and `${var,,}` are bash 4. Use `tr` on 3.2. - **`globstar`** — recursive `**` matching is bash 4. Use `find` instead. - **`wait -n`**, waiting for the first of several background jobs, is bash 4.3. A script that uses any of these works perfectly on the author's Linux box and dies on a Mac, often only on the branch that uses the feature. ## Choosing the shebang ```bash #!/bin/bash # macOS: guaranteed bash 3.2 #!/usr/bin/env bash # first bash on PATH — the Homebrew bash 5 if installed #!/bin/sh # POSIX shell semantics, no bash extensions at all ``` `#!/usr/bin/env bash` is the common recommendation because it lets a modern bash win, but be honest about the tradeoff: it makes the script's behaviour depend on the caller's PATH. On a Mac with `brew install bash` and the prefix ahead of `/usr/bin` you get bash 5; on a clean Mac you silently get 3.2 again. It buys you a *chance* at bash 4+ features, not a guarantee. If a script genuinely requires bash 4 or newer, say so and check: ```bash if (( BASH_VERSINFO[0] < 4 )); then echo "this script needs bash 4 or newer; try: brew install bash" >&2 exit 1 fi ``` Failing loudly at line 3 beats failing obscurely at line 300. ## The confusion worth pre-empting People conflate the login shell with the script interpreter. They do not interact. If your login shell is zsh and you execute a file whose shebang is `#!/bin/bash`, the kernel runs bash — your interactive shell has no say. Conversely, changing someone's login shell fixes nothing about a script that fails on bash 3.2. The only case where the login shell matters is when you *source* a file into the current shell rather than executing it. ## Installing a modern bash ```bash brew install bash # bash 5 under the Homebrew prefix $(brew --prefix)/bin/bash --version ``` Homebrew installs it into its own prefix; it does not and cannot replace `/bin/bash`, which lives on the read-only system volume. To make it a login shell, add its path to `/etc/shells` and then `chsh -s`. Anything with a hard `#!/bin/bash` shebang will still use Apple's 3.2 — installing bash 5 changes what *your PATH* resolves, not what the OS uses.