BillionPhotos.com - stock.adobe.
PowerShell 7: Neue Tools für die Fehlerbehandlung
PowerShell 7 ist die neue Open-Source-Version des Microsoft-Frameworks. Im Vergleich zu vorherigen Versionen bietet sie höhere Benutzerfreundlichkeit bei der Fehlerbehandlung.
Auf Fehler zu stoßen – und sie zu beheben – ist ein unvermeidlicher Teil der Arbeit mit Technologie, und PowerShell bildet da keine Ausnahme.
Den perfekten Code gibt es nicht. Skripte enthalten Fehler oder müssen auf eine kommende Abtrennung einer Ressource hin ausgerichtet werden. Ein Service kann auf ein Problem stoßen oder eine Eingabedatei schlecht formatiert sein.
Zu lernen, wie man eine Fehlermeldung interpretiert, die Ursache findet und den Fehler möglichst elegant behebt, ist ein wichtiger Aspekt dabei, die PowerShell als Werkzeug einzusetzen. Das Entwicklungsteam hinter der Open-Source-Version von PowerShell 7 hat die Fehlerbehandlung von PowerShell sowohl bei der Ausführung von Skripten als auch bei der Eingabe von Befehlen verbessert.
Dieser Artikel führt am Beispiel eines einfachen Skripts durch die PowerShell-Fehlerbehandlung und stellt mehrere neue Funktionen in PowerShell 7 vor, die den Prozess benutzerfreundlicher machen.
Wo finde ich PowerShell 7?
Zunächst sollte man sicherstellen, dass PowerShell 7 installiert ist. Bis zu deren Veröffentlichung war die neueste Version von PowerShell unter dem Namen PowerShell Core bekannt. Microsoft unterstützt weiterhin PowerShell 5.1, plant aber nicht, die neuen Funktionen zu übernehmen, die das Projektteam für die Open Source PowerShell entwickelt.
PowerShell 7 ist für Windows, Mac und Linux erhältlich. Die neueste Version kann über die PowerShell-GitHub-Seite installiert werden.
Unter Windows kann man PowerShell 7 auch im neuen Windows Terminal verwenden, das Verbesserungen gegenüber dem alten Windows-Konsolen-Host bietet.
Fehlermeldungen in vorherigen Versionen von PowerShell
Ein häufiges Problem für Neueinsteiger in Windows PowerShell 5.1 und die früheren PowerShell-Core-Versionen ist die mangelnde Klarheit in den Fehlermeldungen.Ein Beispiel: man möchte eine Liste lokaler Benutzer in eine CSV-Datei exportieren, aber das Skript enthält einen Tippfehler:
Get-LocalUser |= Export-Csv local_users.csv
Die PowerShell würde dann folgendes ausgeben:
Der Fehlercode enthält wichtige Informationen, nämlich dass ein überflüssiges Gleichheitszeichen enthalten ist. Es kann jedoch schwierig sein, diesen entscheidenden Hinweis in der Wand aus rotem Text zu finden.
Eine alte Variable erhält eine neue Funktion
Die Einstellungsvariable in PowerShell namens $ErrorView war bis dato nur wenig bekannt, weil sie auch nur von geringem Nutzen war.
$ErrorView bestimmt, welche Informationen an die Konsole gesendet werden und wie sie im Falle eines Fehlers formatiert werden. Die Meldung kann variieren, je nachdem ob man eine Skriptdatei ausführt, oder einen Befehl in die Shell eingibt.
In früheren Versionen von PowerShell war $ErrorView auf NormalView voreingestellt – daher die rote Textwand im Screenshot.
Das ändert sich mit PowerShell 7. Es gibt eine neue Option für $ErrorView, die nun die Standardeinstellung ist und ConciseView heißt.
Eindeutigere Formatierung von Fehlern in PowerShell 7
Wenn wir den gleichen fehlerhaften Befehl in PowerShell 7 mit dem neuen standardmäßigen ConciseView ausführen, ist die Fehlermeldung leichter zu verstehen.
Die neue PowerShell-Fehlerbehandlung hebt den Bereich im Befehl, der den Fehler beschreibt mit einer anderen Farbe hervor und überfrachtet nicht mit zu vielen Informationen.
Kürzere Fehlermeldungen in der Shell
Ein weiterer Fehler, der beim Schreiben in eine CSV-Datei auftreten kann, ist, dass die Zieldatei gesperrt ist, zum Beispiel weil sie in Excel geöffnet ist.
Wenn man PowerShell als Shell verwendet, gibt die neue Standard-Fehleransicht jetzt nur noch die Fehlermeldung und keine weiteren Informationen mehr aus. Im Folgenden ist die Ausgabe für den Fehler in PowerShell 5.1 abgebildet.
Im Gegensatz dazu bietet die PowerShell-Fehlerbehandlung in der neuesten Version des Automatisierungs-Tools aufgrund der ConciseView-Option eine viel prägnantere Meldung.
Nun ist leichter zu erkennen, dass die Datei gesperrt ist, und die Behebung des Fehlers kann angegangen werden.
Fehleraufzeichnungen untersuchen
Wir haben gesehen, wie PowerShell 7 Fehlermeldungen verbessert, indem es die benötigten Informationen auf eine strukturiertere Art und Weise bereitstellt. Aber was ist zu tun, wenn man dem Problem genauer auf den Zahn fühlen muss? Bleiben wir beim vorherigen Fehler: The process cannot access the file … because it is being used by another process.
Kein Terror mehr durch den $Error
Jedes Mal, wenn PowerShell auf einen Fehler stößt, wird dieser in die automatische Variable $Error geschrieben. $Error ist ein Array und der letzte Fehler wird mit $Error[0] bezeichnet.Um in früheren Versionen von PowerShell mehr über den letzten Fehler zu erfahren, musste $Error[0] mit Cmdlets wie select-object und format-list untersucht werden. Doch das ist mühsam: Erweiterte Informationen über Eigenschaften können nur einzeln aufgerufen werden, und wichtige Informationen sind durch die Verschachtelung bei der Darstellung mancher Eigenschaften schnell übersehen.Ein Beispiel ist der folgende Befehl:
$Error[0] | Select-Object *
Die Fülle wertvoller Daten unter den Eigenschaften Exception und InvocationInfo ist komplett versteckt. Der nächste Abschnitt zeigt, wie man an diese Informationen gelangt.
Get-Error zur Fehleruntersuchung einsetzen
PowerShell 7 enthält ein neues Cmdlet namens Get-Error, mit dem man alle in einem PowerShell-Fehlerdatensatz enthaltenen Informationen überprüfen kann.
Get-Error wird ohne Argumente ausgeführt und zeigt einfach den letzten Fehler an.
Es wird sofort die Hierarchie der nützlichen Objekte und Eigenschaften angezeigt, die unter dem Fehlersatz verschachtelt sind. So wird offensichtlich, dass die Eigenschaft Exception kein unordentlicher Haufen Informationen ist; sie enthält Untereigenschaften, von denen einige ihrerseits Unterpunkte haben. Soll die Fehlermeldung im Code weiterverwendet werden, zum Beispiel um sie in eine Protokolldatei oder die Ereignisanzeige zu schreiben, kann der Administrator die Meldung mit folgendem Befehl speichern:
$Error[0].Exception.Message
Verwenden von ErrorVariable zum Speichern von Fehlersätzen
Das Cmdlet Get-Error akzeptiert auch Fehlerdatensätze aus der Pipeline. Dies ist besonders praktisch, wenn man den allgemeinen Parameter -ErrorVariable verwendet, um Fehler für eine spätere Prüfung zu speichern:
# +myErrors means "add error to $myErrors variable"
Get-LocalUser | Export-Csv local_users.csv -ErrorVariable +myErrors
# Inspect the errors with Get-Error
$myErrors | Get-Error
Durch die Verwendung von Get-Error wird sichtbar, dass -ErrorVariable etwas andere Informationen enthält als die Variable $Error. Die Fehlermeldung ist an mehreren Stellen einsehbar, aber am einfachsten sind sie in einer Eigenschaft namens Message zu finden, wie im folgenden Bild:
Die neuen Funktionen im Zusammenspiel
Wir haben nun mit Get-Error Fehleraufzeichnungen sowohl aus der Shell-Historie als auch aus -ErrorVariable untersucht und gesehen, wie man auf eine Eigenschaft des Fehlers zugreift. Der letzte Schritt besteht darin, alles miteinander zu verknüpfen, indem wir die Eigenschaft aus dem Skript wiederverwenden. Dieses Beispiel speichert Fehler in $myErrors und gib alle Fehlermeldungen in eine Datei aus:
Get-LocalUser | Export-Csv local_users.csv -ErrorVariable +myErrors
if ($myErrors) {
$myErrors.Message | Out-File errors.log -Append
}
Für diejenigen, die sich ernsthaft mit Skripting und Automatisierung beschäftigen wollen, lohnt es sich, sich mit der PowerShell-Fehlerbehandlung vertraut zu machen, nachdem diese in Version 7 aufgewertet wurde. Besonders hilfreich ist die Funktion, Fehler zur späteren Untersuchung in einer Variable zu speichern oder mit einem Kollegen zu teilen.