Zum Inhalt springen
Linux, DevOps & Systeme

Kommentare in Bash

Kommentare in Bash: einzeilig mit Hash, am Zeilenende, mehrzeilig per Here-Document, Shebang, Auskommentieren und Konventionen für lesbare Skripte.

Von DI Herwart Wermescher, MBA ↗

Beim Schreiben von Bash Skripts ist es immer hilfreich, Deinen Code leicht verständlich zu gestalten. Dazu gehören angemessene Kommentare. Wer ohnehin gern an der Shell schraubt, findet im Beitrag zum Anpassen der bash Kommandozeile noch mehr Komfort-Tipps.

Einzeiliger Kommentar mit

Bash kennt genau ein Kommentarzeichen: das Hash #. Alles ab dem # bis zum Zeilenende ignoriert die Shell.

# Dies ist ein Kommentar
echo "Was für ein Tag"

Das gilt in Skriptdateien genauso wie in der interaktiven Shell. Tippst Du dort eine Zeile mit # ein, passiert schlicht nichts.

Kommentar am Zeilenende

Ein Kommentar darf auch mitten in der Zeile beginnen, sofern davor ein abgeschlossener Befehl steht:

echo "Was für ein Tag"     # Dies ist ein Kommentar mitten in der Code-Zeile

Wichtig ist das Leerzeichen vor dem #. Ohne Trennzeichen hängt das Hash am vorherigen Wort und wird Teil des Arguments. echo abc#def gibt abc#def aus, echo abc #def gibt nur abc aus. Das ist eine beliebte Fehlerquelle bei Pfaden und URLs.

Wann ein # kein Kommentar ist

Innerhalb von Anführungszeichen verliert das Hash seine Bedeutung. Das ist logisch, sonst könntest Du keine Farbcodes, keine Kommentarzeichen und keine URL-Anker in Strings verwenden:

echo "Farbe #1B2735 wird gesetzt"     # nur das hier ist ein Kommentar
grep "#!/bin/bash" *.sh

