Portable POSIX-sh-Skripte für Linux, BSD, macOS und AIX schreiben

Worum es geht

POSIX.1-2017 definiert die Shell Command Language unabhängig von einer bestimmten Implementierung. /bin/sh kann je nach System dash sein (Standard unter Debian/Ubuntu, dessen Handbuchseite es als POSIX-konformen Befehlsinterpreter beschreibt), bash im POSIX-Modus (Linux der RHEL-Familie, macOS), ksh (AIX) oder eine ganz andere Shell. Ein Skript, das bisher nur mit den Erweiterungen von bash getestet wurde, kann scheitern, sobald /bin/sh auf eine andere Shell zeigt.

Warum es wichtig ist

Es treten zwei getrennte Portabilitätsprobleme auf:

• Shell-Syntax: Bashismen wie [[ ]], Arrays, function name() {}, source, Prozesssubstitution <(...), set -o pipefail und $'...' (die letzten beiden kamen erst mit der Ausgabe 2024 in POSIX; dash 0.5.12 unterstützt keines von beiden) gehören nicht zu POSIX.1-2017 sh. dash lehnt viele davon ab oder verarbeitet sie stillschweigend falsch. local ist ebenfalls nicht POSIX, wird von dash aber akzeptiert. Das Debian-Werkzeug checkbashisms, in seiner Handbuchseite als Skript beschrieben, um "check for bashisms in /bin/sh scripts", ist genau dafür gedacht: Es sollte über jedes Skript laufen, das #!/bin/sh deklariert.
• Befehlsoptionen unterscheiden sich je nach Hersteller: Die Shell kann portabel sein, die externen Werkzeuge, die sie aufruft, sind es nicht. sed -i verlangt beim BSD-sed von FreeBSD/macOS zwingend ein Erweiterungsargument (dokumentiert als Bearbeiten von Dateien "in-place similarly to" -I, wobei eine Erweiterung auch dann angegeben wird, wenn sie leer ist). Beim GNU-sed ist das Suffix dagegen optional und direkt angehängt. sed -i '' -e ... ist auf der BSD-Seite erforderlich und auf der GNU-Seite falsch (GNU behandelt '' als Dateinamen und beendet sich mit Status 2). sed -i.bak -e ... file && rm file.bak funktioniert auf beiden. readlink -f ist in GNU coreutils und im FreeBSD-Handbuch gleich definiert (alle Symlinks auflösen, um einen kanonischen Pfad zu erhalten); macOS kennt es erst seit 12.3. Auf älteren macOS-Versionen und auf vielen Plattformen, die weder GNU noch BSD sind (zum Beispiel AIX), fehlt es ohne installierte coreutils. date (GNU date -d, BSD date -j -f/-v), stat (GNU stat -c, BSD stat -f) und find weichen zwischen GNU- und BSD-basierten Userlands auf ähnliche Weise voneinander ab.

So wird es angewendet

• Die Shell ehrlich deklarieren: #!/bin/sh nur für Skripte verwenden, die checkbashisms ohne Beanstandung durchlaufen; #!/bin/bash verwenden und die eingeschränkte Portabilität in Kauf nehmen, wenn bash-Funktionen tatsächlich nötig sind.
• In portablen Skripten GNU-spezifische Optionen meiden oder anhand von uname -s bzw. der --version-Ausgabe des Werkzeugs verzweigen und die herstellerspezifische Form aufrufen (sed -i '' ... unter Darwin/FreeBSD, sed -i ... unter Linux).
• Optionen bevorzugen, die POSIX selbst definiert (sed -e, printf statt echo -e, command -v statt which), wenn ein Skript unverändert auf möglichst vielen /bin/sh-Implementierungen laufen muss, einschliesslich der Shell von AIX.
• Die tatsächliche /bin/sh auf jedem Zielsystem testen, nicht nur bash im POSIX-Modus; der "Bash POSIX Mode" von GNU Bash ändert viele Standardeinstellungen, ist aber nicht identisch mit dem Verhalten von dash oder ksh.

Stolpersteine

• Die Annahme, bash --posix oder ein #!/bin/sh-Shebang auf einem System, auf dem /bin/sh tatsächlich bash ist, belege die POSIX-Konformität. Der zusätzliche Lauf unter dash deckt deutlich mehr auf, doch keine einzelne Shell kann die Konformität beweisen.
• sed -i in einer einzigen Form fest einzutragen und das Skript sowohl auf einem Linux-CI-Runner als auch auf einem macOS-Entwicklerrechner einzusetzen.
• Sich auf readlink -f zu verlassen, obwohl es auf der Plattform nicht installiert ist, und keinen Ersatz vorzusehen, etwa (cd "$(dirname -- "$f")" && pwd -P); dieser kanonisiert nur den Verzeichnisteil, nicht aber einen Symlink in der letzten Pfadkomponente.