Es gibt Sachen, die gibt es gar nicht: Wer in der IT bereits in den frühen 2000er-Jahren tätig war, wird sich noch gut an Microsofts Anti-Linux-Kampagnen erinnern. Open Source war in Redmond zum damaligen Zeitpunkt ein rotes Tuch, das man zu verteufeln nicht müde wurde. Legendär etwa die Werbung in diversen IT-Fachzeitschriften, Open-Source-Software biete keine Planungssicherheit für Unternehmen, weil sie spontan mutieren könne – bebildert mit einem Elefanten, der plötzlich den Kopf eines Pinguins hatte. Gut in Erinnerung geblieben ist auch die Aussage des damaligen Microsoft-Chefs Steve Ballmer, der Linux als "Krebsgeschwür" betitelte, das zu vernichten sei.

Längst sind diese Zeiten vorbei. Unter Führung von Satya Nadella hat Microsoft nämlich nicht nur GitHub gekauft, eine der größten Marktplätze für Open-Source-Software. Der Hersteller baut für Azure auch eine eigene Linux-Distribution und beteiligt sich aktiv an vielen Open-Source-Projekten. Die Community hat es Microsoft auf ihre Weise gedankt und rund um die PowerShell, die ebenfalls unter der MIT-Lizenz steht und damit freie Software ist, ein ganzes Universum praktischer Open-Source-Erweiterungen errichtet. Sie alle eint, dass sie die PowerShell um verschiedene Features erweitern, die deren Benutzung einfacher oder effizienter machen oder besser an einzelne Use-Cases anpassen, als es ab Werk der Fall ist.

Mehr als 90 Cmdlets und Funktionen

Vielen Nutzern indes ist die Existenz dieser Community sowie ihrer Erweiterungen gar nicht bekannt. Und so viel sei schon verraten: Wer die PowerShell-Extensions der Open-Source-Gemeinde nicht kennt, verpasst einiges. Höchste Zeit also, für Aufklärung zu sorgen. Dieser Artikel stellt im Folgenden einige der unserer Meinung nach besten Erweiterungen vor und zeigt, wie sie zu installieren und zu nutzen sind. Grundlage ist die von mehreren Entwicklern zusammengetragene Liste der PowerShell Community Extensions (Pscx) auf GitHub unter [1].

Bevor es um die einzelnen Erweiterungen geht, soll Pscx selbst aber kurz im Fokus stehen. Anders als manche andere Seite im Netz, die sich ebenfalls mit PowerShell-Erweiterungen befasst, ist Pscx nämlich nicht nur eine Liste. Stattdessen haben seine Autoren Pscx so vorbereitet, dass es selbst in einer laufenden PowerShell-Instanz als Modul zur Erweiterung geladen werden kann.

Das Modul sorgt dann insbesondere für über 90 zusätzliche Cmdlets und Funktionen, also hauptsächlich ausführbare Befehle in der PowerShell, die zum Teil zusätzliche Funktionalität in Form von weiteren Modulen und Funktionen im Hintergrund nachladen. Enthalten sind in der Sammlung vor allem solche Kommandos, die im Alltag praktische Beihilfe zum Beispiel beim Abfragen von Active Directory und Azure leisten, die in der offiziellen PowerShell aber eben fehlen.

Voraussetzungen und Plattformbesonderheiten

Damit das Pscx-Setup leicht von der Hand geht, ist etwas Vorarbeit nötig – und ein paar Warnungen sind auch angebracht. Eine bezieht sich auf die Tatsache, dass nicht sämtliche der Module aus dem Pscx-Paket auf jedem Betriebssystem funktionieren. Denn zum Teil verwenden die Module Bibliotheken aus Windows, und die stehen unter macOS freilich nicht zur Verfügung. Diese Erfahrung macht auch der Autor dieses Artikels, der in der Folge einen Teil in der mittels Homebrew installierten PowerShell unter macOS und einen anderen Teil auf Windows 11 verfasste.

