Heading

Wie bei jeder Programmiersprache unterstützt PowerShell Kommentare. Genau genommen unterstützt sie zwei Arten von Kommentaren. Wie Sie jedoch später in diesem Artikel sehen werden, kann PowerShell Kommentare auf einige interessante und unerwartete Arten verwenden, die sehr leistungsfähig sein können.

Verwenden von Kommentaren

Der häufigste Stil von Kommentaren, den Sie sehen werden, ist eine Zeile mit einem vorangestellten #-Symbol. (Ich überlasse es Ihnen zu entscheiden, ob Sie das einen Hashtag, ein Pfund-Symbol oder sogar eine gute alte Acht nennen wollen!)

Als Beispiel könnten Sie einen Kommentarblock am Anfang Ihres Programms mit Details dazu haben:

Kommentare wie diese können überall in Ihrem Code stehen. Eine alternative Möglichkeit wäre allerdings eher das, was ich als C-Sprachstil bezeichnen würde oder manchmal auch als Blockkommentar bezeichnet wird:

Mit diesem Stil können Sie einfacher Kommentarzeilen hinzufügen, ohne dass vor jeder Zeile ein # steht. Es steht Ihnen frei, einen der beiden Stile oder sogar beide zu verwenden. Denken Sie aber an die Nützlichkeit von Kommentarblöcken wie diesem, wenn Sie in einem Jahr wiederkommen, um Ihren eigenen Code zu debuggen. Kommentare müssen aber auch nicht am Anfang einer Zeile stehen. Tatsächlich verwende ich persönlich Kommentarblöcke wie oben nur am Anfang eines Skripts oder direkt vor einem besonders komplizierten Codeblock. Ich verwende viel eher Endzeilenkommentare wie z.B.:

Ich habe diesen Kommentar in ein aktuelles Skript eingefügt, weil das | Out-Null nicht etwas war, von dem ich erwartet habe, dass es benötigt wird, und ich weiß, dass ich mich in einem Jahr fragen würde, warum ich es dort hatte, wenn ich den Kommentar nicht hätte. Oder schlimmer noch, ich würde ihn entfernen und mich dann wundern, warum ich eine Abbruchmeldung bekomme, die immer wieder auftaucht.

Beachten Sie, dass wenn Sie einen Kommentar mit einem # beginnen, alles bis zum Ende der Zeile als Kommentar behandelt wird. Dies kann zum Beispiel nützlich sein, wenn Sie testen und das Ende eines Befehls auskommentieren möchten.

Damit können Sie später den Kommentar entfernen und die –online Version der Hilfe erhalten, aber was, wenn Sie einen Kommentar in der Mitte haben wollen? Auch hier gibt Ihnen die PowerShell diese Möglichkeit.

Beachten Sie, dass Sie durch die Verwendung eines Kommentars im Blockstil die Möglichkeit haben, einen Kommentar in der Mitte Ihres Befehls zu haben und trotzdem Elemente rechts davon auszuführen oder zu interpretieren. Schließlich fragen Sie sich vielleicht: „Was ist, wenn ich ein # ausgeben oder etwas Ähnliches tun möchte?“ Wenn Sie versuchen

Sie werden feststellen, dass es nicht ausschreibt, was Sie wollen. Sie erhalten einfach:

