Beherrschung von Positionsparametern: Ein Leitfaden für Bash-Skript-Argumente

Bash-Skripte werden viel nützlicher, wenn sie Argumente akzeptieren, anstatt dass Sie Variablen in der Datei bearbeiten müssen. Ein Backup-Skript sollte ein Quellverzeichnis akzeptieren. Ein Bereitstellungsskript sollte einen Umgebungsnamen akzeptieren. Ein Bereinigungsskript sollte einen oder mehrere Pfade akzeptieren. Diese Werte kommen als Positionsparameter an: $1, $2, $3 und so weiter.

Der knifflige Teil ist nicht das Lesen von $1. Der knifflige Teil ist der Umgang mit fehlenden Argumenten, Argumenten mit Leerzeichen, optionalen Flags und dem Moment, in dem Ihr Skript von "nur für mich" zu etwas wird, das eine andere Person um 2 Uhr morgens ausführen wird.

Die Anatomie von Positionsparametern

Positionsparameter sind spezielle Variablen, die von der Shell definiert werden und den Wörtern entsprechen, die in der Befehlszeile nach dem Skriptnamen angegeben werden. Sie sind fortlaufend nummeriert, beginnend mit 1.

Parameter	Beschreibung	Beispielwert (bei Ausführung von `./script.sh file1 dir/`)
`$0`	Der Name des Skripts selbst (oder der Funktion).	`./script.sh`
`$1`	Das erste an das Skript übergebene Argument.	`file1`
`$2`	Das zweite an das Skript übergebene Argument.	`dir/`
`$N`	Das N-te Argument (wobei N > 0).
`${10}`	Argumente jenseits von 9 müssen in geschweifte Klammern gesetzt werden.

Zugriff auf Argumente jenseits von $9

Während auf die Argumente 1 bis 9 direkt als $1 bis $9 zugegriffen wird, erfordert der Zugriff auf das zehnte Argument und folgende Argumente das Einschließen der Nummer in geschweifte Klammern, um Mehrdeutigkeiten mit Umgebungsvariablen oder Zeichenfolgenoperationen zu vermeiden (z. B. ${10} anstelle von $10).

Wesentliche spezielle Parameter für die Skripterstellung

Über die numerischen Parameter hinaus bietet Bash mehrere kritische spezielle Variablen, die sich auf den gesamten Argumentsatz beziehen. Diese sind für die Validierung und Iteration unverzichtbar.

Zählen von Argumenten mit `$#`

Die spezielle Variable $# enthält die Gesamtzahl der an das Skript übergebenen Befehlszeilenargumente (ohne $0). Dies ist vielleicht die wichtigste Variable für die Implementierung von Eingabevalidierungen.

#!/bin/bash

if [ "$#" -eq 0 ]; then
    echo "Fehler: Keine Argumente angegeben."
    echo "Verwendung: $0 <eingabedatei>"
    exit 1
fi

echo "Sie haben $# Argumente angegeben."

Alle Argumente: `$@` und `$*`

Die Variablen $@ und $* repräsentieren beide die vollständige Liste der Argumente, verhalten sich jedoch unterschiedlich – insbesondere wenn sie in Anführungszeichen gesetzt werden.

`$*` (Einzelne Zeichenfolge)

Wenn in doppelte Anführungszeichen gesetzt ("$*"), wird die gesamte Liste der Positionsparameter als ein einzelnes Argument behandelt, getrennt durch das erste Zeichen der IFS-Variablen (Internal Field Separator) (normalerweise ein Leerzeichen).

Wenn die Eingabeargumente sind: arg1 arg2 arg3
"$*" erweitert sich zu: "arg1 arg2 arg3" (ein einzelnes Element)

`$@` (Getrennte Zeichenfolgen - Bevorzugt)

Wenn in doppelte Anführungszeichen gesetzt ("$@"), wird jeder Positionsparameter als separates, in Anführungszeichen gesetztes Argument behandelt. Dies ist die Standard- und bevorzugte Methode zum Iterieren über Argumente, da sie Argumente mit Leerzeichen korrekt erhält.

Wenn die Eingabeargumente sind: arg1 "arg mit leerzeichen" arg3
"$@" erweitert sich zu: "arg1" "arg mit leerzeichen" "arg3" (drei verschiedene Elemente)

