Spinner-Animationen in Bash-Skripten implementieren

1. Wofür ein Spinner steht, wenn keine Prozentangabe möglich ist

Ein Spinner löst ein anderes Problem als ein Fortschrittsbalken: Er kommt genau dann zum Einsatz, wenn die Gesamtdauer eines Vorgangs nicht bekannt ist und sich deshalb kein Prozentsatz berechnen lässt. Ein DNS-Lookup, ein API-Aufruf mit unbekannter Antwortzeit oder ein Datenbank-Backup mit variabler Größe sind typische Kandidaten, bei denen ein Spinner die einzig sinnvolle Anzeigeform ist. Ohne jede visuelle Rückmeldung wirkt ein Skript in solchen Momenten wie abgestürzt, selbst wenn im Hintergrund alles normal abläuft.

Der psychologische Effekt eines Spinners ist einfach, aber wirksam: Eine sich bewegende Animation signalisiert dem Anwender, dass der Prozess läuft, auch ohne konkrete Information über die verbleibende Zeit. Anders als ein Fortschrittsbalken macht ein Spinner keine Aussage über den tatsächlichen Fortschritt, sondern ausschließlich über die Tatsache, dass etwas passiert. Dieser Artikel zeigt, wie ein solcher Spinner technisch als eigenständiger Hintergrundprozess implementiert wird, ohne den eigentlichen Befehl zu blockieren.

2. Grundprinzip: Zeichenfolge, Carriage Return und Schleife

Das Grundprinzip eines Spinners ähnelt dem eines Fortschrittsbalkens: Beide nutzen das Carriage-Return-Zeichen \r, um dieselbe Zeile wiederholt zu überschreiben. Der Unterschied liegt im Inhalt: Statt eines wachsenden Balkens rotiert ein Spinner durch eine kurze Zeichenfolge, typischerweise | / - \ für einen klassischen ASCII-Spinner oder Braille-Zeichen wie ⠋⠙⠹⠸⠼⠴⠦⠧⠇⠏ für einen flüssigeren, moderneren Look.

Eine einfache Endlosschleife mit kurzer Pause zwischen den Zeichen erzeugt bereits die Animation. Der entscheidende Unterschied zu allen bisher gezeigten Mustern ist jedoch, dass ein Spinner nicht synchron mit einer Verarbeitungsschleife läuft, sondern parallel zu einem einzelnen, potenziell lange laufenden Befehl, dessen Fortschritt von außen nicht messbar ist. Genau das macht die Implementierung als Hintergrundprozess notwendig, statt die Animation direkt in den Hauptablauf des Skripts zu integrieren.

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

# Minimal spinner loop — demonstrates the animation principle only
spinner_chars="/-\|"
for i in {1..20}; do
  char="${spinner_chars:i%4:1}"
  printf "\r%s Verarbeite..." "$char"
  sleep 0.1
done
printf "\r"

3. Der Spinner als eigener Hintergrundprozess

Damit ein Spinner parallel zu einem langlaufenden Befehl animiert, muss die Animationsschleife in einem eigenen Hintergrundprozess laufen, gestartet mit dem &-Operator. Das Hauptskript startet den Spinner im Hintergrund, führt danach den eigentlichen Befehl im Vordergrund aus, und beendet den Spinner-Prozess, sobald der Befehl fertig ist. Die Prozess-ID des Hintergrundprozesses wird über die spezielle Variable $! festgehalten, um ihn später gezielt beenden zu können.

Ein häufiger Fehler bei der ersten Implementierung ist, den Spinner-Prozess in derselben Shell-Session laufen zu lassen, ohne ihn wirklich zu entkoppeln. Ausgaben des Spinners und des eigentlichen Befehls können sich dann überlagern, wenn der Befehl selbst ebenfalls stdout beschreibt. In der Praxis funktioniert der Spinner deshalb am besten für Befehle, die während ihrer Ausführung keine eigene Ausgabe erzeugen, etwa curl -s, tar oder Datenbank-Dumps mit unterdrückter Standardausgabe.

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

start_spinner() {
  local spinner_chars='⠋⠙⠹⠸⠼⠴⠦⠧⠇⠏'
  local i=0
  while true; do
    printf "\r%s Verarbeite..." "${spinner_chars:i++%${#spinner_chars}:1}"
    sleep 0.1
  done
}

# Start the spinner as a detached background process
start_spinner &
spinner_pid=$!

# The actual long-running command
sleep 3

# Stop the spinner once the command is done
kill "$spinner_pid" 2>/dev/null
wait "$spinner_pid" 2>/dev/null
printf "\r\033[K"  # clear the line
echo "Fertig."

4. Synchronisation: Spinner starten und stoppen

