PowerShell-Scripts auf Best Practices prüfen mit dem ScriptAnalyzer


    Tags: ,

    Powershell-LogoDie Entwickler des Open-Source-Projekts PSScriptAnalyzer haben die Version 1.17.1 ihres Code-Checkers für Power­Shell ver­öffentlicht. Das Tool prüft Script-Code auf Basis von vor­definierten Regeln, die sich an den Best Practices orientieren. Neu ist die auto­matische Korrektur von bestimmten Abwei­chungen.

    Erste Versionen des Code-Checkers ließen sich über ein Add-on namens Script Browser in die PowerShell_ISE integrieren. Unter PowerShell 5.x funktioniert dies aber nicht mehr, und das Plug-in wurde aus der PS-Gallery entfernt. Dafür ist der Analyzer nun über die PowerShell-Extension von Visual Studio Code (VSCode) und als eigen­ständiges Modul verfügbar.

    Installation über Package-Management von PowerShell

    Wenn man PowerShell-Scripts nicht in VSCode, sondern wie wohl die meisten Admins in der ISE entwickelt, dann kann man den Code-Checker von der Kommando­zeile aus starten. Dazu muss man das Modul aber erst von der PSGallery installieren:

    Install-Module -Name PSScriptAnalyzer

    Wie der Befehl

    Get-Command -Module PSScriptAnalyzer

    anschließend zeigt, stellt das Modul drei Cmdlets zur Verfügung:

    • Get-ScriptAnalyzerRule
    • Invoke-ScriptAnalyzer
    • Invoke-Formatter

    Regeln anzeigen

    Das erste davon dient dazu, die verfügbaren Regeln anzuzeigen, anhand derer der Code von Scripts geprüft wird. Ruft man es ohne Parameter auf, dann zeigt es alle der aktuell 55 Standard­regeln inklusive Beschreibung.

    Ein nützlicher Parameter ist Severity, der die Liste anhand der Werte Error und Warning auf schwer­wiegende oder weniger gravierende Probleme einschränken kann:

    Get-ScriptAnalyzerRule -Severity Error

    Dieses Kommando würde nur Regeln zeigen, wo ein Verstoß als Fehler eingestuft würde.

    Die Übersicht über das Regel­werk braucht man dann, wenn man nachher bei der Überprüfung nur bestimmte Empfehlungen berück­sichtigen oder andere gezielt ausschließen möchte.

    Anzeigen der Standardregeln für ScriptAnalyzer mit Hilfe von Get-ScriptAnalyzerRule.

    In der neuen Version sind mehrere Regeln dazugekommen:

    • AvoidAssignmentToAutomaticVariable: Damit soll verhindert werden, dass Entwickler Werte an automatische Variablen wie $_ zuweisen.
    • PossibleIncorrectUsageOfRedirectionOperator: Sie ist vor allem für Entwickler gedacht, die häufig andere Programmier­sprachen nutzen, wo als Vergleichs­operatoren für größer bzw. kleiner ein > bzw. < dient. PowerShell verwendet hier bekanntlich -gt bzw. -lt. Die Zeichen > und < sind dagegen der Umleitung vorbehalten.
    • PossibleIncorrectUsageOfAssignmentOperator: Prüft auf den möglicher­weise falschen Einsatz des Zuweisungs­operators. Das könnte etwa passieren, wenn Basic-Entwickler einen Ausdruck auf Gleichheit prüfen.
    • AvoidTrailingWhiteSpace: Die Regel warnt vor Leerzeichen am Ende einer Code-Zeile. Sie könnten bei Zeilenumbrüchen innerhalb einer Anweisung zum Problem werden.

    Code überprüfen

    Die eigentliche Prüfung von Code erfolgt mit Hilfe von Invoke-ScriptAnalyzer. In den meisten Fällen übergibt man dem Cmdlet den Namen einer Script-Datei, die geprüft werden soll:

    Invoke-ScriptAnalyzer -Path .\MyPSScript.ps1

    Mit Hilfe der Paramter IncludeRules und ExcludeRules können bestimmte Regeln explizit ein- oder ausge­schlossen werden. Gibt man hier mehrere an, dann trennt man sie durch ein Komma. Bloße Warnungen könnte man beispielsweise übergehen, indem man den Parameter Severity mit dem Wert Error versieht.

    In diesem Beispiel warnt ScriptAnalyzer vor dem Einsatz eines Alias in einem Script.

    Neu in der Version 1.17.1 ist die Option Fix, die bestimmte Abweichungen von den genutzten Regeln automatisch korrigieren kann. Das gilt etwa für die Verwendung von Aliases für Cmdlets. In einigen Fällen müssen die Autoren von Scripts solche Korrekturen manuell nach­bearbeiten, etwa bei der Konvertierung von Klartext in einen Secure String.

    Möchte man nur ein Code-Fragment und nicht eine ganze Script-Datei überprüfen, dann verwendet man statt Path den Parameter ScriptDefinition und übergibt ihm den Code als Wert. In diesem Fall steht der Schalter Fix aus naheliegenden Gründen nicht zur Verfügung.

    Scripts formatieren

    Schließlich gehört als drittes Cmdlet noch Invoke-Formatter zum Liefer­umfang des Moduls. Wie der Name erwarten lässt, können Script-Autoren damit die Formatierung des Codes aufräumen. Zur Auswahl stehen mehrere Konven­tionen, die sich über den Parameter Settings via Auto­vervoll­ständigung auswählen lassen.

    Formatierungsoptionen von Invoke-Formatter

    Es akzeptiert PowerShell-Code nur über den Parameter ScriptDefinition, so dass man unter Umständen den Inhalt einer Script-Datei über Get-Content einlesen muss, bevor man ihn an den Formatierer übergibt:

    Invoke-Formatter -Settings CodeFormatting `
    -ScriptDefinition (Get-Content -Raw -Encoding UTF8 .\myScript.ps1)

    Eine ausführliche Dokumentation des Moduls findet sich auf Github.

    Täglich Know-how für IT-Pros mit unserem Newsletter

    Wir ver­wenden Ihre Mail-Adresse nur für den Ver­sand der News­letter.
    Es erfolgt keine per­sonen­be­zogene Auswertung.

    Bild von Wolfgang Sommergut
    Wolfgang Sommergut hat lang­jährige Erfahrung als Fach­autor, Berater und Kon­ferenz­sprecher zu ver­schie­denen Themen der IT. Da­ne­ben war er als System­ad­mi­ni­stra­tor und Con­sultant tätig.
    // Kontakt: E-Mail, XING, LinkedIn //

    Verwandte Beiträge

    Weitere Links