Warum Anführungszeichen wichtig sind: Eine Demonstration

Betrachten Sie ein Skript, das mit Argumenten ausgeführt wird: ./test.sh 'hallo welt' datei.txt

#!/bin/bash

# Unquoted $* splits on spaces and is usually wrong.
echo "-- Schleife mit unquotetem \$* --"
for item in $*; do
    echo "Element: $item"
done

# Quoted "$@" preserves each original argument.
echo "-- Schleife mit quotetem \$@ --"
for item in "$@"; do
    echo "Element: $item"
done

Mit ./test.sh 'hallo welt' datei.txt gibt die unquotete Schleife hallo und welt als separate Elemente aus. Die "$@"-Schleife behält hallo welt als ein Argument. Dieser Unterschied ist der Grund, warum erfahrene Shell-Benutzer fast automatisch zu "$@" greifen.

Praktische Techniken für die Argumentverarbeitung

1. Einfaches Skript zum Abrufen von Argumenten

Dieses einfache Skript zeigt, wie Sie auf bestimmte Parameter zugreifen und $0 verwenden, um hilfreiches Feedback zu geben.

deploy_service.sh:

#!/bin/bash
# Verwendung: deploy_service.sh <dienstname> <umgebung>

SERVICE_NAME="$1"
ENVIRONMENT="$2"

# Validierungsprüfung (mindestens zwei Argumente)
if [ "$#" -lt 2 ]; then
    echo "Verwendung: $0 <dienstname> <umgebung>"
    exit 1
fi

echo "Starte Bereitstellung für Dienst: $SERVICE_NAME"
echo "Zielumgebung: $ENVIRONMENT"

# Befehl mit den validierten Parametern ausführen
ssh admin@server-"$ENVIRONMENT" "/pfad/zu/start $SERVICE_NAME"

2. Robuste Eingabevalidierung

Gute Skripte validieren die Eingabe immer, bevor sie fortfahren. Dies beinhaltet die Überprüfung der Anzahl ($#) und oft die Überprüfung des Inhalts der Argumente (z. B. Prüfen, ob ein Argument eine Zahl oder ein gültiger Dateipfad ist).

#!/bin/bash

# 1. Argumentanzahl prüfen (Muss genau 3 sein)
if [ "$#" -ne 3 ]; then
    echo "Fehler: Dieses Skript erfordert drei Argumente (quelle, ziel, benutzer)."
    echo "Verwendung: $0 <quellpfad> <zielpfad> <benutzer>"
    exit 1
fi

SRC_PATH="$1"
DEST_PATH="$2"
USER="$3"

# 2. Inhalt prüfen (Beispiel: Überprüfen, ob der Quellpfad existiert)
if [ ! -f "$SRC_PATH" ]; then
    echo "Fehler: Quelldatei '$SRC_PATH' nicht gefunden oder ist keine Datei."
    exit 2
fi

# Wenn die Validierung bestanden ist, fortfahren
echo "Kopiere $SRC_PATH nach $DEST_PATH als Benutzer $USER..."

Best Practice Tipp: Geben Sie immer eine klare, prägnante Verwendung:-Anweisung an, wenn die Validierung fehlschlägt. Dies hilft Benutzern, ihren Befehlsaufruf schnell zu korrigieren.

3. Iterieren von Argumenten mit `shift`

Der shift-Befehl ist ein hervorragendes Werkzeug, um Argumente sequentiell zu verarbeiten, oft verwendet bei der Handhabung einfacher Flags oder bei der Verarbeitung von Argumenten einzeln innerhalb einer while-Schleife.

shift verwirft das aktuelle $1-Argument, verschiebt $2 nach $1, $3 nach $2 und dekrementiert $# um eins. Dies ermöglicht es Ihnen, das erste Argument zu verarbeiten und dann zu schleifen, bis keine Argumente mehr übrig sind.

#!/bin/bash

# Ein einfaches -v Flag verarbeiten und dann die verbleibenden Dateien auflisten

VERBOSE=false

if [ "$1" = "-v" ]; then
    VERBOSE=true
    shift  # Das -v Flag verwerfen und Argumente nach oben verschieben
fi

if $VERBOSE; then
    echo "Ausführlicher Modus aktiviert."
fi

if [ "$#" -eq 0 ]; then
    echo "Keine Dateien angegeben."
    exit 0
fi

echo "Verarbeite $# verbleibende Dateien:"
for datei in "$@"; do
    if $VERBOSE; then
        echo "Prüfe Datei: $datei"
    fi
    # ... Verarbeitungslogik hier
done

Hinweis: shift ist nützlich für einfaches Parsen. Für komplexe Skripte mit vielen Flags ist getopts normalerweise die bessere Wahl für kurze Optionen. Die Handhabung langer Optionen variiert je nach Plattform, testen Sie daher sorgfältig, wenn Sie externes getopt verwenden.

Ein realistischeres Parser-Skript

Viele interne Skripte beginnen mit einem optionalen Flag und einem erforderlichen Wert. Hier ist ein kleines Muster, das lesbar bleibt:

#!/usr/bin/env bash
set -u

dry_run=false
environment=""

usage() {
    echo "Verwendung: $0 [--dry-run] --env <dev|staging|prod> <datei>..." >&2
}

while [ "$#" -gt 0 ]; do
    case "$1" in
        --dry-run)
            dry_run=true
            shift
            ;;
        --env)
            if [ "$#" -lt 2 ]; then
                echo "Fehler: --env erfordert einen Wert." >&2
                usage
                exit 2
            fi
            environment="$2"
            shift 2
            ;;
        --help|-h)
            usage
            exit 0
            ;;
        --)
            shift
            break
            ;;
        -*)
            echo "Fehler: unbekannte Option: $1" >&2
            usage
            exit 2
            ;;
        *)
            break
            ;;
    esac