Hier kommt der Grab-Akzent ` zum Einsatz.

So wird die gewünschte Meldung ausgedruckt.

Sie könnten auch die gesamte Zeichenkette in Anführungszeichen einschließen:

Das würde funktionieren, aber ich wollte ein Beispiel dafür geben, wie man dem #-Qualifier entkommt.

Wenn Sie, wie ich, oft die PowerShell ISE zum Schreiben von Skripten verwenden, gibt es noch einen letzten nützlichen Trick, den ich mit Ihnen teilen möchte, für den ich aber nur eine Beschreibung und einige Screenshots, aber kein Skript zur Verfügung stellen kann. Es handelt sich um eine Tastenkombination, die nicht kommentarspezifisch ist, aber nützlich ist, wenn Sie einen Codeabschnitt haben, den Sie auskommentieren möchten, z. B. zum Testen. Setzen Sie den Cursor an den Anfang der Zeile und halten Sie Shift-Alt gedrückt, um ihn mit den Pfeiltasten nach oben oder unten zu bewegen. Sie werden feststellen, dass eine dünne Linie (auf meinem Bildschirm blau) erscheint. Wenn Sie die Zeilen markiert haben, die Sie kommentieren möchten, geben Sie einfach ein # ein, und es erscheint am Anfang jeder Zeile.

Das ist ein Beispiel für den zu kommentierenden Code:

Wenn Sie rechts neben den Text in Zeile 40 klicken und nach mehrmaligem Drücken von Shift-Alt und dem Pfeil nach oben, sehen Sie die blaue Linie:

Nach dem Drücken von # <Leerzeichen> sehen Sie die Zeichen, die dem Code hinzugefügt wurden:

Als Anmerkung: Sie können diesen Trick an jeder beliebigen Stelle der Zeile anwenden (wenn Sie also einen Haufen Kommentare am Ende einer Reihe von Zeilen einfügen wollten, könnten Sie diesen Trick verwenden, um das # einfach für Sie einzufügen) und ist natürlich nicht spezifisch für das Kommentieren, aber das ist eine der offensichtlichsten Anwendungen. Sie können dies auch mit regulären Ausdrücken machen. Markieren Sie den fraglichen Code-Block:

Dann drücken Sie Strg-H, um das Dialogfeld Suchen und Ersetzen zu erhalten. Stellen Sie sicher, dass Suchen in Auswahl und Reguläre Ausdrücke ausgewählt sind:

Das Caret ^ wird verwendet, um den Anfang einer Zeile zu verankern und natürlich das # (dort ist ein Leerzeichen) fügt grundsätzlich ein # und ein Leerzeichen am Ende der markierten Zeilen ein. Beachten Sie, wenn Sie einen Codeblock nicht hervorheben, wirkt sich dies auf Ihr gesamtes Skript aus.

Und mehr

Wenn das jedoch alles wäre, was Kommentare in der PowerShell tun können, wäre dies ein sehr kurzer und langweiliger Artikel (und mein Redakteur würde den Kopf schütteln und sagen: „Greg, ich brauche mehr als 850 Wörter!“) Wie bei vielen Dingen in der PowerShell haben die Ersteller Funktionen hinzugefügt, die sie leistungsfähiger machen, als Sie vielleicht erwarten.

Ich bereitete mich kürzlich auf eine Präsentation vor, die ich bei der Hampton Roads SQL Server User Group hielt. Während dieser Präsentation führe ich ein Skript in PowerShell aus, das SQL Server startet und stoppt. Dazu muss ich es als Administrator ausführen. Natürlich hatte ich das während einer Übung völlig vergessen, und als ich es als ich selbst ausführte, kam es zu mehreren hässlichen Fehlern. Das war zwar kein Showstopper, aber nicht das, was man sich bei einer Demo wünscht. Das brachte mich dazu, darüber nachzudenken, wie ich sicherstellen könnte, dass dies während des eigentlichen Vortrags nicht passiert.

Mein erster Gedanke war, ein Cmdlet zu finden, das prüft, als wer ich angemeldet war, und dann abbricht, wenn ich nicht der richtige Benutzer bin. Ein Teil des Problems bei diesem Ansatz ist natürlich, dass man, wenn man ein Programm (z. B. PowerShell ISE) als Administrator ausführt, als der angemeldete Benutzer angezeigt wird. Dies sollte schwieriger werden, als ich dachte.

Wieder einmal hat mich PowerShell überrascht. Das Lösen dieses Problems ist trivial. Um zu sehen, wie das Problem zu lösen ist, öffnen Sie die PowerShell ISE als Sie selbst (d. h. wählen Sie NICHT „Als Administrator ausführen“ und stellen Sie sicher, dass Ihr Benutzer keine lokalen Administratorrechte hat) und geben Sie den folgenden Code ein:

Speichern Sie dies in einer Datei namens restart timer service example.ps1 und versuchen Sie dann, es auszuführen. Sofern Sie kein lokaler Administrator auf Ihrem Rechner sind, sollten Sie einen Fehlerbildschirm ähnlich dem untenstehenden erhalten.

Wenn Sie dies mit der Option „Als Administrator ausführen“ ausführen, sollte es ohne Fehler laufen. In diesem Beispiel ist der Fehler ziemlich harmlos, aber vielleicht schreiben Sie ein Skript, bei dem ein Fehler nicht so harmlos wäre. Um dieses Problem zu lösen, fügen Sie einfach den folgenden Kommentar an den Anfang des obigen Skripts und speichern Sie es erneut.

Nun erhalten Sie einen anderen Fehler:

Es ist immer noch ein bisschen hässlich, aber viel besser, als das Skript auszuführen und vielleicht etwas kaputt zu machen. Beachten Sie, wenn Sie das Skript einfach ausschneiden und in ein neues Fenster einfügen, aber nicht speichern, wird PowerShell versuchen, das Ganze auszuführen. Im Grunde wird das #requires ignoriert, es sei denn, es handelt sich um eine tatsächlich gespeicherte Datei. Dies löste mein anfängliches Problem, aber es brachte mich dazu, andere Funktionen zu untersuchen, die mir nicht bekannt waren. Für #requires gibt es eine ganze Liste:

Wie Sie sehen können, geben Ihnen diese eine Menge Macht bei der Steuerung, wie und wann Ihr Skript ausgeführt wird. Das #Requires –Version ist nützlich, wenn Ihr Skript Funktionen benötigt, die nur in einer neueren Version von PowerShell verfügbar sind. Beachten Sie, dass dies eine Mindestanzahl ist. Die Version von PowerShell, die Sie ausführen, muss mit dieser übereinstimmen oder höher sein. Sie können dies nicht verwenden, um eine frühere Version von PowerShell zu erfordern. Ein nützliches Cmdlet, das ich kürzlich in einem Skript verwendet habe, ist beispielsweise compress-archive. Glücklicherweise war dieses Skript spezifisch für das Problem, das ich zu lösen versuchte, aber wenn ich versuchen würde, ein allgemeineres Skript zu schreiben, würde ich vielleicht #requires –Version 5.0 an das Ende meines Skripts setzen. Zur Demonstration speichern Sie das folgende Skript als benötigte Version example.ps1.

Wenn Sie dies in Ihrer vorhandenen PowerShell ISE-Instanz ausführen, sollte es ohne Probleme ausgeführt werden, aber wenn Sie versuchen, das Skript in einer älteren Version wie PowerShell 2.0, wird das Skript in der Zeile #requires fehlschlagen und den Rest des Skripts nicht ausführen. Dies ist das gewünschte Ergebnis.

Zum Testen könnten Sie auch etwas wie –Version 99.99 einfügen, und Sie erhalten Fehlermeldungen ähnlich den Beispielen unten, aber ich wollte zeigen, wie dies in der realen Welt auf vorhandenen Systemen funktionieren würde, und auch die Fähigkeit der Befehlszeile demonstrieren, auf eine frühere Version von PowerShell zurückzugreifen.

Um dies zu testen, müssen Sie die Kommandozeilenversion der PowerShell verwenden und diese wie folgt starten:

Dann führen Sie die oben gespeicherte Datei aus requires version example.ps1. Sie sollten eine Fehlermeldung wie diese sehen:

Während ich empfehlen würde, den #Requires-Kommentar ganz an den Anfang der Datei zu setzen, können Sie ihn in Wahrheit überall platzieren und es wird sich genauso verhalten. Wenn Sie die obige Datei neu erstellen, aber den Kommentar nach dem Get-Process nach unten verschieben und als Requires-Version speichern Beispiel Version 2.ps1.

Versuchen Sie, es unter Version 2.0 wie oben auszuführen, erhalten Sie eine ähnliche Fehlermeldung und das gesamte Skript wird nicht ausgeführt.

Das bedeutet, dass Sie keinen Teil eines Skripts haben können, der unter einer älteren Version (oder als Nicht-Administrator) laufen kann, und dann einen Teil, der eine bestimmte Version erfordert oder als Administrator laufen muss. Wenn Sie so etwas im Code machen wollen, müssen Sie schlauer werden. Speichern Sie das folgende Skript als Requires version example Version 3.ps1.

Wenn Sie dies unter Version 5 oder höher ausführen, wird die Datei Process.txt erstellt und gepackt. Wenn Sie es unter einer früheren Version ausführen, wie z. B. –Version 2.0 oben, kann das Skript die Datei „Process.txt“ trotzdem erstellen, da Get-Process ein Cmdlet ist, das in Version 2.0 verfügbar ist. Da Compress-Archive nicht verfügbar ist, überspringt das Skript diesen Schritt und gibt eine Fehlermeldung aus. Es liegt an Ihnen, ob Sie Skripts schreiben möchten, die die Version von PowerShell erkennen und sich je nach Version unterschiedlich verhalten, aber in vielen Fällen, wenn Sie das Skript einfach abbrechen möchten, ist der #Requires-Kommentar bei weitem der einfachste Weg, die Dinge zu handhaben.

Zwei letzte Vorbehalte zur Verwendung eines #Requires-Kommentars. Er muss am Anfang der Zeile beginnen; Sie dürfen keine Leerzeichen oder Tabulatoren davor haben. Außerdem können Sie nicht versuchen, ihn zu überlisten und ihn als Teil eines try/catch-Blocks einfügen, um ihn eleganter zu behandeln. Speichern Sie das folgende Skript, um beide Vorbehalte zu veranschaulichen: Benötigt Versionsbeispiel Version 4.ps1.

Beachten Sie, dass es das #requires in Zeile 6 ist, das das Skript abbricht, nicht das in Zeile 1, und dass das try/catch keinen Effekt hatte. #Requires sind global und wirken sich auf das gesamte Skript aus, unabhängig davon, wo sie sich befinden, sofern sie in der Zeile beginnen. Und ja, Sie können mehr als ein #Requires in einem Skript haben. Sie könnten eine bestimmte Version von PowerShell, bestimmte Module und RunAsAdministrator voraussetzen.

Zwei letzte Vorbehalte zum #Requires – RunAsAdministrator-Kommentar. Er wurde in der PowerShell-Version 4.0 eingeführt und funktioniert nicht auf Nicht-Windows-Systemen (ja, denken Sie daran, PowerShell ist jetzt plattformübergreifend!). Speichern Sie das folgende Skript unter dem Namen Requires Administrator.ps1. Sie benötigen eine Linux-Instanz, um dies zu testen, aber vorausgesetzt, Sie haben eine, kann PowerShell mit den hier beschriebenen Methoden auf Linux installiert werden. Kopieren oder speichern Sie nach der Installation das obige Skript auf Ihre Linux-Instanz. Um das Skript auszuführen, können Sie Folgendes eingeben:

Sie sollten sehen

Zuletzt fragen Sie sich vielleicht, ob Sie Kommentare im Blockstil mit dem #Requires verwenden können. Nach meinen begrenzten Tests funktioniert dies nicht. Sie müssen jede Anforderung in eine eigene Zeile mit einem vorangestellten # stellen. Dieses Skript funktioniert:

Dieses Script funktioniert nicht:

Abschluss