Farbige Diff-Ausgabe in Bash-Skripten gestalten

1. Warum monochromes diff in Skripten unterschätzt wird

Das klassische diff-Kommando liefert technisch vollständige Informationen darüber, was sich zwischen zwei Dateien geändert hat, aber die reine Textausgabe mit < und > als Markierung ist im Terminal schwer zu überfliegen. Eine farbige Diff-Ausgabe löst dieses Wahrnehmungsproblem, indem hinzugefügte Zeilen grün, entfernte Zeilen rot und geänderte Bereiche gelb hervorgehoben werden. Der Unterschied springt bei längeren Diffs sofort ins Auge, während eine monochrome Ausgabe Zeile für Zeile gelesen werden muss.

In eigenen Bash-Skripten, etwa für Konfigurationsvergleiche vor einem Deployment oder für Backup-Verifikation, wird eine farbige Diff-Ausgabe oft übersehen, weil diff selbst standardmäßig keine Farbe unterstützt. Dabei ist der Aufwand, Farbe hinzuzufügen, gering, sowohl über fertige Werkzeuge als auch über eine einfache Eigenimplementierung. Dieser Artikel zeigt beide Wege und macht deutlich, wann sich welcher Ansatz lohnt.

2. colordiff: die schnellste Lösung ohne Eigenbau

colordiff ist ein schlanker Perl-Wrapper um das klassische diff-Kommando, der die Ausgabe zeilenweise analysiert und mit ANSI-Farbcodes versieht, ohne die zugrunde liegende diff-Logik zu verändern. Der Aufruf ist denkbar einfach: colordiff datei1 datei2 statt diff datei1 datei2, alle gewohnten diff-Optionen wie -u für Unified-Diff-Format funktionieren unverändert weiter, weil colordiff sie einfach an diff durchreicht.

Der große Vorteil von colordiff in Bash-Skripten ist, dass keine eigene Parsing-Logik nötig ist. Das Werkzeug übernimmt die komplette Erkennung von Hinzufügungen, Löschungen und Kontextzeilen und färbt sie konsistent ein. Die Farbschemata lassen sich über eine Konfigurationsdatei ~/.colordiffrc anpassen, was für Teams mit einheitlichem Styling über mehrere Skripte hinweg praktisch ist, ohne die Farblogik in jedem Skript zu wiederholen.

#!/usr/bin/env bash
set -euo pipefail

compare_configs() {
  local file_a="$1"
  local file_b="$2"

  if command -v colordiff &>/dev/null; then
    colordiff -u "$file_a" "$file_b"
  else
    echo "[INFO] colordiff nicht gefunden, Fallback auf einfaches diff" >&2
    diff -u "$file_a" "$file_b"
  fi
}

compare_configs /etc/nginx/nginx.conf.bak /etc/nginx/nginx.conf

3. git diff --color für versionierte Vergleiche

Für Dateien, die in einem Git-Repository verwaltet werden, ist git diff --color oft die pragmatischere Wahl, weil kein separates Werkzeug installiert werden muss, sobald Git bereits vorhanden ist. Über git diff --no-index --color datei1 datei2 lässt sich git diff sogar für Dateien außerhalb eines Repositories nutzen, was diese Option auch für reine Dateivergleiche in Bash-Skripten interessant macht, unabhängig von einer bestehenden Versionskontrolle.

Der Vorteil von git diff gegenüber colordiff liegt in den zusätzlichen Funktionen wie Wort-Diff mit --word-diff, das Änderungen innerhalb einer Zeile statt nur zeilenweise hervorhebt. Für Konfigurationsdateien, bei denen sich oft nur ein einzelner Wert innerhalb einer langen Zeile ändert, ist diese feinere Granularität deutlich aufschlussreicher als ein reiner Zeilenvergleich, bei dem die gesamte Zeile als geändert markiert wird.

#!/usr/bin/env bash
set -euo pipefail

# git diff --no-index works even outside a Git repository
git --no-pager diff --no-index --color=always \
  /etc/app/settings.yml.bak /etc/app/settings.yml || true

# Word-level diff highlights the changed value inside a long line
git --no-pager diff --no-index --color=always --word-diff \
  /etc/app/settings.yml.bak /etc/app/settings.yml || true

4. Eigene Einfärbung mit awk und ANSI-Codes

Weder colordiff noch git diff sind auf jedem Zielsystem garantiert vorhanden, insbesondere auf minimalen Server-Images. Für diesen Fall lässt sich eine farbige Diff-Ausgabe mit reinem diff und awk selbst bauen. Das Prinzip: Die Ausgabe von diff im Unified-Format wird zeilenweise durch awk geleitet, das anhand des ersten Zeichens jeder Zeile entscheidet, welche ANSI-Farbe angewendet wird, grün für Zeilen mit führendem +, rot für Zeilen mit führendem -.

