Interaktive Bash-Tools mit select, read, Menüs und Bestätigungen

1. Warum interaktive Bash-Tools Usability brauchen

Ein interaktives Bash-Tool, das täglich von mehreren Personen genutzt wird, muss dieselbe Sorgfalt bei der Bedienbarkeit erhalten wie eine Webanwendung. Wenn ein Deployment-Skript mit einem nackten read-Prompt auf Eingabe wartet, ist nicht klar, welche Werte erwartet werden, ob Groß-/Kleinschreibung wichtig ist oder ob die Eingabe optonal ist. Diese Unklarheit erzeugt Fehler und kostet Zeit. Interaktive Bash-Werkzeuge mit klarer Prompt-Formulierung, Hinweisen zu erlaubten Werten und Default-Anzeigen reduzieren diese Fehlerklasse auf null.

Die zweite Dimension: Sicherheit durch Bestätigung. Jede interaktive Bash-Aktion, die irreversibel ist – Datenbankdrop, Produktions-Deployment, Massenumzug von Dateien –, verdient einen expliziten Bestätigungsdialog. Das Muster read -rp "Typ 'yes' zum Bestätigen: " stellt sicher, dass niemand durch versehentliches Enter-Drücken eine kritische Aktion auslöst. In CI/CD-Umgebungen, die keine Benutzereingabe haben, muss das Skript diese Bestätigungen über Flags überspringen können – das ermöglicht denselben Code für manuellen und automatisierten Einsatz.

Das dritte Argument: Professionelle Ausgaben. Farbige Statusmeldungen (grün für Erfolg, rot für Fehler, gelb für Warnungen) sind in interaktiven Bash-Tools mit ANSI-Escape-Codes in wenigen Zeilen implementierbar – ohne externe Tools. Fortschrittsanzeigen für lang laufende Operationen verhindern, dass Benutzer glauben, das Skript sei eingefroren. Diese Aspekte zusammen machen den Unterschied zwischen einem Skript, das nur der Autor benutzen kann, und einem Tool, das ein ganzes Team produktiv nutzt.

2. select: nummerierte Auswahlmenüs

Das Builtin select ist das eleganteste Werkzeug in Bash für nummerierte Auswahlmenüs in interaktiven Bash-Tools. Es nummeriert eine Liste automatisch, zeigt einen konfigurierbaren Prompt (PS3), liest die Auswahl ein und stellt den gewählten Wert in $REPLY (die Zahl) und in der Loop-Variable (den Text) zur Verfügung. Der Code ist deutlich kürzer und fehlerunanfälliger als ein manuell implementiertes Menü mit case und read. Fehleingaben (leere Eingabe, ungültige Zahl) werden von select implizit behandelt – die Variable bleibt leer, die Schleife läuft weiter.

Ein häufiges Missverständnis bei select in Bash: Die Schleife läuft nicht nur einmal, sondern bis ein explizites break aufgerufen wird. Das ist das gewünschte Verhalten für Hauptmenüs, die nach einer Aktion wieder angezeigt werden sollen. Für einmalige Auswahlen kommt sofort nach der Verarbeitung ein break. Der Prompt PS3 sollte immer gesetzt werden – der Standard-Prompt #? ist für Benutzer nichtssagend. Ein gutes interaktives Bash-Menü setzt PS3 auf eine beschreibende Frage wie "Ihre Wahl: ".

#!/usr/bin/env bash
# interactive_menu.sh — Professional select menu with colors
set -euo pipefail

# ANSI color codes — check terminal support first
if [[ -t 1 ]] && tput colors &>/dev/null; then
  RED="$(tput setaf 1)" GREEN="$(tput setaf 2)"
  YELLOW="$(tput setaf 3)" BLUE="$(tput setaf 4)"
  BOLD="$(tput bold)" RESET="$(tput sgr0)"
else
  RED="" GREEN="" YELLOW="" BLUE="" BOLD="" RESET=""
fi

# Formatted output helpers
info()    { printf '%s[INFO]%s  %s\n' "$BLUE"   "$RESET" "$*"; }
success() { printf '%s[OK]%s    %s\n' "$GREEN"  "$RESET" "$*"; }
warn()    { printf '%s[WARN]%s  %s\n' "$YELLOW" "$RESET" "$*" >&2; }
error()   { printf '%s[ERROR]%s %s\n' "$RED"    "$RESET" "$*" >&2; }

