Dry-Run und Bestätigung in Admin-Skripten: PowerShell -WhatIf/-Confirm und ein --dry-run-Flag in der Shell

Ziel

Ein Admin-Skript erhält einen Modus, der anzeigt, was es tun würde, sowie eine Möglichkeit für den Aufrufer, vor jeder zustandsändernden Aktion eine ausdrückliche Bestätigung zu verlangen.

Voraussetzungen

PowerShell-Funktionen, die als Advanced Functions geschrieben sind ([CmdletBinding()]); für Shell-Skripte ist keine besondere Ausstattung nötig, nur eine Konvention.

Schritte

1. In PowerShell [CmdletBinding(SupportsShouldProcess)] direkt über den param()-Block der Funktion setzen. about_Functions_CmdletBindingAttribute beschreibt SupportsShouldProcess als die Eigenschaft, die der Funktion automatisch die allgemeinen Parameter -WhatIf und -Confirm hinzufügt – die Schalter müssen nicht selbst implementiert werden.
2. Vor jeder zustandsändernden Zeile if ($PSCmdlet.ShouldProcess($target, $action)) { <do the change> } aufrufen. about_Functions_Advanced_Methods beschreibt ShouldProcess als die Methode, die -WhatIf/-Confirm prüft und zurückgibt, ob die Operation ausgeführt werden soll; wurde -WhatIf übergeben, gibt ShouldProcess die Zeile "What if:" aus und liefert $false zurück, ohne dass diese Logik selbst geschrieben werden muss.
3. Jedes aufgerufene Cmdlet, das selbst -WhatIf unterstützt, sollte den Schalter explizit erhalten (Remove-Item @params -WhatIf:$WhatIfPreference), damit ein Dry-Run der eigenen Funktion auch ein Dry-Run von allem ist, was sie aufruft. Die Preference wird nur an Befehle in derselben Scope-Kette automatisch weitergegeben, nicht zuverlässig in andere Module.
4. Bei destruktiven Aktionen im CmdletBinding-Attribut ConfirmImpact = 'High' setzen, damit eine Bestätigungsabfrage auch dann erscheint, wenn der Aufrufer -Confirm nicht angegeben hat (der Standardwert von $ConfirmPreference ist High). In einer mit -NonInteractive gestarteten Sitzung schlägt diese Abfrage fehl, statt zu warten; unbeaufsichtigte Aufrufer müssen daher bewusst -Confirm:$false übergeben.
5. In einem Shell-Skript ein explizites Flag --dry-run (oder -n) einführen, das zu Beginn in eine Variable eingelesen wird, z. B. DRY_RUN=0. Jeden zustandsändernden Befehl kapseln: run() { if [ "$DRY_RUN" = 1 ]; then echo "DRY-RUN: $*"; else "$@"; fi; }. Danach jeden verändernden Befehl über run rm -f "$path" usw. aufrufen, ohne die Logik, die über das Auszuführende entscheidet, zu duplizieren.
6. Den Dry-Run-Plan in derselben Form ausgeben, in der der echte Lauf protokolliert, damit der Vergleich der Ausgabe eines Dry-Runs mit der eines echten Laufs aussagekräftig ist.
7. Für Bestätigungen ohne vollständiges TTY (agentengesteuerte, nicht interaktive Kontexte) als Standard ein ausdrückliches --yes/-Confirm:$false verlangen, statt standardmässig stillschweigend fortzufahren; ein Flag soll zum Überspringen der Bestätigung nötig sein, nicht zu ihrer Anforderung.

Erwartetes Ergebnis

MyFunction -WhatIf und --dry-run eines Shell-Skripts melden beide jede Aktion, die sie ausführen würden, ohne etwas zu verändern. Ohne diese Flags führt das Skript dieselben Aktionen aus, die der Dry-Run beschrieben hat, und zwischen beiden Pfaden ist keine Logik dupliziert.

Grenzen und Prüfbasis

ShouldProcess schützt nur die Codepfade, um die es gelegt wird; eine Funktion kann SupportsShouldProcess deklarieren und trotzdem in einem Zweig, der ShouldProcess nie aufruft, Zustand verändern. Daher ist jede verändernde Zeile einzeln zu prüfen. Der Shell-Wrapper run() erzeugt keine zutreffende Ausgabe für Befehle, deren tatsächliche Wirkung von Daten abhängt, die sich erst durch die echte Ausführung zeigen (z. B. eine Abfrage, die eine Zeilenanzahl liefert); die Dry-Run-Ausgabe ist dafür zwangsläufig eine Annäherung. Umleitungen führt die aufrufende Shell aus, bevor run gestartet wird; run cmd > file kürzt file also auch im Dry-Run-Modus. Solche Schritte in run sh -c '...' oder in eine Funktion packen.