Dieser Eigenbau hat gegenüber den fertigen Werkzeugen einen entscheidenden Vorteil: volle Kontrolle über das Farbschema und keine zusätzliche Abhängigkeit außer awk, das auf praktisch jedem Unix-System vorinstalliert ist. Der Nachteil ist der etwas höhere Wartungsaufwand, weil Sonderfälle wie die Kopfzeilen des Unified-Diff-Formats (--- und +++) explizit von der normalen Plus- und Minus-Logik unterschieden werden müssen, um nicht versehentlich als geänderte Zeile eingefärbt zu werden.

#!/usr/bin/env bash
set -euo pipefail

colorize_diff() {
  awk '
    /^\+\+\+/ { print "\033[1m" $0 "\033[0m"; next }   # file header (bold)
    /^---/    { print "\033[1m" $0 "\033[0m"; next }   # file header (bold)
    /^\+/     { print "\033[32m" $0 "\033[0m"; next }  # added line (green)
    /^-/      { print "\033[31m" $0 "\033[0m"; next }  # removed line (red)
    /^@@/     { print "\033[36m" $0 "\033[0m"; next }  # hunk header (cyan)
    { print }
  '
}

diff -u old_config.yml new_config.yml | colorize_diff

5. Seite-an-Seite-Vergleich mit diff -y einfärben

Für kurze Dateien mit wenigen Zeilen ist die Seite-an-Seite-Ansicht mit diff -y oft übersichtlicher als das Unified-Format, weil beide Versionen nebeneinander statt hintereinander erscheinen. Ohne Farbe ist diese Ansicht aber schwer zu überfliegen, weil der Unterschied zwischen unveränderten und geänderten Zeilen nur am schmalen Trennzeichen in der Mitte erkennbar ist. Eine farbige Diff-Ausgabe hebt hier vor allem das Trennzeichen selbst hervor, etwa | für geänderte, < für nur links vorhandene und > für nur rechts vorhandene Zeilen.

colordiff unterstützt -y direkt und färbt die Trennzeichen automatisch ein, was diese Kombination zur einfachsten Lösung für Seite-an-Seite-Vergleiche macht. Wer stattdessen die Eigenbau-Lösung aus dem vorherigen Abschnitt nutzt, muss die Erkennung der Trennzeichen in der Mitte der Zeile selbst mit einem regulären Ausdruck in awk nachbilden, was etwas mehr Aufwand bedeutet, aber ebenso funktioniert.

#!/usr/bin/env bash
set -euo pipefail

# Side-by-side comparison with automatic color highlighting
if command -v colordiff &>/dev/null; then
  colordiff -y -W 120 old_config.yml new_config.yml
else
  diff -y -W 120 old_config.yml new_config.yml
fi

6. Exit-Codes von diff korrekt in Skripten auswerten

Ein oft übersehenes Detail: diff gibt Exit-Code 0 zurück, wenn keine Unterschiede gefunden wurden, Exit-Code 1, wenn Unterschiede vorhanden sind, und Exit-Code 2 bei einem tatsächlichen Fehler, etwa wenn eine der beiden Dateien nicht existiert. Unter set -e beendet ein gefundener Unterschied das Skript sofort, weil Exit-Code 1 als Fehler interpretiert wird, selbst wenn der Unterschied das erwartete und gewünschte Ergebnis der Prüfung ist.

Für Skripte, die eine farbige Diff-Ausgabe anzeigen und danach kontrolliert auf das Ergebnis reagieren sollen, muss der Exit-Code explizit abgefangen werden, etwa mit diff_output=$(diff -u a b) || diff_exit=$?. Erst mit dieser expliziten Behandlung lässt sich zwischen "keine Unterschiede", "Unterschiede gefunden" und "echter Fehler beim Vergleich" sauber unterscheiden, statt alle drei Fälle unter set -e gleich zu behandeln.

#!/usr/bin/env bash
set -uo pipefail  # note: no -e, we handle diff's exit codes explicitly

check_config_drift() {
  local baseline="$1"
  local current="$2"

  diff -u "$baseline" "$current" | colorize_diff
  local diff_exit=${PIPESTATUS[0]}

  case "$diff_exit" in
    0) echo "Keine Abweichung gefunden." ;;
    1) echo "[WARN] Konfiguration weicht vom Baseline ab." >&2; return 1 ;;
    *) echo "[ERROR] Vergleich fehlgeschlagen, Exit-Code $diff_exit" >&2; return 2 ;;
  esac
}

