PowerShell 7 und Windows PowerShell. Tobias Weltner

dem Quellcode finden Sie dort die aktuellen Installationsmedien. Scrollen Sie dazu die Startseite nach unten, bis Sie Hinweise ähnlich wie die in Abbildung 1.10 sehen.

       Hinweis

      Webseiten ändern sich und werden hin und wieder restrukturiert. Unter https://github.com/PowerShell/PowerShell/releases finden Sie aber in jedem Fall die Liste der veröffentlichten Versionen und Installationsmedien.

       macOS

      Idealerweise würde PowerShell über Apples App Store bereitgestellt. Aktuell ist das indes leider noch nicht der Fall. Die nächsteinfachere Installationsvariante nutzt den Paketmanager homebrew, der dafür zunächst installiert werden muss (https://brew.sh/). Anschließend ist die Installation der PowerShell wie bei allen Paketmanagern trivial:

      brew install --cask powershell

      pwsh

      Um PowerShell von Zeit zu Zeit zu aktualisieren, schreiben Sie:

      brew update

      brew upgrade powershell --cask

      Weitere Informationen finden Sie hier: https://docs.microsoft.com/en-us/powershell/scripting/install/installing-powershell-core-on-macos.

      Abbildung 1.10: PowerShell steht für viele Betriebssysteme zur Verfügung.

       Kompatibilität der PowerShell

      Lassen Sie uns an dieser Stelle gleich die zwangsläufigen Fragen zur Kompatibilität von Power-Shell-Code stellen, die natürlich entstehen, wenn PowerShell auf so vielen unterschiedlichen Plattformen ausführbar ist. Also wie kompatibel ist PowerShell eigentlich?

       Kann ich ein PowerShell-Skript auf Linux entwickeln und auf Windows ausführen (oder umgekehrt)?

       Kann ich Skripte, die ursprünglich für Windows PowerShell konzipiert wurden, unverändert in der neuen PowerShell einsetzen?

       Kann ich also beispielsweise nahtlos mit all meinem vielleicht schon bestehenden Code im Unternehmen von Windows PowerShell auf PowerShell umsteigen?

       Die Antwort auf alle Fragen lautet wie so häufig: »Kommt drauf an.«

       Abwärtskompatibilität der Sprache

      Die eigentliche PowerShell-Sprache ist wunderbar abwärtskompatibel: Eine höhere Power-Shell-Version unterstützt also immer die Sprachelemente einer niedrigeren PowerShell-Version. Die neue PowerShell (in Version 7.x) unterstützt daher alle Sprachelemente der älteren Windows PowerShell (Version 5.1).

      Lediglich eine spezielle Windows PowerShell-Technik wurde in PowerShell komplett entfernt: Workflows. Dies geschah aber mangels Interesse, denn Workflows hatten sich nie durchgesetzt.

      Prinzipiell sind also alte Skripte in der neuen PowerShell unverändert einsetzbar (sofern sie keine Workflows verwenden).

       Verfügbarkeit von Befehlen

      In der Praxis ist es dann leider doch nicht so einfach, denn das eben Gesagte bezieht sich nur auf »Sprachelemente«. Die PowerShell-Sprache bildet also einen Rahmen, und der ist kompatibel. Die eigentlichen Befehle, die in diesem Rahmen eingesetzt werden, sind es oftmals aber nicht.

      Der PowerShell-Befehlssatz ist nämlich nicht fest vorgegeben und noch nicht einmal Teil der eigentlichen PowerShell, sondern speist sich aus verschiedenen externen Quellen (die im nächsten Kapitel genauer dargelegt werden). Deshalb kann es durchaus sein, dass Befehle in einer anderen PowerShell-Version oder auf einem anderen Betriebssystem nicht zur Verfügung stehen:

       Aufgegebene Befehle: Einige Windows PowerShell-Befehle wurden bei PowerShell endgültig ausgemustert, weil sie entweder veraltet oder Windows-spezifisch waren. Dazu zählen populäre Befehle wie Get-EventLog oder Get-WmiObject, die bei Windows PowerShell sehr häufig eingesetzt wurden. Setzt ein Skript solche Befehle ein, muss es umgeschrieben werden. Für die meisten dieser Befehle gibt es seit PowerShell 3 (bessere) Alternativen (beispielsweise Get-WinEvent und Get-CimInstance).

       Plattformspezifische Befehle: Andere PowerShell-Befehle (zum Beispiel Get-Printer oder Get-NetIpConfiguration) und erst recht Anwendungen (zum Beispiel robocopy.exe) stammen vom Betriebssystem oder installierter Drittsoftware. Wenn ein Skript solche Befehle verwendet, funktioniert es möglicherweise nicht mehr plattformübergreifend.

      Der Ehrlichkeit halber muss gesagt werden, dass all dies meist gar nicht tragisch ist: In der Regel sollen PowerShell-Skripte ganz plattformspezifische Aufgaben automatisieren. Dort, wo die eingesetzten Befehle fehlen, werden sie also typischerweise auch gar nicht benötigt.

      Und soll PowerShell doch einmal plattformübergreifende Aufgaben erfüllen, sind die dazu notwendigen Befehle, beispielsweise für Programmaufrufe, Dateisystem- und Fernzugriffe sowie Remoting, in allen PowerShell-Versionen und -Varianten gleichermaßen vorhanden.

      Man kann sich PowerShell also am besten vorstellen als ein generisches, plattformübergreifendes Basis-Automationsframework, das je nach verwendeter Software und eingesetztem Betriebssystem wie ein individueller Maßanzug um viele spezifische Befehle ergänzt ist.

       Out-GridView

      Ein besonderes Szenario gilt für den überaus populären Befehl Out-GridView, mit dem man Auswahldialoge wie den in Abbildung 1.11 erzeugt. Er funktioniert auch in der neuen PowerShell, aber leider nur in Windows. Code, der Out-GridView einsetzt, ist also nicht mehr auf Linux und macOS lauffähig.

      »Schuld« daran ist das .NET Framework Core, eine Softwarebibliothek, aus der sich Anwendungsentwickler bedienen dürfen und auf der das neue PowerShell aufbaut. .NET Core unterstützt grafische Oberflächen (derzeit) nur auf dem Windows-Betriebssystem. Das hat Auswirkungen auf alle Befehle, die grafische Oberflächen generieren. Zum Glück sind solche Befehle, einmal abgesehen von Out-GridView, extrem selten.

      Um nicht abwarten zu müssen, bis .NET Core vielleicht künftig einmal grafische Oberflächen auf allen Betriebssystemen unterstützt, hat das PowerShell-Team eine textbasierte Alternative zu Out-GridView geschaffen: Out-ConsoleGridView.

      Abbildung 1.11: Ein grafisches Universalauswahlfenster funktioniert nur bei Windows.

      Dieser Befehl ist derzeit noch kein Teil von PowerShell (und wie bei so vielen guten Ideen bleibt abzuwarten, ob er bis zu Ende entwickelt wird). Einstweilen kann man ihn (nur in PowerShell 7, nicht in Windows PowerShell) mit dem folgenden Befehl nachinstallieren:

      PS> Install-Module -Name Microsoft.PowerShell.ConsoleGuiTools -Scope CurrentUser

      Nun kann das außerhalb von Windows fehlende Out-GridView durch die plattformübergreifende Variante Out-ConsoleGridView