Dasselbe gilt für Parameter-Expansionen. ${#VAR} liefert die Länge einer Variablen, $# die Anzahl der Argumente. Beides hat mit Kommentaren nichts zu tun:

ARGS=$#                 # Anzahl der übergebenen Parameter
LAENGE=${#PFAD}         # Länge des Strings in PFAD

Auch in einem Here-Document oder hinter einem Backslash bleibt das Hash ein normales Zeichen.

Mehrzeilige Kommentare

Bash hat keine eigene Syntax für Kommentarblöcke wie /* … */. Der saubere und in jedem Editor lesbare Weg sind mehrere Zeilen mit #:

# ---------------------------------------------
# Sichert die Datenbank und rotiert alte Dumps.
# Läuft täglich per cron, siehe /etc/cron.d/db.
# ---------------------------------------------

Jeder halbwegs aktuelle Editor kann einen markierten Block auf Tastendruck mit # versehen. In vim erledigt das etwa der visuelle Blockmodus, in VS Code Strg+#. Diese Variante hat den Vorteil, dass sie in jeder Shell funktioniert und beim Lesen sofort als Kommentar erkennbar ist.

Der Here-Document-Trick

Willst Du einen längeren Block wirklich am Stück auskommentieren, gibt es einen Workaround über ein Here-Document, das an den Doppelpunkt-Befehl übergeben wird. Der Doppelpunkt ist ein eingebauter Befehl, der nichts tut und immer erfolgreich zurückkehrt:

: <<'KOMMENTAR'
Dies ist ein
mehrzeiliger Kommentar
in Bash.
KOMMENTAR

Zwei Dinge sind dabei entscheidend. Erstens der Doppelpunkt am Anfang: Ohne ihn versucht Bash, den Text als Eingabe an ein Kommando zu geben, und je nach Kontext bekommst Du eine Fehlermeldung. Zweitens die einfachen Anführungszeichen um das Begrenzerwort. Nur damit unterbleibt jede Expansion. Ohne Quotes ersetzt Bash im Block weiterhin $VARIABLEN, führt `Backticks` und $(befehle) aus und stolpert über nicht abgeschlossene Ausdrücke. Ein vermeintlicher Kommentar, der Befehle ausführt, ist der schlechteste Kommentar überhaupt.

Eine Variante mit gleichem Effekt ist:

: '
Dies ist ein
sehr kurzer Multiline Kommentar
in Bash.
'

Hier ist der gesamte Block ein Argument des Doppelpunkt-Befehls. Der Haken: Ein einzelnes Anführungszeichen im Text, etwa ein Apostroph in „don’t”, beendet den String vorzeitig und bricht das Skript. Für Fließtext ist die Here-Document-Variante robuster.

Meine Empfehlung nach vielen Jahren Skripten: Für Dokumentation nimm #-Zeilen. Den Here-Document-Trick nutze ich nur zum kurzfristigen Stilllegen eines Codeblocks während der Fehlersuche.

Der Shebang in Zeile 1

Eine Zeile fällt aus dem Rahmen: die erste. Steht dort #! gefolgt von einem Interpreterpfad, wertet der Kernel sie beim Ausführen aus, bevor Bash das Skript überhaupt sieht:

#!/bin/bash

Für Bash sieht das aus wie ein gewöhnlicher Kommentar, für das Betriebssystem ist es die Angabe, womit die Datei ausgeführt wird. Deshalb muss der Shebang in Zeile 1 stehen, ohne Leerzeile oder Leerzeichen davor. Portabler ist #!/usr/bin/env bash, weil damit die Bash aus dem PATH genommen wird und das Skript auch auf Systemen läuft, die Bash nicht unter /bin ablegen.

Code aus- und einkommentieren

Beim Debuggen kommentierst Du gern einzelne Zeilen aus. Setze das # ganz an den Zeilenanfang, damit auf einen Blick erkennbar ist, dass die Zeile inaktiv ist:

rsync -av /daten/ /backup/
# rm -rf /backup/alt/          # deaktiviert bis Rückfrage geklärt

Zwei Hinweise aus der Praxis. Schreib dazu, warum die Zeile stillgelegt ist und ab wann sie wieder aktiv werden soll, sonst weiß in sechs Monaten niemand mehr Bescheid. Und lösch auskommentierten Code, wenn er endgültig weg soll: Die Historie hat Deine Versionsverwaltung, das Skript braucht sie nicht.

Wenn Du solche Kommentar-Blöcke später in vielen Dateien wiederfinden willst, hilft Dir die Anleitung Text in Dateien finden.

Konventionen für gut lesbare Skripte

Ein Kopfkommentar direkt unter dem Shebang zahlt sich aus. Ich halte darin Zweck, Autor, Datum und Aufrufsyntax fest:

#!/usr/bin/env bash
#
# backup-db.sh - Sichert die Produktionsdatenbank nach /srv/backup
#
# Autor:   Herwart Wermescher
# Erstellt: 2026-09-07
# Aufruf:  ./backup-db.sh <zielverzeichnis>
# Rückgabe: 0 = ok, 1 = Zielverzeichnis fehlt, 2 = Dump fehlgeschlagen

Für Funktionen genügt ein kurzer Block darüber mit Parametern und Rückgabewert:

# Prüft, ob ein Dienst läuft.
# $1 - Name der systemd-Unit
# Rückgabe: 0 wenn aktiv, sonst 1
laeuft_dienst() {
  systemctl is-active --quiet "$1"
}

Die wichtigste Regel: Kommentiere das Warum, nicht das Was. i=$((i+1)) # i um eins erhöhen hilft niemandem. sleep 5 # API wirft sonst 429, Rate Limit greift ab 10 Anfragen/Minute rettet dem Nächsten eine Stunde. Halte Kommentare außerdem aktuell: Ein Kommentar, der etwas anderes behauptet als der Code, ist schlimmer als gar keiner.

Für zeitgesteuerte Skripte lohnt zusätzlich ein Hinweis, von wo der Aufruf kommt. Wie Du solche Aufrufe planst, zeigt Linux cron kurz und bündig.

bash comment, bash comments, comment in bash

Weil die meiste Shell-Dokumentation englisch ist, hier die Begriffe zum Nachschlagen: Ein einzeiliger Kommentar heißt single-line comment oder inline comment, ein Block heißt multiline comment oder block comment, das Stilllegen von Code commenting out. Wonach immer Du suchst, es läuft in Bash auf dasselbe Zeichen hinaus: das Hash am Zeilenanfang, alles andere sind Workarounds drumherum.

Verwandte Beiträge

Über diesen Blog

Ein Sammelsurium an Denkanstößen.

Hier sammle ich Wissen, Argumente und Links zu allem, was mich beschäftigt — von Technik über Küche bis Nachhaltigkeit. Beruflich berate ich zu Cybersecurity.