# Main menu with select
show_deployment_menu() {
  local environments=("production" "staging" "development" "Exit")
  local choice

  PS3="${BOLD}Select deployment target: ${RESET}"

  select choice in "${environments[@]}"; do
    case "$choice" in
      "production")
        warn "Production deployment selected!"
        confirm_action "Deploy to PRODUCTION" && deploy "production" || info "Cancelled."
        break
        ;;
      "staging")
        info "Staging deployment selected"
        deploy "staging"
        break
        ;;
      "development")
        deploy "development"
        break
        ;;
      "Exit")
        info "Exiting."
        exit 0
        ;;
      *)
        error "Invalid choice '$REPLY' — please enter a number from the list"
        ;;
    esac
  done
}

deploy() {
  local env="$1"
  success "Deploying to $env…"
  # deployment logic here
}

show_deployment_menu

3. read: Eingaben sicher einlesen

Das read-Builtin ist das Herzstück jedes interaktiven Bash-Tools. Die wichtigste Variante ist read -r: Das -r-Flag deaktiviert die Interpretation von Backslashes, was bei der Eingabe von Dateipfaden und regulären Ausdrücken unverzichtbar ist. Ohne -r wird \n in der Eingabe als Newline interpretiert – ein häufiger, schwer debugbarer Bug. read -rp "Prompt: " zeigt den Prompt direkt vor dem Cursor, ohne dass ein separates echo nötig ist.

Für Passworteingaben in interaktiven Bash-Tools gibt es read -rs: -s (silent) deaktiviert das Echo der Eingabe, sodass das Passwort unsichtbar bleibt. Nach der Eingabe muss manuell ein Newline ausgegeben werden (echo), da -s auch den automatischen Zeilenumbruch nach Enter unterdrückt. Mehrzeilige Eingaben lassen sich mit read -r -d '' (null-delimiter) einlesen – die Eingabe läuft bis zu einem Ctrl+D oder bis zum Nullbyte. Das ist nützlich für interaktive Texteditoren im Terminal.

4. Timeouts und Default-Werte

In interaktiven Bash-Tools, die in halbautomatisierten Prozessen laufen (z. B. Deployment-Skripte, die normalerweise automatisch laufen, aber bei Bedarf Interaktion ermöglichen), ist ein Timeout für Eingaben essenziell. read -t 30 -rp "Fortfahren? [J/n] " wartet maximal 30 Sekunden und gibt Exit-Code 1 zurück, wenn keine Eingabe erfolgt. Das Skript kann dann mit einem Default-Wert fortfahren. Dieses Muster kombiniert manuellen und automatisierten Betrieb in einem einzigen Skript.

Der Timeout-Wert sollte großzügig gewählt werden – Benutzer, die gerade abgelenkt sind oder kurz die Bildschirmausgabe lesen, brauchen mehr als fünf Sekunden für eine Entscheidung. 30–60 Sekunden sind für kritische Aktionen angemessen. Das interaktive Bash-Skript soll nach Ablauf des Timeouts den sichersten Default-Wert wählen – bei einem Deployment-Skript typischerweise Abbruch, nicht Fortfahren. Der Countdown zum Timeout kann sichtbar angezeigt werden, was die UX erheblich verbessert.

#!/usr/bin/env bash
# input_handling.sh — Robust input functions for interactive Bash tools
set -euo pipefail

# Read with timeout and fallback default
read_with_timeout() {
  local prompt="$1" default="$2" timeout="${3:-30}"
  local input

  if read -t "$timeout" -rp "$prompt [$default]: " input 2>/dev/null; then
    echo "${input:-$default}"
  else
    echo ""  # newline after timeout
    echo "$default"
    return 0
  fi
}

# Read password silently
read_password() {
  local prompt="${1:-Password}"
  local pass

  read -rs -p "$prompt: " pass
  echo ""  # newline — -s suppresses it
  echo "$pass"
}

# Countdown display before timeout default action
read_with_countdown() {
  local message="$1" default_action="$2" seconds="${3:-15}"
  local i

  for (( i = seconds; i > 0; i-- )); do
    printf '\r%s — proceeding with "%s" in %2d seconds (Ctrl+C to abort)' \
      "$message" "$default_action" "$i"
    sleep 1 &
    local sleep_pid=$!

    # Check for keypress without blocking
    if read -t 1 -rn 1 -p "" key 2>/dev/null; then
      wait "$sleep_pid" 2>/dev/null || true
      echo ""
      echo "$key"
      return 0
    fi
    wait "$sleep_pid" 2>/dev/null || true
  done

  echo ""
  echo "$default_action"
}

# Example usage
version="$(read_with_timeout "Version to deploy" "$(git describe --tags --abbrev=0 2>/dev/null || echo 'latest')" 30)"
echo "Deploying version: $version"

action="$(read_with_countdown "No input detected" "skip" 15)"
echo "Action: $action"

