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:

Abbildung 1: Vor der Veröffentlichung von PowerShell 7 wurden bei Tippfehlern in Befehlen solche Fehlermeldungen angezeigt.
Abbildung 1: Vor der Veröffentlichung von PowerShell 7 wurden bei Tippfehlern in Befehlen solche Fehlermeldungen angezeigt.

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.

Abbildung 2: Die neue ConciseView-Option reduziert das Durcheinander und hebt den Ort des Fehlers mit einer anderen Farbe hervor.
Abbildung 2: Die neue ConciseView-Option reduziert das Durcheinander und hebt den Ort des Fehlers mit einer anderen Farbe hervor.

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.

Abbildung 3: Die Standardfehlermeldung in Windows PowerShell 5.1 bietet eine Menge Informationen, aber nicht in einer nützlichen Darstellung.
Abbildung 3: Die Standardfehlermeldung in Windows PowerShell 5.1 bietet eine Menge Informationen, aber nicht in einer nützlichen Darstellung.

Im Gegensatz dazu bietet die PowerShell-Fehlerbehandlung in der neuesten Version des Automatisierungs-Tools aufgrund der ConciseView-Option eine viel prägnantere Meldung.

Abbildung 4: Die Option ConciseView bietet eine einfachere Fehlermeldung, wenn ein Problem mit einem Befehl auftritt.
Abbildung 4: Die Option ConciseView bietet eine einfachere Fehlermeldung, wenn ein Problem mit einem Befehl auftritt.

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 *

Abbildung 5: Die automatische Variable $Error in älteren PowerShell-Versionen speicherte Fehler, war aber nicht flexibel genug, um einen tieferen Einblick in die betroffenen Eigenschaften zu geben.
Abbildung 5: Die automatische Variable $Error in älteren PowerShell-Versionen speicherte Fehler, war aber nicht flexibel genug, um einen tieferen Einblick in die betroffenen Eigenschaften zu geben.

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.

Abbildung 6: Die Verwendung des Parameters ErrorVariable bietet eine flexiblere Möglichkeit, Fehler zu protokollieren, als die Verwendung der Variable $Error, die jeden Fehler in einer Sitzung speichert.
Abbildung 6: Die Verwendung des Parameters ErrorVariable bietet eine flexiblere Möglichkeit, Fehler zu protokollieren, als die Verwendung der Variable $Error, die jeden Fehler in einer Sitzung speichert.

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:

Abbildung 7: Die Verwendung des Parameters -ErrorVariable bietet eine flexiblere Möglichkeit, Fehler zu protokollieren, als die Variable $Error, die jeden Fehler in einer Sitzung speichert.
Abbildung 7: Die Verwendung des Parameters -ErrorVariable bietet eine flexiblere Möglichkeit, Fehler zu protokollieren, als die Variable $Error, die jeden Fehler in einer Sitzung speichert.

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.

Nächste Schritte

Wie sich SQL-Server über PowerShell steuern lassen

Drei wichtige PowerShell-Tutorials für Administratoren

Sicherheit bei der Automatisierung mit Rule Engines

Erfahren Sie mehr über Server- und Desktop-Virtualisierung