PowerShell 7.0 freigegeben: Eine Shell für (fast) alle und (fast) alles

Mit PowerShell Core 6.0 hatte Microsoft den plattformneutralen Neustart gewagt. Die Version 7.0 soll nun Windows PowerShell 5.1 fast ebenbürtig sein.

In Pocket speichern vorlesen Druckansicht 246 Kommentare lesen
PowerShell 7.0 rückt näher ran

(Bild: Artur Szczybylo/Shutterstock.com)

Lesezeit: 8 Min.
Von
  • Dr. Holger Schwichtenberg
Inhaltsverzeichnis

Die Windows PowerShell 7.0 ist für Windows (ab Windows 7 und Windows Server 2008 R2), Linux (diverse Distributionen) und macOS (ab Version 10.12) erschienen. Der Fokus liegt dabei auf der Annäherung an die Funktionen von Windows PowerShell 5.1.

Seit 2006 hat Microsoft die auf dem .NET Framework basierende Windows PowerShell mit ihrem objektorientierten Pipelining als Alternative zu klassischen Shells mit zeichenkettenbasierten Pipelining etabliert. Im Januar 2018 erfolgt dann aber ein Neustart: Die PowerShell Core 6.0 basierte auf .NET Core und lief nicht nur auf Windows, sondern auch auf Linux und macOS. Insbesondere aufgrund Einschränkungen in den verfügbaren Basisklassen von .NET Core war die Core-Ausgabe aber weit weniger mächtig als die letzte Version 5.1 der Windows PowerShell.

PowerShell 7.0 wurde als-Open Source-Projekt auf GitHub entwickelt. Dabei hat Microsoft viele Beiträge von Entwicklern außerhalb dereigenen Firma erhalten. Die Azure Cloud Shell in Microsofts Cloud-Portal wurde bereits auf PowerShell 7.0 umgestellt.

Mittlerweile hat .NET Core viele Klassen aus dem klassisches .NET Framework übernommen. Für die nun erschienene PowerShell 7.0 (bewusst ohne Core im Namen) verwendet Microsoft als Basis das aktuelle .NET Core 3.1.1. Damit ist der funktionale Unterschied zwischen Windows PowerShell 6.1 und PowerShell 7.0 deutlich reduziert. Viele Commandlets, die in PowerShell Core 6.x fehlten, zum Beispiel für die Zwischenablage, die Druckerausgabe und grafische Ausgaben, sind nun in PowerShell 7.0 zurückgekehrt.

Ganz verschwunden ist der funktionale Unterschied zwischen Windows PowerShell 5.1 und PowerShell 7.0 allerdings nicht. Ein Schnelltest des Autors ergab folgendes Bild auf der aktuellen Vorschauversion von Windows 10 20H1:

Anzahl der Befehle in Windows PowerShell 5.1 1586
Neue Befehle in PowerShell 7.0 + 16
Entfallene Befehle in PowerShell 7.0 - 95
Anzahl der Befehle in PowerShell 7.0 1507

Zu den weiterhin fehlenden Funktionen in PowerShell 7.0 gehören insbesondere:

  • WMI-Commandlets der ersten Generation (WMI v1) wie Get-WmiObject und Invoke-WmiMethod. Die WMI-v2-Commandlets wie Get-CimInstance und Invoke-CimMethod werden aber unterstützt.
  • Beitritt zu Windows-Domänen mit Add-Computer
  • Start von Workflows in PowerShell (es gibt die Basistechnik, Windows Workflow Foundation, nicht in .NET Core)
  • Verwendung von PowerShell-Snap-Ins (Add-PSSnapin, Remove-PSSnapin). Es gibt seit PowerShell Core 6.0 nur noch Module.
  • Zugriff auf das Windows-Ereignisprotokoll (Get-EventLog, Write-EventLog u.a.)
  • Unterstützung für Transaktionen (Get-Transaction, Complete-Transaction, Undo-Transaction u.a.)
  • Commandlets für den Dienst Microsoft User Experience Virtualization (UE-V)

Bereits in PowerShell Core 6.x gab es Befehle, die Plattformneutralität durchbrachen und nur auf Windows verfügbar waren (z.B. zur Dienstverwaltung, Benutzerverwaltung und Dateiberechtigungsvergabe). In PowerShell 7.0 hat sich diese Liste noch um solche Befehle erweitert, die grafische Ausgaben erzeugen (z.B. Out-GridView und Show-Command). Diese Befehle basieren auf der Windows Presentation Foundation (WPF), die es in .NET Core seit Version 3.0 zwar in der .NET Core Windows Desktop Runtime gibt, aber nicht für Linux und macOS implementiert ist. Auch die in PowerShell 7.0 wieder eingeführten Befehle Out-Printer, Get-HotFix und Clear-RecycleBin funktionieren nur auf Windows.