5. Eingabevalidierung und Wiederholung

Rohes read ohne Validierung in interaktiven Bash-Tools ist ein offenes Tor für fehlerhafte Eingaben, die den Skriptablauf in undefinierte Zustände bringen. Eine Validierungsfunktion, die einen Prompt wiederholt solange die Eingabe nicht den erwarteten Kriterien entspricht, ist das robusteste Muster. Die Kriterien können eine Regex sein ([[ "$input" =~ ^[0-9]+$ ]] für Zahlen), eine Whitelist von Werten ([[ "$input" == "yes" || "$input" == "no" ]]) oder eine benutzerdefinierte Validierungsfunktion, die true/false zurückgibt.

Für interaktive Bash-Eingaben mit komplexer Validierung lohnt es sich, eine generische ask()-Funktion zu schreiben, die Prompt, Validierungsregex und Fehlermeldung als Parameter nimmt. Diese Funktion schleift so lange, bis eine valide Eingabe vorliegt. Eine maximale Anzahl von Wiederholungen verhindert Endlosschleifen bei falsch konfigurierten Skripten. Nach der maximalen Anzahl von Versuchen bricht das Skript mit einem klaren Fehler ab – Benutzer sollen nicht endlos falsche Eingaben machen können.

6. Bestätigungsdialoge für gefährliche Aktionen

Der wirksamste Schutzmechanismus gegen versehentlich ausgeführte destruktive Aktionen in interaktiven Bash-Tools ist ein expliziter Bestätigungsdialog mit erschwerter Zustimmung. Statt einem einfachen y/n-Prompt, der durch einfaches Enter-Drücken ausgelöst werden kann, soll der Benutzer ein spezifisches Wort eintippen – typischerweise den Namen der Umgebung, der Ressource oder eine Phrase wie destroy. Das zwingt zur bewussten Auseinandersetzung mit der Aktion und verhindert reflexartiges Bestätigen.

Das Muster für sichere Bestätigungen in interaktiven Bash-Skripten: Den Benutzer auffordern, den Ressourcennamen zu tippen, dann den eingetippten Wert mit dem Erwarteten vergleichen. Nur bei exakter Übereinstimmung wird die Aktion ausgeführt. In CI-Umgebungen ohne Terminal gibt eine Hilfsvariable wie $FORCE_YES=1 oder ein --yes-Flag die Bestätigung implizit – aber nur wenn das Skript explizit im Nicht-Interaktiv-Modus gestartet wurde, erkennbar an [[ ! -t 0 ]] (stdin ist kein Terminal).

#!/usr/bin/env bash
# confirmations.sh — Safe confirmation dialogs for destructive actions
set -euo pipefail

FORCE="${FORCE:-0}"

# Detect if running in interactive terminal
is_interactive() {
  [[ -t 0 && -t 1 ]]
}

# Simple yes/no confirmation
confirm() {
  local message="${1:-Continue?}"

  # In CI or non-interactive mode: require explicit FORCE=1
  if ! is_interactive; then
    if [[ "$FORCE" == "1" ]]; then
      return 0
    else
      echo "[ERROR] Non-interactive mode: set FORCE=1 to proceed without confirmation" >&2
      return 1
    fi
  fi

  local reply
  read -rp "${message} [y/N] " reply
  [[ "${reply,,}" =~ ^(y|yes)$ ]]
}

# Strong confirmation: requires typing a specific word
confirm_action() {
  local action="$1" confirm_word="${2:-yes}"

  if ! is_interactive; then
    [[ "$FORCE" == "1" ]] && return 0 || { echo "[ERROR] FORCE=1 required" >&2; return 1; }
  fi

  echo ""
  printf '  \033[1;31m⚠  WARNING:\033[0m %s\n\n' "$action"
  printf '  Type \033[1m%s\033[0m to confirm: ' "$confirm_word"

  local input
  read -r input

  if [[ "$input" == "$confirm_word" ]]; then
    echo ""
    return 0
  else
    echo ""
    echo "[ABORT] Confirmation failed — action cancelled."
    return 1
  fi
}

# Confirmation with production environment check
deploy_with_confirmation() {
  local env="$1" version="$2"

  if [[ "$env" == "production" ]]; then
    confirm_action "Deploy version $version to PRODUCTION" "deploy-production" || return 0
  else
    confirm "Deploy $version to $env?" || { echo "Cancelled."; return 0; }
  fi

  echo "Starting deployment of $version to $env…"
}

deploy_with_confirmation "production" "v2.3.0"

7. Farben und Formatierung im Terminal

