zsh as the macOS default shell: what breaks in a script written for bash

What it is

Apple's own support documentation states that, starting with macOS 10.15, zsh is the default login and interactive shell for newly created accounts; accounts carried over from 10.14 or earlier can still have bash as their login shell (check with dscl . -read ~ UserShell). An agent that opens a Terminal-like session on a Mac is therefore usually in zsh, even though /bin/bash is still present for scripts that name it in a shebang. That /bin/bash is frozen at 3.2.57, the last release under GPLv2; bash 4.0 and later are GPLv3, which Apple does not ship.

Why it matters

zsh's default option set differs from bash/POSIX sh in ways that change the result of otherwise-identical-looking code:

• Word splitting: zsh's SH_WORD_SPLIT option, described in the zsh manual as causing "field splitting to be performed on unquoted parameter expansions", is off by default. An unquoted $var containing spaces stays one word in zsh (interactive or script), unlike bash where it splits; unquoted $(...) output is still split. Code ported from bash that relies on that splitting (a longstanding bash/sh idiom) silently does nothing in plain zsh.
• Arrays start at 1: by default zsh numbers array elements from 1; the KSH_ARRAYS option switches to the bash/ksh convention, described in the manual as making "array elements... numbered from zero". Code that assumes arr[0] is the first element reads the wrong element, or an empty one, under default zsh.
• Glob errors instead of a literal string: with zsh's default options, a pattern that matches nothing triggers the NOMATCH behaviour, documented as printing "an error, instead of" leaving the pattern unchanged; bash instead passes the literal, unexpanded pattern to the command unless nullglob/failglob are set. A script assuming the bash default can abort under zsh on a glob that simply matched nothing.

How to apply

• Put an explicit shebang (#!/bin/bash or #!/bin/zsh) on every script instead of relying on the login shell, and run scripts with bash script.sh rather than sourcing them into an interactive zsh session when bash semantics are required.
• If a script must run correctly under both, quote every parameter expansion ("$var") so word-splitting differences never matter, and avoid 0-based array assumptions or test both engines.
• Treat /bin/bash on macOS as a legacy 3.2 build: it predates associative arrays, mapfile, and other bash 4+ features; install a current bash via a package manager if those are needed, and reference it by full path since /bin/bash will not change.

Pitfalls

• Assuming "it's a Mac, it's basically Linux/bash" and pasting a bash-specific script into an agent's default shell on macOS without a shebang.
• Testing only in an interactively configured zsh (with a customized .zshrc that sets KSH_ARRAYS or SH_WORD_SPLIT) and shipping a script that fails under a clean default profile.
• Forgetting that /bin/sh on macOS is by default bash 3.2 running in POSIX mode (since 10.15 it dispatches via /private/var/select/sh, which can be relinked to dash or zsh), with option defaults distinct from both interactive zsh and normal bash.