PowerShell

Unter Windows gibt es neben .bat (seltener auch .cmd) -Dateien und dem Windows und Windows Script Host seit 2006 die PowerShell.

PowerShell Fenster
PowerShell Eingabe

Historie

Die Idee beim Scripting unter UNIX ist, dass Konfigurationsdateien Text enthalten und alle Programme Text ausgeben. Zum Bearbeiten dieses Textes hängt man Tools wie head, tail, grep, sed, … sowie das nächste Kommando mittels „|“ aneinander. Das bedeutet aber, dass jede Eingabe erst mal syntaktisch analysiert (parsed) werden muss und die Ausgabe muss in einem Kompromiss zwischen menschen- und maschinenlesbarem Text formatiert werden.

Unter DOS war Skripting mit .bat-files nur sehr eingeschränkt möglich, und die Eingabeaufforderung unter Windows hat daran wenig geändert.

Pipes

PowerShell „Cmdlets“ kann man, wie die „Tools“ unter *IX, mit „|“ aneinanderhängen. Der erste wichtige Unterschied ist aber, dass nicht Text, sondern Objekte übergeben werden. Wenn trotzdem lesabarer Text auf dem Bildschirm erscheint, liegt das daran, dass die PowerShell an das letzte Cmdlet einer Kette implizit eine Textkonvertierung anghängt. Man kann die natürlich auch selber anhängen, wenn man auf die Formatierung Einfluss nehmen will. Ein Cmdlet hat typischerweise drei Methoden: „Begin“, „Process“ und „End“. Die mittlere wird einmal pro Objekt aufgerufen, das über die Pipe übergeben wird und die anderen beiden nur einmal. Vereinfachte Cmdlets können aber auch aus nur einer einzigen Funktion bestehen.

Installation

Seit Windows 7 ist serienmäßig PowerShell installiert, und es wird sogar eine einfache Entwicklungsumgebung, die „ISE“ („Integrated Scripting Environment“) mitgeliefert.

PowerShell ISE
Windows PowerShell Integrated Scripting Environement

Für ältere Windows Versionen ab Windows XP kann man die PowerShell downloaden. Allerdings muss man dann auch gleich .NET mit downloaden.

Cmdlets

PowerShell Cmdlets haben ein sehr systematisches Namensschema: „Verb-Nomen“. Wenn man nicht weiß, wie ein Kommando heißt, kann man mit „Get-Command“ danach suchen und als Parameter „-Verb“ oder „-Noun“ angeben. Beispiel:

PS C:\> Get-Command -Noun Csv
CommandType     Name                 ModuleName
-----------     ----                 ----------
Cmdlet          ConvertFrom-Csv      Microsoft.PowerShell.Utility
Cmdlet          ConvertTo-Csv        Microsoft.PowerShell.Utility
Cmdlet          Export-Csv           Microsoft.PowerShell.Utility
Cmdlet          Import-Csv           Microsoft.PowerShell.Utility

Code Completion mit Tab funktionieren natürlich auch.

Wenn man das passende Cmdlet gefunden hat, bekommt man mit „Get-Help“ Hilfe. Das funktioniert auch bei selbstgeschriebenem Code, wenn man spezielle Kommentare hinzugefügt hat, siehe about_comment_based_help. Der Mechanismus erinnert entfernt an Javadoc oder phpDocumentor. Cmdlets kann man entweder in PowerShell oder in einer .NET-Sprache, also z. B. C# oder VB schreiben.

Voreinstellungen

Im Auslieferungszustand weigert sich die PowerShell Script-Dateien auszuführen. Mit dem Kommando „Set-ExecutionPolicy“ kann man das ändern. Gängig ist die Einstellung „RemoteSigned“ (lokal erstellte Scripts dürfen ausgeführt werden, downgeloadete nur, wenn sie digital signiert sind).

Die Environmentvariable $PROFILE zeigt auf eine Script, das beim Start der PowerShell ausgeführt wird, genau wie .profile unter UNIX.

$ENV:PSModulePath zeigt der PowerShell, wo sie nach Modulen suchen soll, die z. B. Cmdlets enthalten. In diesem Pfad ist üblicherweise u. a. %UserProfile%\Documents\WindowsPowerShell\Modules enthalten. Da kann man also eigene Erweiterungen unterbringen.

Bewertung

Einige Geräte, mit denen ich beruflich zu tun habe, haben auch eine „Kommandozeile“, und da nervt es schon, dass es beim einen Hersteller „config Show“ und beim anderen „Show config“ (oder war’s „showcfg“?) heißt. Die Regel, dass bei PowerShell alles „Verb-Nomen“ heißt, ist sicher nicht nobelpreisverdächtig, aber sie würde bei herstellerübergreifenden Arbeiten helfen, obwohl die Reihenfolge in der PowerShell ärgerlicherweise genau umgekehrt ist wie in objektorientierten Sprachen, wo es „Objekt.Methode()“, also Nomen.Verb heißt. Nebenbei bekämen diese Geräte eine Scriptsprache, mit der man auch deren Administration automatisieren kann. So muss ich auf irgendeinem anderen Rechner ein Script laufen lassen und Kommandos mit „ssh“ übermitteln, was die Fehlerbehandlung nicht gerade vereinfacht.

Links

PowerShell Scriptomatic a utility to create WMI scripts using Windows PowerShell.

4 Antworten auf „PowerShell“

Kommentar verfassen