Die zentrale Herausforderung bei einem Spinner-Hintergrundprozess ist die zuverlässige Synchronisation mit dem eigentlichen Befehl. Startet der Spinner zu früh oder wird er zu spät beendet, entstehen visuelle Artefakte wie ein weiterlaufender Spinner nach Abschluss des eigentlichen Befehls. Der bewährte Ablauf ist immer derselbe: Spinner im Hintergrund starten, PID in einer Variable sichern, den eigentlichen Befehl im Vordergrund ausführen und dessen Exit-Code separat sichern, dann den Spinner-Prozess mit kill beenden.

Ein subtiler, aber wichtiger Punkt ist die Reihenfolge zwischen kill und wait. Ohne wait nach dem kill-Aufruf kann das Skript fortfahren, bevor der Spinner-Prozess tatsächlich beendet ist, was zu einer letzten sichtbaren Spinner-Ausgabe führen kann, die die nachfolgende Skriptausgabe überschreibt. Das explizite wait stellt sicher, dass der Prozess vollständig terminiert ist, bevor das Skript mit der nächsten Ausgabe fortfährt.

5. Sauberes Cleanup mit trap statt verwaister Prozesse

Der größte praktische Fehler bei einem selbst gebauten Spinner ist ein verwaister Hintergrundprozess, der weiterläuft, wenn das Hauptskript unerwartet abbricht, etwa durch Strg-C oder einen Fehler unter set -e. Ohne Absicherung terminiert der Spinner-Prozess in diesem Fall nicht, sondern läuft in einer Endlosschleife im Hintergrund weiter, bis er manuell mit kill beendet wird. Bei wiederholter Ausführung des Skripts sammeln sich so über die Zeit mehrere verwaiste Spinner-Prozesse an, die unnötig CPU-Zyklen verbrauchen.

Die Lösung ist ein trap auf EXIT, INT und TERM, der den Spinner-Prozess unabhängig vom Beendigungsgrund zuverlässig terminiert. Dieser Trap sollte so früh wie möglich registriert werden, direkt nach dem Start des Spinner-Prozesses, damit auch ein Abbruch unmittelbar nach dem Start korrekt behandelt wird. Die Kombination aus trap und einer Guard-Prüfung, ob die PID überhaupt noch existiert, macht das Cleanup robust gegen alle denkbaren Abbruchszenarien.

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

spinner_pid=""

stop_spinner() {
  if [[ -n "$spinner_pid" ]] && kill -0 "$spinner_pid" 2>/dev/null; then
    kill "$spinner_pid" 2>/dev/null
    wait "$spinner_pid" 2>/dev/null
  fi
  printf "\r\033[K"  # clear any leftover spinner output
}

# Register cleanup for every possible exit path
trap stop_spinner EXIT INT TERM

start_spinner() {
  local chars='⠋⠙⠹⠸⠼⠴⠦⠧⠇⠏'
  local i=0
  while true; do
    printf "\r%s Verarbeite Backup..." "${chars:i++%${#chars}:1}"
    sleep 0.1
  done
}

start_spinner &
spinner_pid=$!

# Simulate a long-running command that might fail or be interrupted
sleep 3

echo "Backup abgeschlossen."

6. Exit-Code des eigentlichen Befehls weiterreichen

Ein häufig übersehener Aspekt ist, dass der Exit-Code des eigentlichen Befehls erhalten bleiben muss, auch wenn zwischen Befehlsausführung und Skriptende noch weitere Aktionen stattfinden, etwa das Stoppen des Spinners. Ruft man den eigentlichen Befehl direkt auf, gefolgt vom kill-Aufruf für den Spinner, überschreibt der Exit-Code des kill-Befehls den ursprünglichen Exit-Code, sofern dieser nicht explizit zwischengespeichert wird.

Die korrekte Vorgehensweise sichert den Exit-Code des eigentlichen Befehls unmittelbar nach dessen Ausführung in einer eigenen Variable, bevor irgendein weiterer Befehl ausgeführt wird. Erst danach wird der Spinner gestoppt, und am Ende des Skripts wird explizit mit exit "$command_exit_code" beendet. Dieses Muster stellt sicher, dass ein aufrufendes Skript oder eine CI-Pipeline korrekt erkennt, ob der eigentliche Befehl erfolgreich war, unabhängig vom internen Ablauf der Spinner-Verwaltung.

#!/usr/bin/env bash
set -uo pipefail  # note: no -e here, we handle the exit code manually

run_with_spinner() {
  local message="$1"
  shift

  local chars='⠋⠙⠹⠸⠼⠴⠦⠧⠇⠏'
  local i=0
  ( while true; do
      printf "\r%s %s" "${chars:i++%${#chars}:1}" "$message"
      sleep 0.1
    done ) &
  local spinner_pid=$!

  # Run the actual command, capture its exit code without losing it
  "$@"
  local command_exit_code=$?

  kill "$spinner_pid" 2>/dev/null
  wait "$spinner_pid" 2>/dev/null
  printf "\r\033[K"

  return "$command_exit_code"
}