Die starke Annäherung des Befehlsumfangs von PowerShell 7.0 an die Windows PowerShell 5.1 basiert vor allem darauf, dass die meisten der in Windows mitgelieferten PowerShell-Erweiterungsmodule nun auch unter PowerShell 7.0 lauffähig sind. Die Windows-spezifischen Modulverzeichnisse C:\Program Files\WindowsPowerShell\Modules und C:\Windows\system32\WindowsPowerShell\v1.0\Modules gehören daher in PowerShell 7.0 zum Standardsuchpfad für Module. Nicht zu PowerShell 7.0 kompatible Module erkennt man seit Windows 10 1809 und Windows Server 2019 daran, dass diese in der Eigenschaft "CompatiblePSEditions" keinen "Core"-Eintrag besitzen.

Eigenschaft CompatiblePSEditions bei einem zu PowerShell 7 kompatiblen und einem nicht kompatiblen PowerShell-Modul

Wenn man versucht, diese nicht kompatiblen Module mit Import-Modulen in PowerShell 7.0 zu laden, kommt es bei einigen zu einer Fehlermeldung, bei anderen erscheint aber nur eine Warnung. Diese besagt, dass PowerShell 7 eine Remoting-Verbindung zu einer Instanz der Windows PowerShell aufbaut und dort die Befehle ausführt. Dieses Verfahren nennt Microsoft "WinPSCompatSession" und basiert auf dem Modul "WindowsCompatibility"; dies gibt es natürlich nur unter Windows, nicht auf Linux und macOS, denn dort gibt es keine Windows PowerShell.

Unter Linux und macOS fehlen alle PowerShell-Module, die nicht zum Kern der PowerShell, sondern zu Windows gehören. So findet man unter Linux und macOS lediglich 270 Befehle statt der 1507 Befehle auf Windows 10.

Die Anzahl der neuen Funktionen in PowerShell 7.0 gegenüber der Windows PowerShell 5.1 ist überschaubar. Eine größere Verbesserung ist die Einführung der Pipeline-Verkettungsoperatoren && und ||, die aus klassischen Shells bekannt sind. Bisher konnte man in der PowerShell einzelne Befehle mit dem Pipe-Symbol | zu einer Pipeline verbinden. Nun kann der Nutzer ganze Pipelines verbinden, wobei die Pipeline nach && im Erfolgsfall und die Pipeline im Fehlerfall ausgeführt wird.

Aus der Programmiersprache C# hat Microsoft den Null Assignment Operator ??, den Null Coalescing Operator ??= und den Null Conditional Operator ?. in die PowerShell-Skriptsprache übernommen. Der letztgenannte Operator gilt aber als ein experimentelles Feature, dass Nutzer erst aktivieren müssen (siehe Get-ExperimentalFeature und Enable-ExperimentalFeature). Schleifen kann man nun mit ForEach-Object -Parallel in mehrere Threads ausführen.

Bei Fehlern bietet die PowerShell 7 nun eine deutlich detaillierte und übersichtlichere Ausgabe (Concise View). Eine Liste der letzten Fehler in der neuen Form erhält man mit Get-Error. Die eingebaute Variable $error funktioniert aber weiterhin. Auch die Ausgabe der Commandlets Format-Hex und Select-String hat Microsoft verbessert. Bei Select-String werden nun die Fundstellen in der Ausgabe hervorgehoben. Bei der Eingabe unterstützt die PowerShell 7.0 den Nutzer nun auch mit Vorschlägen bei Variableninhalten, wenn die der PowerShell die möglichen Werte bekannten sind (z.B. bei Enumerationen oder per Annotation [ValidateSet]).

Mehr Infos

Das kommt in PowerShell 7

Darüber hinaus gibt es viele kleinere Verbesserungen, wie den neuen Parameter -count, mit dem Nutzer beim Commandlet Get-Random angeben kann, dass er nicht nur eine, sondern mehrere Zufallszahlen bekommen möchte. Der Befehl Get-Member liefert bei COM-Objekten nicht nur den Datentyp, sondern auch den Namen der Parameter von Methoden. Dies hilft erheblich zum Verständnis, wie man die Methode aufrufen muss.

Mit PowerShell 7.0 gleicht Microsoft den Support an die Unterstützung der zugrunde liegenden .NET-Core-Version an. Das bedeutet, dass PowerShell 7.0 wie .NET Core 3.1 bis zum 3. Dezember 2022 unterstützt wird. Genaueres erfährt man über die vollständige Liste aller von PowerShell 7.0 unterstützten Betriebssystemversionen. Die Unterstützung für die Version 6.0 und 6.1 ist bereits beendet. Version 6.2 will Microsoft noch sechs Monate lang warten.

Nach aktuellem Stand wird die PowerShell 7.0 mit keinem Betriebssystem im Standard ausgeliefert. Nutzer können die PowerShell 7.0 von der Release-Seite auf GitHub beziehen. In Windows will Microsoft dauerhaft die Windows PowerShell 5.1 ausliefern. Möglich ist, dass PowerShell 7.0 oder ein Nachfolger irgendwann als zweite Option hinzukommt. Die moderne PowerShell und die klassische Windows PowerShell können auf einem System koexistieren, da sie unterschiedliche Anwendungsnamen besitzen (powershell.exe vs. pwsh.exe).

Weitere Informationen findet man in der Blog-Ankündigung. Die nächste Version die Nummer 7.1 tragen. Eine Roadmap dafür steht noch aus. (ane)