done

if [ -z "$environment" ]; then
    echo "Fehler: --env ist erforderlich." >&2
    usage
    exit 2
fi

if [ "$#" -eq 0 ]; then
    echo "Fehler: Geben Sie mindestens eine Datei an." >&2
    usage
    exit 2
fi

for datei in "$@"; do
    if [ ! -f "$datei" ]; then
        echo "Fehler: Datei nicht gefunden: $datei" >&2
        exit 3
    fi

    if $dry_run; then
        echo "Würde $datei nach $environment hochladen"
    else
        echo "Lade $datei nach $environment hoch"
        # Upload-Befehl hier einfügen
    fi
done

Beachten Sie die langweiligen Details. Fehlermeldungen gehen an stderr. -- bedeutet "Höre auf, Optionen zu parsen", was es jemandem ermöglicht, einen Dateinamen zu übergeben, der mit einem Bindestrich beginnt. Die letzte Dateischleife verwendet "$@", sodass release notes.txt ein Dateiname bleibt.

Häufige Fehler

Der häufigste Fehler ist das Vergessen von Anführungszeichen:

cp $1 $2

Das bricht, wenn einer der Pfade Leerzeichen oder Shell-Glob-Zeichen enthält. Verwenden Sie:

cp -- "$1" "$2"

Das -- teilt vielen Befehlen mit, dass die Optionsverarbeitung beendet ist, was hilft, wenn ein Pfad mit - beginnt.

Ein weiterer häufiger Fehler ist das zu späte Validieren. Wenn Ihr Skript zwei Argumente erwartet, überprüfen Sie dies, bevor Sie etwas Zerstörerisches tun:

if [ "$#" -ne 2 ]; then
    echo "Verwendung: $0 <quelle> <ziel>" >&2
    exit 2
fi

Verwenden Sie unterschiedliche Exit-Codes, wenn es dem Aufrufer hilft. Ein Verwendungsfehler könnte 2 sein; eine fehlende Datei könnte 3 sein; ein fehlgeschlagener externer Befehl kann seinen eigenen Status behalten. Sie benötigen keine riesige Exit-Code-Taxonomie, aber die Rückgabe von 0 nach einem fehlerhaften Aufruf macht die Automatisierung schwerer vertrauenswürdig.

Funktionen haben auch Positionsparameter

Innerhalb einer Bash-Funktion beziehen sich $1 und $2 auf die Argumente der Funktion, nicht auf die ursprünglichen Argumente des Skripts.

log_copy() {
    local src="$1"
    local dest="$2"

    echo "Kopiere $src nach $dest"
    cp -- "$src" "$dest"
}

log_copy "$1" "$2"

Das ist nützlich, kann Sie aber überraschen, wenn Sie erwartet haben, dass $1 innerhalb der Funktion das erste Argument auf Skriptebene bedeutet. Übergeben Sie Werte explizit. Das macht die Funktion einfacher zu testen und einfacher wiederzuverwenden.

