zsh als Standard-Shell unter macOS: Was in einem für bash geschriebenen Skript nicht mehr funktioniert

Worum es geht

Laut Apples eigener Support-Dokumentation ist zsh ab macOS 10.15 die Standard-Login- und interaktive Shell für neu angelegte Accounts; von 10.14 oder früher übernommene Accounts können weiterhin bash als Login-Shell haben (Prüfung mit dscl . -read ~ UserShell). Ein Agent, der auf einem Mac eine Terminal-ähnliche Sitzung öffnet, befindet sich daher in der Regel in zsh, auch wenn /bin/bash weiterhin für Skripte vorhanden ist, die es in der Shebang-Zeile angeben. Dieses /bin/bash ist auf Version 3.2.57 eingefroren, das letzte Release unter GPLv2; bash 4.0 und neuer stehen unter GPLv3, das Apple nicht ausliefert.

Warum es wichtig ist

Die Standardoptionen von zsh unterscheiden sich von bash/POSIX sh auf eine Weise, die das Ergebnis von scheinbar identischem Code verändert:

• Wortaufteilung (Word Splitting): Die zsh-Option SH_WORD_SPLIT, im zsh-Handbuch beschrieben als Ursache dafür, dass "field splitting to be performed on unquoted parameter expansions" stattfindet, ist standardmässig ausgeschaltet. Ein nicht in Anführungszeichen gesetztes $var mit Leerzeichen bleibt in zsh (interaktiv oder im Skript) ein einziges Wort, anders als in bash, wo es aufgeteilt wird; die Ausgabe von nicht in Anführungszeichen gesetztem $(...) wird dagegen weiterhin aufgeteilt. Aus bash übernommener Code, der sich auf diese Aufteilung stützt (ein altbekanntes bash/sh-Idiom), tut in reinem zsh stillschweigend nichts.
• Arrays beginnen bei 1: Standardmässig nummeriert zsh Array-Elemente ab 1; die Option KSH_ARRAYS schaltet auf die bash/ksh-Konvention um, im Handbuch beschrieben als "array elements... numbered from zero". Code, der arr[0] als erstes Element annimmt, liest unter Standard-zsh das falsche oder ein leeres Element.
• Glob-Fehler statt Literal-String: Mit den Standardoptionen von zsh löst ein Muster, das nichts trifft, das Verhalten NOMATCH aus, laut Dokumentation die Ausgabe eines Fehlers ("an error, instead of" ...), statt das Muster unverändert zu lassen; bash dagegen übergibt das unexpandierte Muster wörtlich an den Befehl, sofern nullglob/failglob nicht gesetzt sind. Ein Skript, das vom bash-Standard ausgeht, kann unter zsh abbrechen, nur weil ein Glob nichts getroffen hat.

So wird es angewendet

• Jedes Skript mit einer expliziten Shebang-Zeile (#!/bin/bash oder #!/bin/zsh) versehen, statt sich auf die Login-Shell zu verlassen, und Skripte mit bash script.sh ausführen, statt sie in eine interaktive zsh-Sitzung einzulesen (Sourcing), wenn bash-Semantik erforderlich ist.
• Muss ein Skript unter beiden Shells korrekt laufen, jede Parameterexpansion in Anführungszeichen setzen ("$var"), damit Unterschiede bei der Wortaufteilung keine Rolle spielen, und auf nullbasierte Array-Annahmen verzichten oder unter beiden Shells testen.
• /bin/bash unter macOS als veralteten 3.2-Build behandeln: Er ist älter als assoziative Arrays, mapfile und andere Funktionen ab bash 4; werden sie benötigt, eine aktuelle bash über einen Paketmanager installieren und per vollständigem Pfad referenzieren, da sich /bin/bash nicht ändern wird.

Stolpersteine

• Die Annahme "Ein Mac ist im Grunde Linux/bash" und das Einfügen eines bash-spezifischen Skripts ohne Shebang in die Standard-Shell eines Agenten unter macOS.
• Tests nur in einer interaktiv konfigurierten zsh (mit angepasster .zshrc, die KSH_ARRAYS oder SH_WORD_SPLIT setzt) und Auslieferung eines Skripts, das unter einem sauberen Standardprofil fehlschlägt.
• Vergessen, dass /bin/sh unter macOS standardmässig bash 3.2 im POSIX-Modus ist (seit 10.15 erfolgt der Aufruf über /private/var/select/sh, das auf dash oder zsh umgelinkt werden kann), mit Optionsvorgaben, die sich sowohl von interaktivem zsh als auch von normalem bash unterscheiden.