ANSI-Escape-Codes für Farben machen interaktive Bash-Tools erheblich lesbarer – aber nur wenn das Terminal sie unterstützt. Das korrekte Muster ist immer: Vor der Nutzung von Farben mit tput colors und [[ -t 1 ]] prüfen, ob das Terminal Farben unterstützt und ob die Ausgabe tatsächlich in ein Terminal geht (nicht in eine Pipe oder Datei). Wenn Farben nicht verfügbar sind, werden die Escape-Code-Variablen auf leere Strings gesetzt – der restliche Code läuft ohne Änderung weiter.

Für interaktive Bash-Ausgaben empfiehlt sich eine Farbpalette, die auf wenige semantische Farben beschränkt ist: Grün für Erfolg, Rot für Fehler, Gelb für Warnungen, Cyan oder Blau für Informationen. Das Überladen mit vielen Farben macht die Ausgabe unübersichtlicher. tput ist gegenüber direkten ANSI-Escape-Codes vorzuziehen, weil es portabler ist: tput setaf 2 für Grün, tput sgr0 zum Zurücksetzen. Auf Systemen ohne tput-Unterstützung fallen die Codes auf No-Ops zurück, während direkte ANSI-Codes als rohe Escape-Sequenzen in der Ausgabe erscheinen.

8. Fortschrittsanzeigen und Spinner

Lang laufende Operationen in interaktiven Bash-Tools ohne Fortschrittsanzeige lassen Benutzer im Dunkeln darüber, ob das Skript noch arbeitet oder eingefroren ist. Ein einfacher Spinner – sich drehendes Zeichen, das die aktive Verarbeitung signalisiert – lässt sich mit einer Hintergrundschleife implementieren: Den Prozess im Hintergrund starten, die PID speichern, den Spinner laufen lassen, auf den Prozess warten, den Spinner stoppen. Das Muster nutzt tput civis (Cursor verstecken) und tput cnorm (Cursor wiederherstellen), um die Ausgabe sauber zu halten.

Für Operationen, bei denen der Fortschritt bekannt ist (Verarbeitung von N Dateien), ist ein prozentualer Fortschrittsbalken sinnvoller als ein Spinner. Das Muster in interaktiven Bash-Tools: Gesamtzahl bestimmen, in der Schleife aktuellen Index durch Gesamtzahl dividieren, Balken aus Unicode-Zeichen oder ASCII-Zeichen zusammensetzen und mit \r (Wagenrücklauf) in derselben Zeile überschreiben. Das vermeidet das Herunterscrollen der Ausgabe und hält die Statusanzeige statisch.

9. Interaktive Skripte nicht-interaktiv machen

Das eleganteste Merkmal professioneller interaktiver Bash-Tools ist ihre Fähigkeit, sowohl interaktiv als auch vollautomatisch zu funktionieren. Das Skript prüft beim Start, ob es in einem Terminal läuft ([[ -t 0 ]] für stdin, [[ -t 1 ]] für stdout). Im Nicht-Interaktiv-Modus (Pipeline, CI/CD) werden alle Prompts übersprungen und stattdessen Standardwerte oder explizit übergebene CLI-Argumente verwendet.

CLI-Argumente mit einer einfachen Argument-Parser-Funktion einzulesen ist der sauberste Weg für interaktive Bash-Tools, die auch nicht-interaktiv nutzbar sein sollen. Eine Funktion, die $@ durchläuft und bekannte Flags wie --env production, --version v1.2.0 und --yes auswertet, braucht keine externe Bibliothek. Unbekannte Flags werden mit einem Fehler und der Usage-Ausgabe abgelehnt. So hat das Tool eine saubere API für beide Nutzungsformen.

10. Zusammenfassung

Professionelle interaktive Bash-Tools bauen auf vier Techniken: select mit gesetztem PS3 für nummerierte Menüs, read -r für sichere Texteingaben mit optionalem Timeout, ANSI-Farben über tput für semantisch codierte Ausgaben und explizite Bestätigungsdialoge für destruktive Aktionen. Diese Kombination schafft Shell-Werkzeuge, die sowohl erfahrene als auch weniger erfahrene Nutzer sicher bedienen können.

Der praktische Einstieg: Bestehende Skripte um einen Bestätigungsdialog für jede irreversible Aktion erweitern. Das erhöht sofort das Sicherheitsniveau ohne großen Umbau. Danach Farbcodes einführen für klarere Status-Kommunikation. Schließlich Menüs mit select für häufig genutzte Auswahlentscheidungen, die bisher als Argument übergeben wurden. So werden Skripte schrittweise zu vollwertigen Tools, die ein ganzes Team produktiv nutzt.

11. FAQ: Interaktive Bash-Tools mit select, read, Menüs und Bestätigungen