Wer die PowerShell unter Windows nutzt, hat diese Probleme natürlich nicht. Hier sollten alle Komponenten aus Pscx funktionieren. Unter macOS ist hingegen wie beschrieben mit Einschränkungen zu rechnen, und für Linux gilt dasselbe. Zwar war die klassische Kommandozeile unter Windows lange weniger verbreitet als unter Linux, doch hat sich die plattformübergreifende PowerShell in den vergangenen Jahren deutlich weiterentwickelt. Entsprechend sind viele Funktionen heute auch auf UNIX-artigen Systemen stabil nutzbar, selbst wenn einzelne Erweiterungen wie Pscx weiterhin primär auf Windows ausgerichtet sind.

Unter Windows steht die PowerShell obendrein ab Werk zur Verfügung, wenn auch in einer veralteten Version. Hier tut der Benutzer gut daran, vor der Installation von Pscx noch ein Update auf die aktuelle Version 7 der Shell durchzuführen. Wer die Shell unter Linux installieren will, beschafft sich entweder die für die eigene Distribution passenden Pakete oder setzt auf den Betrieb in einem Docker-Container wie im Download-Artikel ab Seite 24 beschrieben. Unter macOS steht die Vorgehensweise mit Homebrew als einfachste Option zur Verfügung.

Nach der Installation einer aktuellen PowerShell-Version kann grundsätzlich auch die Einbindung zusätzlicher Erweiterungen erfolgen. Eine der bekanntesten Sammlungen ist dabei die "PowerShell Community Extensions" (Pscx). Allerdings sollten Anwender beachten, dass dieses Projekt seit einiger Zeit nur noch eingeschränkt gepflegt wird und in mehreren, teils veralteten Versionsständen vorliegt.

So gilt die Version 3.3.2 zwar formal weiterhin als "stabil", stammt jedoch bereits aus dem Jahr 2018. Auch die zuletzt veröffentlichte Vorabversion 4.0.0-beta4 aus dem Jahr 2020 ist mittlerweile deutlich in die Jahre gekommen. Vor dem Hintergrund der kontinuierlichen Weiterentwicklung der PowerShell sind viele Funktionen von Pscx heute entweder direkt Bestandteil der Shell oder werden durch spezialisierte, aktiv gepflegte Module aus der PowerShell Gallery ergänzt.

Pscx bleibt dennoch eine interessante Sammlung von Werkzeugen und liefert insbesondere einen guten Überblick darüber, wie die Community die PowerShell über die Jahre erweitert hat. In der Praxis kann es sich daher lohnen, einzelne Funktionen gezielt einzusetzen oder als Ausgangspunkt für weiterführende Lösungen zu nutzen.

Pscx installieren und einrichten

Install-Module Pscx -Scope CurrentUser -AllowClobber als Befehl in der PowerShell selbst aufgerufen installiert die alte Version, Install-Module -Name Pscx -AllowPrerelease -AllowClobber spielt die Version 4.0.0-beta4 auf. Fragt der Installer nach, ob er das Paket wirklich installieren soll, empfiehlt sich ein Druck auf "A", um die Module und etwaige Abhängigkeiten im System zu verankern.

Dabei nicht ganz optimal: Weil Pscx ein großes Verzeichnis ist, enthält es wie bereits erwähnt durch die Bank alle Module ohne Abstufung nach Betriebssystemen. Praktischer wäre es, das allgemeine Pscx enthielte nur jene Module, die auf allen unterstützten Betriebssystemen auch wirklich lauffähig sind. Obendrein existiert keine Liste, die einen Überblick über universelle Module und Windows-spezifische Module vermittelt. Hier können Sie nur ausprobieren und so herausfinden, ob ein Modul funktioniert oder nicht.

Der Parameter "-AllowClobber" sorgt übrigens dafür, dass das Modul installiert wird, obwohl einige der in Pscx enthaltenen Cmdlets inzwischen auch in der offiziellen PowerShell oder in anderen Modulen verfügbar sind. Der Parameter erlaubt es Pscx also, bereits vorhandene Versionen dieser Befehle durch die eigenen Varianten zu überschreiben. Wollen Sie eine bestehende Pscx-Installation aktualisieren, kommt komplementär dazu das Cmdlet "Update-Module Pscx" zum Einsatz. Weitere Befehle zur Installation der Pscx sind danach nicht mehr nötig, denn das Werkzeug erreicht als Komplettpaket den Rechner. Sobald Pscx also aktiviert ist, stehen alle enthaltenen Kommandos darin zur Verfügung.

