Skript-Grundlagen

Was ein Skript ist

Ein Skript ist eine Textdatei, deren Zeilen ein Interpreter — bei uns die Bash — der Reihe nach abarbeitet. Es gibt keinen Compiler, keine Binärdatei, kein Linker. Du speicherst Befehle, die du auch interaktiv eintippen könntest, und die Shell liest sie wie ein Mensch: Zeile für Zeile.

Der Unterschied zu einem kompilierten Programm (etwa C oder Go) liegt im Ablauf:

Für Automatisierung, System-Administration und Glue-Code zwischen Werkzeugen sind Skripte unschlagbar — du editierst die Datei und das war’s, kein Build-Schritt, keine Toolchain.

Shebang #!

Die erste Zeile eines Skripts ist die Shebang-Zeile (auch „Hashbang”). Sie beginnt mit #! und gibt dem Kernel an, welcher Interpreter die Datei ausführen soll.

#!/bin/bash
echo "Hallo Welt"

Wenn du das Skript per ./hello.sh startest, liest der Kernel die ersten beiden Bytes (#!), findet den Pfad zum Interpreter und ruft ihn mit der Skriptdatei als Argument auf. Aus deiner Sicht passiert das transparent — der Kernel führt also nicht die Datei direkt aus, sondern startet bash hello.sh.

Was passiert, wenn der Shebang fehlt? Dann übergibt die aktuelle Shell die Datei an einen Interpreter ihrer Wahl — oft /bin/sh, manchmal die aktuelle Login-Shell. Das ist nicht nur unportabel, es bricht auch alle Bash-spezifischen Features (Arrays, [[ ... ]], $(...) ist OK, aber <() nicht überall). Ein Skript ohne Shebang ist eine tickende Zeitbombe.

Es gibt zwei gängige Varianten:

Auf macOS liegt die System-Bash in Version 3.2 unter /bin/bash — moderne Bash 5.x installiert Homebrew unter /opt/homebrew/bin/bash oder /usr/local/bin/bash. Für Skripte, die Features ab Bash 4 nutzen (assoziative Arrays, mapfile, ${var,,}), ist #!/usr/bin/env bash deshalb der robustere Default — es greift die Bash, die im PATH zuerst gefunden wird.

Ausführbar machen

Eine frisch erstellte Skriptdatei ist standardmäßig nicht ausführbar. Das siehst du in den Permissions:

ls -l hello.sh

-rw-r--r-- 1 michael michael 38 May  5 10:00 hello.sh

Die rw--Bits zeigen: lesen und schreiben ja, ausführen nein. Mit chmod +x setzt du das Execute-Bit für alle Klassen (Owner, Group, Others):

chmod +x hello.sh
ls -l hello.sh

-rwxr-xr-x 1 michael michael 38 May  5 10:00 hello.sh

Details zu den Bits stehen im Artikel Berechtigungen. Restriktiver wäre chmod 750 hello.sh (nur Owner und Group dürfen ausführen). Jetzt kannst du das Skript direkt aufrufen:

./hello.sh

Das ./ ist nötig, weil das aktuelle Verzeichnis aus Sicherheitsgründen nicht im PATH steht — sonst könnte ein präpariertes ls im aktuellen Ordner das echte ls überschreiben. Mehr dazu im Artikel zum PATH.

Alternativ kannst du den Interpreter explizit aufrufen:

bash hello.sh

Diese Variante umgeht den Shebang und braucht kein Execute-Bit — die Datei muss nur lesbar sein. Praktisch zum Testen oder wenn du bewusst eine andere Bash-Version verwenden willst (/opt/homebrew/bin/bash hello.sh).

Ausführungs-Modi

Ein Skript kann auf sehr unterschiedliche Weise laufen — und das hat reale Folgen für Variablen, Working Directory und Fehlerbehandlung. Die wichtigsten Modi:

Der Unterschied zwischen Subshell und Source ist der Klassiker:

#!/usr/bin/env bash
export PROJECT_DIR="/srv/app"
cd "$PROJECT_DIR"

./setvars.sh
echo "$PROJECT_DIR"
pwd

source ./setvars.sh
echo "$PROJECT_DIR"
pwd

/home/michael
/srv/app
/srv/app

Nach ./setvars.sh ist PROJECT_DIR leer und pwd unverändert — der Subshell-Prozess war beendet, bevor seine Variablen die Eltern-Shell erreichen konnten. Nach source bleibt beides bestehen. Genau deshalb wird ~/.bashrc immer gesourced, nie ausgeführt: Die Aliase und Variablen sollen ja in deiner aktuellen Session leben.

Der Debug-Modus bash -x ist dein bester Freund bei der Fehlersuche:

bash -x hello.sh

+ echo 'Hallo Welt'
Hallo Welt

Alternativ aktivierst du den Trace nur für einen Block: set -x an, set +x aus.

Best-Practice-Skript-Header

Jedes ernsthafte Bash-Skript sollte mit einem robusten Header starten. Die Default-Einstellungen der Bash sind aus historischen Gründen sehr nachgiebig — Fehler werden geschluckt, undefinierte Variablen werden zu leeren Strings, Pipes maskieren Probleme. Mit drei Zeilen drehst du das um:

#!/usr/bin/env bash
set -euo pipefail
IFS=$'\n\t'

Was die einzelnen Optionen bewirken:

set -e allein reicht nicht: Ohne pipefail würde cmd_das_failt | tee log.txt als erfolgreich gelten, weil tee zurückgibt. Und ohne set -u rutscht ein Tippfehler wie rm -rf "$PORJECT_DIR/" durch zu rm -rf / — weil $PORJECT_DIR einfach leer ist. Das hat 2015 ein bekanntes Hosting-Skript zerlegt.

Die IFS-Zeile ist das kleinere Mosaiksteinchen: Standardmäßig trennt Bash Wörter an Space, Tab und Newline. Das frisst dir Dateinamen mit Leerzeichen. Mit dem engeren IFS wird das Verhalten vorhersehbarer — und du gewöhnst dir an, Variablen konsequent in Anführungszeichen zu setzen ("$datei" statt $datei).

Tiefer in das Thema geht der Artikel zur Fehlerbehandlung — inklusive trap, Cleanup-Funktionen und gezieltem Override mit || true.

Encoding und Line-Endings

Bash erwartet UTF-8 ohne BOM und LF (Line Feed, \n) als Zeilenende. Klingt selbstverständlich, ist aber die Quelle eines der häufigsten Anfänger-Probleme: Du editierst ein Skript auf Windows und plötzlich tut es nichts mehr.

Der Grund: Windows-Editoren speichern standardmäßig mit CRLF (\r\n). Bash liest dann den Shebang als #!/usr/bin/env bash\r — und sucht nach einem Interpreter namens bash\r, den es natürlich nicht gibt. Die Fehlermeldung ist legendär kryptisch:

./script.sh

Typische Fehlermeldungen sind bad interpreter: No such file or directory oder '\r': command not found mitten im Skript. Beides bedeutet: Line-Endings prüfen.

So räumst du das auf:

dos2unix script.sh

Falls dos2unix nicht installiert ist, geht es auch mit sed:

sed -i 's/\r$//' script.sh

Prüfen lässt sich das mit file:

file script.sh

script.sh: Bourne-Again shell script, ASCII text executable

Bei CRLF-Endings stünde dort with CRLF line terminators. Eine BOM (Byte Order Mark, EF BB BF am Dateianfang) ist genauso tödlich wie CRLF: Sie sitzt vor dem #! und macht den Shebang unsichtbar. UTF-8 in Linux-Tooling ist immer ohne BOM.

Editoren wie VS Code, Sublime und JetBrains erkennen .sh-Dateien meist und schalten automatisch auf LF — sicherheitshalber lohnt sich aber ein Blick in die Statusleiste oder eine .editorconfig mit end_of_line = lf im Repo.

Skript-Pfad und Working Directory

Eine häufige Aufgabe: Das Skript soll Dateien neben sich selbst lesen — etwa eine Config oder ein Helper-Skript. Das aktuelle Working Directory ist dabei nicht zwingend der Skript-Ordner, sondern der Ordner, aus dem das Skript aufgerufen wurde.

cd /tmp
/home/michael/scripts/info.sh

Working Directory: /tmp
Skript-Pfad:       /home/michael/scripts/info.sh

In der Bash gibt es mehrere Variablen, die mit dem Skript-Pfad zu tun haben:

Das klassische Idiom, um den Verzeichnispfad des Skripts selbst robust zu bestimmen:

SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
echo "Skript liegt in: $SCRIPT_DIR"

Das geht so vor:

1. ${BASH_SOURCE[0]} liefert den Pfad zur Skript-Datei — auch wenn das Skript gesourced wurde.
2. dirname "..." extrahiert den Verzeichnis-Anteil (/home/michael/scripts/info.sh zu /home/michael/scripts).
3. cd "..." wechselt dort hinein — innerhalb einer Command-Substitution, also ohne dauerhaftes Wechseln des Working Directory.
4. pwd gibt den absoluten, aufgelösten Pfad zurück (auch bei relativen Aufrufen wie ./info.sh).

Mit SCRIPT_DIR kannst du dann verlässlich auf Geschwister-Dateien zugreifen:

source "$SCRIPT_DIR/lib/helpers.sh"
config_file="$SCRIPT_DIR/config.env"

Warum BASH_SOURCE statt $0? Wenn ein Skript via source other.sh von einem anderen geladen wird, ist $0 der Name des äußeren Skripts — nicht der gerade laufenden Datei. ${BASH_SOURCE[0]} hingegen zeigt immer auf die aktuelle Datei. Für Bibliotheks-Skripte, die per source eingebunden werden, ist das der Unterschied zwischen „funktioniert immer” und „funktioniert nur, wenn niemand es sourced”.

Weiterführende Ressourcen

Externe Quellen

• Bash-Manpage (man7.org) — Vollständige Referenz zu set, BASH_SOURCE und allen Built-ins
• GNU Bash-Handbuch — Offizielle Dokumentation mit Beispielen zu Shell-Modi und Optionen
• ShellCheck — Statischer Linter für Bash-Skripte, findet Quoting-Fehler und unsichere Patterns
• Google Shell Style Guide — Bewährte Konventionen für robuste, lesbare Skripte
• Bash Pitfalls (mywiki.wooledge.org) — Sammlung typischer Fehler mit ausführlicher Erklärung

Verwandte Artikel

• Linux Shell — Bash, Zsh und die Grundlagen der Kommandozeile
• Streams und Pipes — stdin, stdout, stderr und ihre Umleitung
• Berechtigungen — Permissions-Bits und das Execute-Bit im Detail
• PATH — Wie die Shell Programme findet und warum ./ nötig ist
• Variablen — Shell- und Umgebungsvariablen, export und Vererbung