Weiterleiten von Argumenten an einen anderen Befehl

Viele Wrapper-Skripte existieren nur, um ein wenig Einrichtung hinzuzufügen, bevor sie einen anderen Befehl aufrufen. In diesem Fall ist "$@" das, was den Wrapper ehrlich hält.

#!/usr/bin/env bash
set -e

export APP_ENV=staging
exec /usr/local/bin/myapp "$@"

Wenn jemand ausführt:

./run-staging.sh --config "config mit leerzeichen.yml" --verbose

erhält der umschlossene Befehl dieselben drei Argumente. Wenn Sie $* oder unquotetes $@ verwendet hätten, könnte der Konfigurationspfad in mehrere Wörter aufgeteilt werden.

exec ist optional, aber oft nützlich in Wrappern, da es den Shell-Prozess durch den Zielprozess ersetzt. Das macht Signale unter systemd, Docker oder einer Prozessüberwachung vorhersehbarer.

Standardwerte ohne Überraschungen

Manchmal sollte ein Argument optional sein. Bash-Parametererweiterung kann helfen:

environment="${1:-dev}"

Das bedeutet "verwende $1, wenn es gesetzt und nicht leer ist; andernfalls verwende dev." Das ist in Ordnung für freundliche lokale Skripte, aber seien Sie vorsichtig bei Produktionsskripten. Ein stiller Standardwert kann in der falschen Umgebung bereitstellen, wenn jemand ein Argument vergisst.

Für riskante Befehle bevorzugen Sie explizite Eingabe:

if [ "$#" -lt 1 ]; then
    echo "Verwendung: $0 <umgebung>" >&2
    exit 2
fi

Standardwerte sind am besten, wenn die Konsequenz gering ist, wie z. B. das Standardisieren einer Protokollebene oder eines Ausgabeverzeichnisses. Sie sind riskant, wenn das Argument einen Server auswählt, Daten löscht oder ein Bereitstellungsziel ändert.

Positionsparameter und `set -u`

Viele Bash-Skripte verwenden set -u, sodass nicht gesetzte Variablen einen Fehler verursachen. Das kann Tippfehler abfangen, ändert aber auch das Verhalten fehlender Positionsparameter.

#!/usr/bin/env bash
set -u

echo "Erstes Argument: $1"

Führen Sie dieses Skript ohne Argumente aus und Bash beendet sich mit einem "unbound variable"-Fehler. Dieser Fehler ist technisch korrekt, aber nicht benutzerfreundlich. Validieren Sie $#, bevor Sie erforderliche Parameter lesen:

if [ "$#" -lt 1 ]; then
    echo "Verwendung: $0 <eingabedatei>" >&2
    exit 2
fi

input_file="$1"

Für optionale Parameter unter set -u verwenden Sie eine geschützte Erweiterung:

mode="${2:-default}"

Das hält den strikten Modus nützlich, ohne dass fehlende optionale Werte das Skript zum Absturz bringen.

Wann Positionsparameter die falsche Schnittstelle sind

Positionsparameter sind großartig für kleine Befehle:

backup.sh /var/www /backup/www.tar.gz

Sie werden schwer lesbar, wenn das Skript viele Werte annimmt:

deploy.sh prod us-east-1 api v2.4.1 true false 30

Niemand möchte sich merken, was das fünfte Argument bedeutet. Sobald ein Skript diesen Punkt erreicht, verwenden Sie benannte Flags oder eine Konfigurationsdatei:

deploy.sh --env prod --region us-east-1 --service api --version v2.4.1 --timeout 30

Der Code ist etwas länger, aber die Befehlszeile wird selbstdokumentierend. Das ist ein guter Kompromiss für Skripte, die von einem Team verwendet werden.

Gute Handhabung von Positionsparametern ist meist Disziplin: frühzeitig validieren, jede Erweiterung in Anführungszeichen setzen, es sei denn, Sie möchten absichtlich eine Aufteilung, "$@" zum Weiterleiten von Argumenten verwenden und Verwendungsmeldungen nahe an den Prüfungen halten, die sie auslösen. Diese Gewohnheiten lassen kleine Skripte echte Dateinamen, echte Benutzer und echte Automatisierung überleben.