Und die haben es wie schon beschrieben gerade im Hinblick auf ihren Funktionsumfang in sich. Ergänzend kommt hinzu: Ist Pscx einmal aktiviert, lässt es sich auch aus Skripten für die PowerShell heraus verwenden und nutzen. Obendrein ermöglicht es sogar Automationslösungen wie Ansible, die unter Linux mittlerweile ebenfalls gut funktionieren, durch zusätzliche Funktionen aus Pscx bessere Automatisierung zu erreichen.

Wer nach Pscx und etwaigen Anleitungen die klassischen Suchmaschinen durchforstet, sollte aufpassen. Denn die PowerShell Community Extensions teilen sich den Namen mit einem Emulator für PlayStation-Spiele für Linux. Es schadet also nicht, einer Suche nach "pscx" stets auch ein "PowerShell" beizufügen.

Pscx-Cmdlets praktisch einsetzen

Hat die PowerShell es auf Ihr System geschafft, lassen sich die Cmdlets und Funktionen daraus unmittelbar nutzen. Leider existieren zwar Listen über die verfügbaren Erweiterungen – eine umfangreiche Doku im Netz aber gibt es nicht. Stattdessen stehen unmittelbar auf der Kommandozeile die Hilfstexte der einzelnen Befehle zur Verfügung.

Das ist beispielsweise bei den Werkzeugen aus Pscx zum Erstellen komprimierter Archive gut zu sehen. Wer oft zwischen den Welten unterwegs ist, also etwa Linux- und Windows-Systeme gleichermaßen betreut, kennt das Problem: Gängige Kompressionsformate wie Gzip oder Bzip2 waren unter Windows lange Zeit nicht ohne externe Zusatzprogramme nutzbar – und auch heute unterscheiden sich die verfügbaren Werkzeuge und Workflows je nach Plattform teilweise deutlich. Pscx schafft hier Abhilfe: Es enthält die Cmdlets "Write-GZip", "Write-BZip2" sowie "Write-Tar" und auch "Write-Zip". "Tar" ist streng genommen kein Kompressionsformat, sondern das unter Linux übliche Standardformat, um mehrere Dateien oder Ordner zu einer Datei zu bündeln ("Tarball"). Üblicherweise werden diese Archivdateien anschließend noch komprimiert, sodass Dateien mit den Endungen ".tar.gz" (oder ".tgz") oder ".tar.bz2" entstehen.

Dank Pscx lassen sich diese endlich auch in der PowerShell anlegen. Dabei ist die Verwendung der Cmdlets durchaus gewöhnungsbedürftig, zumindest wenn der Nutzer aus der Linux- oder macOS-Welt kommt. Denn alle genannten Cmdlets erwarten die Eingabe der zu verpackenden Dateien als unmittelbare Ausgabe eines anderen Programms über die Standardausgabe und Standardeingabe. Es muss also die Pipe zur Anwendung kommen, die die Ausgabe eines Werkzeugs an ein anderes umleitet und für dieses als Eingabe nutzt. Das sieht dann beispielsweise so aus:

dir c:\logs\ -rec -inc *.log | write-tar -output logs.tar | write-gzip -level 9 | move-item c:\archived_logs\

Das genannte Kommando durchsucht zunächst den Ordner "logs" auf Laufwerk C: samt aller Unterordner nach Dateien, deren Endung ".log" ist, und gibt eine entsprechende Liste aus. Die erscheint aber nicht auf dem Bildschirm, sondern fungiert unmittelbar als Eingabe für das write-tar-Cmdlet. Das erstellt eine Datei "logs.tar", schreibt sie aber nicht ins Dateisystem, sondern gibt sie unmittelbar als Eingabe an "write-gzip" weiter. Per Gzip komprimiert das Cmdlet den zuvor erstellten Tarball dann mit der höchstmöglichen Stufe der Kompression ("-level 9") und übergibt die fertige Datei schließlich an das Cmdlet "move-item". Dieses verfrachtet das angelegte Archiv in den Ordner "archived_logs" auf Laufwerk C.

Die Cmdlets für BZip2 und Zip funktionieren ganz ähnlich. Das Kommando

dir c:\logs\ -rec -inc *.log | write-bzip2 -level 9 | move-item c:\archived_logs\