run_with_spinner "Datenbank wird gesichert..." pg_dump mydb > backup.sql
echo "Exit-Code des Backups: $?"

7. Verschiedene Zeichensätze und Geschwindigkeiten

Die Wahl des Zeichensatzes beeinflusst maßgeblich, wie flüssig ein Spinner wirkt. Der klassische ASCII-Spinner mit | / - \ funktioniert in jedem Terminal, auch in sehr alten oder eingeschränkten Umgebungen ohne UTF-8-Unterstützung. Die Braille-Zeichen bieten eine deutlich flüssigere Optik mit zehn statt vier Zwischenschritten, benötigen aber UTF-8-fähige Terminals, was in modernen Umgebungen praktisch immer der Fall ist, in sehr alten SSH-Sitzungen aber nicht garantiert werden kann.

Die Rotationsgeschwindigkeit, gesteuert über den sleep-Wert zwischen den Zeichen, sollte einen Kompromiss zwischen sichtbarer Bewegung und CPU-Last finden. Ein zu kurzer Sleep-Wert von etwa 0,01 Sekunden erzeugt spürbare CPU-Last durch die vielen printf-Aufrufe, ein zu langer Wert von über 0,3 Sekunden wirkt ruckelig statt flüssig. Werte zwischen 0,08 und 0,15 Sekunden haben sich in der Praxis als guter Mittelweg etabliert, der auf den meisten Systemen flüssig wirkt, ohne unnötig Ressourcen zu verbrauchen.

8. Integration in bestehende Deployment-Skripte

Der praktische Nutzen eines Spinners zeigt sich am deutlichsten in Deployment-Skripten, die mehrere langlaufende Schritte nacheinander ausführen, etwa Abhängigkeiten installieren, Assets kompilieren und Cache leeren. Statt jeden Schritt einzeln mit einem eigenen Spinner zu instrumentieren, empfiehlt sich eine zentrale Wrapper-Funktion wie im vorherigen Abschnitt gezeigt, die für jeden beliebigen Befehl wiederverwendet werden kann, ohne die Spinner-Logik mehrfach zu duplizieren.

Für Skripte mit mehreren aufeinanderfolgenden Schritten lohnt sich zusätzlich eine kurze Erfolgsmeldung nach jedem Schritt, die den Spinner durch ein Häkchen oder ein einfaches "[OK]" ersetzt. Diese Kombination aus Animation während der Ausführung und klarer Bestätigung danach gibt dem Anwender sowohl während als auch nach jedem Schritt ein zuverlässiges visuelles Signal, ohne dass mehrere Zeilen Ausgabe pro Schritt entstehen.

9. Spinner im Vergleich zu Fortschrittsbalken und stillem Warten

Die Wahl zwischen einem Spinner, einem Fortschrittsbalken und gar keiner Anzeige hängt in erster Linie davon ab, ob sich der Fortschritt eines Vorgangs messen lässt. Ist die Gesamtdauer oder Gesamtmenge bekannt, ist ein Fortschrittsbalken die informativere Wahl. Ist sie unbekannt, bleibt der Spinner die einzige sinnvolle Option, die dennoch aktive Rückmeldung gibt.

In der Praxis lohnt sich eine kleine Heuristik: Befehle, deren typische Laufzeit unter einer Sekunde liegt, sollten keinen Spinner bekommen, weil die Animation dann nur kurz aufflackert und mehr stört als hilft. Für alles darüber, ohne bekannte Gesamtdauer, ist der Spinner das richtige Werkzeug, kombiniert mit der in Abschnitt 8 gezeigten Wrapper-Funktion für konsistente Anwendung über das gesamte Skript hinweg.

10. Zusammenfassung

Eine Spinner-Animation in Bash basiert auf einer Endlosschleife, die eine kurze Zeichenfolge über Carriage Return wiederholt in dieselbe Zeile schreibt, gestartet als eigenständiger Hintergrundprozess. Die eigentliche Herausforderung liegt nicht in der Animation selbst, sondern in der zuverlässigen Verwaltung: die PID mit $! sichern, den Spinner nach Abschluss des eigentlichen Befehls mit kill und wait beenden, und mit trap auf EXIT, INT und TERM sicherstellen, dass kein Prozess verwaist zurückbleibt.

Ebenso wichtig ist die korrekte Weitergabe des Exit-Codes des eigentlichen Befehls, damit ein aufrufendes Skript oder eine CI-Pipeline Erfolg und Misserfolg zuverlässig erkennt, unabhängig von der internen Spinner-Verwaltung. Wer diese Muster einmal in einer wiederverwendbaren Wrapper-Funktion kapselt, kann jeden beliebigen langlaufenden Befehl im Skript mit einer konsistenten Spinner-Animation versehen, ohne die Logik für jeden Aufruf neu zu schreiben.

11. FAQ: Spinner-Animationen in Bash