check_config_drift /etc/app/baseline.yml /etc/app/current.yml

7. Terminal-Erkennung: Farbe nur wenn sinnvoll

Farbcodes in der diff-Ausgabe sind nur dann ein Gewinn, wenn die Ausgabe tatsächlich in einem Terminal angezeigt wird, das ANSI-Sequenzen interpretiert. Wird dieselbe Ausgabe in eine Logdatei umgeleitet oder von einem anderen Skript weiterverarbeitet, erscheinen die Escape-Codes als kryptische Zeichenfolgen zwischen dem eigentlichen Text, was die Lesbarkeit eher verschlechtert als verbessert. Die Prüfung [[ -t 1 ]] stellt fest, ob stdout mit einem echten Terminal verbunden ist, und sollte vor jeder Farbentscheidung stehen.

Sowohl colordiff als auch git diff --color=auto beherrschen diese Erkennung bereits von sich aus und schalten Farbe automatisch ab, wenn die Ausgabe umgeleitet wird. Bei der eigenen awk-Lösung aus Abschnitt 4 muss diese Prüfung dagegen manuell ergänzt werden, etwa indem die colorize_diff-Funktion nur aufgerufen wird, wenn [[ -t 1 ]] wahr ist, und andernfalls die unveränderte diff-Ausgabe direkt weitergegeben wird.

8. Praxisbeispiel: Konfigurationsvergleich vor einem Deployment

Ein realistisches Einsatzgebiet für farbige Diff-Ausgabe ist die Prüfung von Konfigurationsdateien vor einem Deployment, bei der ein Operator auf einen Blick erkennen muss, welche Werte sich seit dem letzten bekannten Stand geändert haben. Ein Skript, das vor jedem Deployment automatisch die aktuelle Konfiguration mit einer als Referenz gespeicherten Version vergleicht und das Ergebnis farbig darstellt, reduziert das Risiko, eine unbeabsichtigte Änderung zu übersehen, erheblich gegenüber einer monochromen Ausgabe.

Kombiniert mit den Exit-Code-Mustern aus Abschnitt 6 lässt sich ein solches Skript zusätzlich als Gate im Deployment-Prozess einsetzen: Werden Unterschiede gefunden, zeigt das Skript die farbige Diff-Ausgabe und fragt explizit nach Bestätigung, bevor das Deployment fortgesetzt wird. Dieses Muster verbindet die reine Sichtbarkeit von Änderungen mit einer aktiven Sicherheitsmaßnahme gegen versehentliche Konfigurationsabweichungen.

9. Werkzeuge für farbige Diffs im Vergleich

Für farbige Diff-Ausgaben in Bash-Skripten stehen mehrere Wege zur Verfügung, die sich in Abhängigkeit, Funktionsumfang und Kontrolle über das Farbschema unterscheiden.

Für die meisten Wartungsskripte ist eine Kombination die robusteste Lösung: colordiff oder git diff --color bevorzugt verwenden, mit einem Fallback auf die selbst gebaute awk-Lösung, falls beide Werkzeuge auf dem Zielsystem fehlen. So bleibt die farbige Diff-Ausgabe in jeder Umgebung verfügbar, ohne dass ein Skript an fehlenden Paketen scheitert.

10. Zusammenfassung

Eine farbige Diff-Ausgabe macht Änderungen zwischen Dateien in Bash-Skripten deutlich schneller erfassbar als die monochrome Standardausgabe von diff. colordiff ist die schnellste Lösung ohne Eigenimplementierung, git diff --color mit --word-diff bietet zusätzlich feinere Granularität für Konfigurationsdateien, und eine Eigenbau-Lösung mit awk und ANSI-Codes funktioniert auch dort, wo keines der beiden Werkzeuge verfügbar ist.

Entscheidend für den produktiven Einsatz sind zwei Details: die korrekte Auswertung der diff-Exit-Codes, damit "keine Unterschiede", "Unterschiede gefunden" und "echter Fehler" sauber unterschieden werden, und die Terminal-Erkennung mit [[ -t 1 ]], damit Farbcodes nicht als kryptische Zeichenfolgen in Logdateien landen. Wer diese Muster einmal in einer wiederverwendbaren Funktion kapselt, bekommt eine farbige Diff-Ausgabe, die in jedem Wartungs- und Deployment-Skript konsistent funktioniert.

11. FAQ: Farbige Diff-Ausgabe in Bash