wäre syntaktisch also korrekt und würde funktionieren. Aber Vorsicht: Es zeigt auch, dass der Umweg über die Erstellung einer tar-Datei nicht zwingend nötig ist. Die zweite Variante des Cmdlets erstellt stattdessen von jeder gefundenen Datei in "C:\logs" eine BZip2-komprimierte Version und verschiebt sie dann nach "C:\archived_logs". Hier haben Sie letztlich also nicht eine etwas größere Datei im BZip2-Format, sondern viele kleinere.

Text- und Quellcode-Dateien automatisiert bearbeiten

So unscheinbar die genannten Cmdlets für das Erstellen von Archiven auch sind, so praktisch sind sie im Alltag und so sehr erleichtern sie die Arbeit. Wer die einzelnen Module aus Pscx durchforstet und anfängt, sie regelmäßig zu nutzen, merkt schnell: Hier haben sich Entwickler wirklich Gedanken gemacht, und ganz allgemein erhöht Pscx die Freude an der alltäglichen Kommandozeilenarbeit ungemein.

Hauptverantwortlich dafür sind auch Cmdlets wie "Edit-File", das ganz unscheinbar daherkommt, in Wirklichkeit aber mächtiger ist, als es der Admin vermuten würde. Zunächst tut es nichts anderes als ganz banal ein Fenster des auf Systemebene festgelegten Standard-Texteditors zu öffnen. Das ist bei allen Windows-Versionen ab Werk freilich Notepad. Möchten Sie dieses Verhalten ändern, bearbeiten Sie Ihr PowerShell-Profil direkt mit Edit-File: Der Befehl Edit-File $profile öffnet das Profil, und mit

$Pscx:Preferences['TextEditor'] = '"C:\Program Files\Notepad++\notepad++.exe"'

legen Sie beispielsweise Notepad++ als Standardeditor fest.

Edit-File kann aber noch viel mehr als das. Wer von Linux her "sed" kennt, weiß: Dabei handelt es sich um einen interaktiven Editor, der in Dateien zum Beispiel Ersetzungen vornehmen kann. Auf denselben Spuren wandert Edit-File. Soll etwa in einer Quelltextdatei eines Programms flächendeckend eine Versionsnummer durch eine neue ersetzt werden, geht das mittels Edit-File src/main.c -Pattern v4\.0 -Replacement v4.5.1, wenn sich die zu bearbeitende Quelltextdatei im Unterordner "src" des Verzeichnisses befindet, in dem Sie gerade auf der PowerShell sind. Wer gleich sämtliche Quelltextdateien eines Programmes verändern möchte, braucht die Hilfe des Get-ChildItem-Cmdlets, das der PowerShell ab Werk beiliegt:

Get-ChildItem main/*.c -Recurse | Edit-File -Pattern v4.0 -Replacement v4.5.1 -Force -SimpleMatch

Das Kommando ändert die Zeichenfolge "v4.0" in allen Dateien, deren Endungen ".c" sind, im Unterordner "src" zu "v4.5.1". Der Parameter "-SimpleMatch" legt dabei fest, dass die zu ersetzende Zeichenfolge nicht in Form eines regulären Ausdrucks (regular expression) anzugeben ist, wie es beim Beispiel zuvor der Fall war. Weil der Parameter dort fehlt, war der Punkt in "-Pattern v4\.0" dort durch ein Backslash zu markieren ("quoting"). Dass Edit-File durchaus mächtig ist, zeigt dann auch ein umfassenderes Beispiel, das vollen Gebrauch von regulären Ausdrücken macht:

$pattern = '(?s)(<PostBuildEvent>).*?(</PostBuildEvent>)'

Get-ChildItem doc/*.xml -Recurse | Edit-File -Pattern $pattern -Replacement '$1$2' -SingleString

Das Beispiel editiert alle HTML-Dateien im Ordner "doc" interaktiv und automatisch und löscht dabei alle Buchstaben, die zwischen den zwei Elementen "<PostBuildEvent>" und "</PostBuildEvent>" vorkommen. Praktisch im Alltag ist obendrein vermutlich der Parameter "-Encoding", der den zu nutzenden Zeichensatz festlegt. Wer es mit älteren Dateien im ASCII-Format zu tun hat oder Programme verwendet, die nur ASCII-Eingabe anstelle von UTF-8 akzeptieren, rettet sich beispielsweise mittels des Parameters "-Encoding ascii".

Maßeinheiten mit PowerShell umrechnen

Das metrische System ist bekanntermaßen eine recht praktische Erfindung, oder zumindest denken das nach Lage der Dinge die meisten Menschen auf diesem Planeten. Damit die wissen, worum es geht, wenn Maßangaben statt in Zentimetern und Metern in Adlerschwingen oder Hamburgerbrötchen angegeben sind, bietet die PowerShell, wenn mit Pscx erweitert, das Cmdlet "ConvertTo-Metric" an. Es konvertiert nicht-metrische Maßeinheiten in ihre metrischen Pendants.

Wer beispielsweise wissen möchte, wie groß eine Person nach hiesigen Standards ist, deren Größe wie jene von Tom Hanks "6 ft" lautet, kommt mittels ConvertTo-Metric 6 ft schnell ans Ziel und weiß nun, dass Tom Hanks 1,83 Meter misst.

Etwas komplizierter gestalten sich die Dinge bei Julia Roberts, die ihre Größe mit 5' 8'' angibt, also 5 Fuß und 8 Zoll. ConvertTo-Metric 5 ft und ConvertTo-Metric 8 in helfen aber aus der Patsche: 5 amerikanische Fuß sind 152,4 Zentimeter und 8 amerikanische Zoll sind 20,32 Zentimeter. In Summe erreicht Julia Roberts also eine Größe von knapp einem Meter und 73 Zentimetern, wie sich durch einen Blick auf ihre Wikipedia-Seite schnell bestätigen lässt.

Im Alltag der Systemadministration werden Sie freilich weniger auf die Maßangaben irgendwelcher Promis schielen als viel mehr Umrechnungen vornehmen, die einen Bezug zur Arbeit haben. Wer beispielsweise ein neues Display kaufen will und ad hoc nicht mehr in Erinnerung hat, welche Diagonale das aktuelle 23-Zoll-Display bietet, findet das mit ConvertTo-Metric auf der PowerShell ebenso schnell heraus.

Zeilenendungen zwischen Windows und Linux konvertieren

Aus Sicht passionierter Administratoren, die sowohl Windows- als auch Linux-Systeme verwalten, ist eines der größten Ärgernisse der Unterschied der Standardtextformate zwischen den Welten. Das fällt in Linux etwa dadurch auf, dass Sie eine von Windows her importierte txt-Datei aufmachen und lauter Steuerzeichen sehen. Das untrüglichste Anzeichen dafür sind die Zeichen "^M" am Ende jeder Zeile. Mit denen können Vi & Co. unter Linux nichts anfangen, Notepad auf Windows hingegen schon.

Pscx enthält mehrere Cmdlets, mit denen sich Dateien vom einen Format auf ein anderes umstellen lassen. Die Kommandos "ConvertTo-UnixLineEnding" und "ConvertTo-WindowsLineEnding" sind dabei durchaus mächtig. Denn sie verändern nicht nur die Zeilenendungen in den Dateien, die sie per Parameter als Pfad übergeben bekommen. Sie bieten über den Parameter "-Encoding" stattdessen auch die Möglichkeiten, die Kodierung der Datei, also ihren genutzten Zeichensatz, anzupassen. Und der ist die eigentliche Ursache für den Buchstabensalat. Das Handling der Cmdlets ist dabei denkbar einfach, denn es ist nur der Pfad der zu verändernden Datei als Argument mit anzugeben – fertig.

System- und Umgebungsinformationen abfragen

Quasi eine eigene Unterfamilie der Cmdlets, die zu Pscx gehören, bilden jene Befehle, die dem Admin Details über seine aktuelle Arbeitsumgebung verraten. Hier war eine Motivation offensichtlich, Details in Skripten verfügbar zu machen, die ansonsten nur schwer zu beschaffen wären, für verschiedene Konfigurationsaufgaben aber notwendig sind.

Wer beispielsweise auf einem System unterwegs ist, das zu einer Windows-Domäne gehört, und den für ihn zuständigen DHCP-Server abfragen möchte, tut das mittels "Get-DhcpServer". Wer Details über ein eingehängtes Speicherlaufwerk oder ein optisches Laufwerk abfragen möchte, benutzt dafür die Cmdlets "GetOpticalDriveInfo" und "Get-MountPoint", jeweils gefolgt vom Laufwerksbuchstaben.

Eher anekdotischer Art ist "Get-LoremIpsum", das in beliebiger, per Parameter festzulegender Länge den berühmten Beispieltext der Textsetzer, "Lorem Ipsum ..." (Bild 1), ausgibt, also einen Platzhaltertext. Durchaus praktischerer Natur ist "GetDomainController", denn das verrät Ihnen alle relevanten Details über einen Active Directory Controller, der gerade für einen bestimmten Client zuständig ist.

Große Liebe zum Detail beweisen die Entwickler von Pscx zudem im Hinblick auf symbolische Verlinkungen im Dateisystem. Diese sind unter Linux administrativer Alltag und kommen etwa zum Einsatz, wenn zwei Programme auf dieselbe Datei zugreifen sollen, aber sie an unterschiedlichen Orten suchen. Der POSIX-Standard unterscheidet dabei zwischen "Softlinks" oder auch "symbolischen Links" und "Hardlinks". Ein Symlink ist dabei einfach ein Verweis von einem Ort im Dateisystem auf eine andere Stelle – ein Hardlink zeigt stattdessen auf die Inode im Dateisystem, die den Inhalt der verlinkten Datei enthält. Von praktischer Relevanz sind im Alltag vor allem Softlinks.

Dank Pscx kann die PowerShell beides komfortabel und einfach anlegen: "NewSymlink" und "New-Hardlink" sind zuständig und erwarten als ersten Parameter die Quelldatei sowie als zweiten Parameter das Ziel des Links. Auf Systemen mit NTFS steht außerdem noch das Cmdlet "New-Junction" bereit, das eine Dateisystem-Verbindung zwischen zwei Ordnern auf verschiedenen Partitionen anlegt und dabei im Wesentlichen funktioniert wie ein Hardlink für Verzeichnisse. Umfassender Dateisystemakrobatik steht dank Pscx also nichts mehr im Weg.

PowerShell-Cmdlets analysieren und Fehler beheben

Während der größte Teil der Nutzerschaft Pscx vor allem wegen dessen Cmdlets gut finden dürfte, sollten Administratoren auch die im Paket enthaltenen Funktionen nicht unterschätzen. Denn die erweisen sich etwa als besonders praktisch bei der Ausgabe von Details zu Pscx selbst sowie zu anderen Cmdlets.

Ein Beispiel verdeutlicht das gut: "GetPscxhelp" ist eine Pscx-eigene Funktion, die Hilfstexte für verschiedene Cmdlets der PowerShell enthält und optisch sinnvoll darstellen kann. Obendrein enthält "Get-Pscxhelp" auch den Parameter "-Examples", der für einzelne Cmdlets konkrete Beispiele darstellt. Wer Erfahrung mit Manpages auf Linux-Systemen hat, erkennt Optik und Struktur der angezeigten Hilfen schnell.

Mindestens so praktisch ist die Funktion "Get-Parameter" (Bild 2), die sich auf praktisch jedes PowerShell-Programm anwenden lässt. Sie zeigt sämtliche Parameter sowie deren Eigenschaften an, und zwar für das Cmdlet, das Sie als Parameter an "Get-Parameter" übergeben. Get-Parameter dir also zeigt die Parameter des "dir"-Befehls an, das einfach den Inhalt des aktuellen Arbeitsverzeichnisses auflistet.

Für jene Admins, die sich über zum Teil kryptische Fehlermeldungen in Windows aufregen, haben die Leute hinter Pscx ebenfalls etwas in petto. Oft zeigt Windows bei fehlgeschlagenen Operationen einfach eine kryptische Zahl an, etwa "5". Der ist schon im Terminal selbst lästig, aber noch viel nervtötender, wenn etwaige Fehler aus Skripten heraus entstehen. "Resolve-WindowsError" schafft Abhilfe und zeigt auf Basis der angegebenen Fehlernummer eine aussagekräftige Fehlermeldung an. "Resolve-WindowsError" bekommt als Parameter dabei eine Zahl mit auf den Weg, die sich auf den jeweiligen Eintrag im Fehlerlog von Windows bezieht. "Resolve-WindowsError 5" kann dann beispielsweise "Access is denied" auf der Kommandozeile ausgeben, wenn der Fehler im Fehlerlog mit der Nummer 5 diesen Inhalt hat. De facto handelt es sich bei "Resolve-WindowsError" also um ein interaktives Nachschlagewerkzeug im Fehlerlog.

In dieselbe Kategorie fällt das Cmdlet "Get-FileTail", das dem klassischen "tail" sehr nahekommt, wie Sie es womöglich von Linux kennen. Denn Tail zeigt einfach die angegebene Anzahl von Zeilen am Ende der definierten Datei. Gibt es also eine Datei "foo.log", zeigt "Get-FileTail foo.log -Count 20" die letzten 20 Zeilen am Ende eben dieser Datei an. Hängen Sie zusätzlich noch den Parameter "-Wait" an, bringt "Get-FileTail" auch neue Logzeilen auf den Screen, die erst in die Datei eingefügt worden sind, nachdem "Get-FileTail" bereits gelaufen war. Weil es unter Windows durchaus Dienste gibt, die in Textdateien loggen, statt die Systemvorrichtungen dafür zu verwenden, ist das sehr hilfreich. Gerade Anwendungen kleinerer Hersteller sind dabei oft "quick and dirty" gebaut und nutzen eher lokale Logdateien als das Logging des Systems.

Nicht unter den Tisch fallen soll schließlich die Funktion "Edit-Profile". Die öffnet das Profil der Shell in einer Notepad-Session, die Sie gerade in der PowerShell nutzen. Auch die lässt sich mittels Konfigurationsvorgaben in ihrer Profildatei nämlich in Verhalten und Aussehen steuern. Das Kommando "Edit-Profile" bietet eine Abkürzung, um die entsprechende Datei zu erreichen.

Wollen Sie etwa Oh-My-Posh aktivieren, ist dieser Schritt unumgänglich. Achtung: Der aufgerufene Editor wirft beim ersten Start möglicherweise eine Fehlermeldung, wonach die Profildatei nicht existiert. Das kann vorkommen, denn standardmäßig enthält die PowerShell keine leere Profildatei. Legen Sie dann die Datei im Editor einfach an und speichern Sie sie ab. Spätere Aufrufe sollten die Fehlermeldung dann nicht mehr zeigen.

Fazit: Nützliche PowerShell-Erweiterungen mit Einschränkungen

Die Community-Extensions der PowerShell sind ausgesprochen nützlich und bieten viele Funktionen, die in der PowerShell ab Werk früher fehlten oder heute durch zusätzliche Module ergänzt werden. Dabei geht es um die Veränderung des Dateisystems, das Einholen von Infos etwa rund um die eigene Active-Directory-Session sowie um viele kleine Helferlein, die das Scripting mit der PowerShell erleichtern. Dabei fällt auf, dass die meisten Extensions nicht nur klaglos funktionieren, sondern in Form umfassender Hilfstexte auch ausgezeichnet dokumentiert sind.

Obendrein ist gut zu bemerken, dass für Teile der Pscx passionierte Linux-Admins verantwortlich sein dürften, die aus irgendwelchen Gründen auch Windows-Systeme betreuen oder betreuen müssen. Denn teilweise bauen die Pscx-Cmdlets Befehle in sehr ähnlicher Art und Weise nach, die unter Linux etwa in Form von GNU-Werkzeugen absolute Standardausstattung sind. Ganz unabhängig von der Motivation ihrer Entwickler sind die Pscx-Erweiterungen für Administratoren ein willkommenes Add-on.

Zu hoffen bleibt allerdings, dass die ins Stocken geratene Entwicklung von Pscx wieder etwas mehr Fahrt aufnimmt. Die Version 4.0.0-beta4 funktioniert zwar, aber auch die PowerShell steht ja selbst nicht still. Zum Teil kommt es deshalb zu Kollisionen von Cmdlets zwischen einer aktuelleren PowerShell und den leicht angestaubten Pscx-Archiven. Die Funktionalität aber beeinflussen diese Dopplungen zum Glück nicht negativ. (ln)

Über den Autor: Martin Loschwitz  ist Gründer und Geschäftsführer der True West IT Services GmbH. Nebenberuflich schreibt er als freier Journalist zu Themen wie Cloud Computing, Virtualisierung und Container.