PowerShell Core für Windows, Linux und macOS

Universalmuschel

Holger Schwichtenberg

Microsoft bietet sein Kommandozeilen- und Scripting-Werkzeug PowerShell nun auch für andere Betriebssysteme an. Allerdings noch in abgespeckter Form.

Dass die Windows-Kommandozeile cmd kein adäquates Administrationswerkzeug ist, hatte Microsoft schon vor über zehn Jahren eingesehen. 2006 erschien die erste Version der Windows PowerShell, die gegenüber bash & Co. sogar den Vorteil bietet, dass sie in die Pipeline keine Zeichenketten befördert, sondern typisierte .NET-Objekte (Abbildung 1).

Robustes Objekt-Pipelining mit der PowerShell: An welcher Stelle im von Get-Service gelieferten ServiceController-Objekt sich das Attribut Status befindet, ist nicht relevant (Abb. 1).

Die PowerShell ist in der Version 5.1 ein Open-Source-Projekt, das der Softwarekonzern auf github.com unter den Augen der Öffentlichkeit entwickelt. Das neue Produkt hat das „Windows“ im Namen eingebüßt und heißt passend zur Core-Strategie bei .NET nun PowerShell Core 6.0. Basis ist nicht mehr das .NET Framework 4.7 (das weiterhin nur unter Windows läuft), sondern .NET Core 2.0, das es auch für Linux und macOS gibt [1]. Microsoft führt Windows PowerShell nicht mehr weiter und liefert dafür nur noch Fehlerbehebungen [2]. Eine umfangreiche Liste mit Links zum Thema findet man unter ix.de/ix1808064.

Eine berechtigte Frage ist, wozu man PowerShell überhaupt auf Linux und macOS portiert hat, wo es dort doch mit bash, ksh, tcsh, zsh, fish et cetera viele etablierte Shells gibt [3]. Antwort: Microsoft gehört inzwischen zum Vorstand der Linux Foundation und verdient in seiner Cloud Azure mit dem Betrieb von Linux-Servern Geld.

Core 6.0 lässt sich parallel zu früheren PowerShell-Installationen auf einem Windows-Rechner betreiben, denn die ausführbare Datei heißt nicht mehr powershell.exe, sondern nun pwsh.exe. Mit bisherigen Aktualisierungen war ein gleichzeitiger Betrieb nicht möglich.

Ausgabe der Versionstabelle und der Anzahl der Befehle von PowerShell Core 6.0.1 auf Ubuntu-Linux (Abb. 2)

Linux-Anwender können die PowerShell aus Repositories installieren, die Microsoft für gängige Distributionen bereitstellt. Zum Start gibt man im Linux-Terminal-Fenster pwsh ein (Abbildung 2). Für die Installation auf macOS bietet Microsoft ein .pkg-File (Apple Software Package) oder alternativ ein Archiv (.gz) an.

Etwas anderes Konsolenverhalten

Das Modul PSReadline für die Eingabeunterstützung wird mitgeliefert. Während Core unter Windows den Eingabemodus Windows verwendet, ist unter macOS und Linux Emacs eingestellt. Die Konsole verhält sich daher etwas anders als bei der alten PowerShell: Während der Benutzer unter Windows nach einer Eingabe von Get-H und dem Drücken der Tabulatortaste den Vorschlag für das erste passende Commandlet (Get-Help) und bei jedem weiteren Drücken der Tabulatortaste für die folgenden Commandlets (Get-History und Get-Host) erhält, bekommt er unter macOS und Linux eine Liste der passenden Commandlets nach dem ersten Drücken der Tabulatortaste. Erst wenn die Eingabe eindeutig ist, wird vervollständigt. Ebenso funktioniert die Eingabeunterstützung für andere Konstrukte, etwa Parameter. Unter Linux und macOS kann man die aus Windows bekannte Eingabeunterstützung aktivieren mit

Set-PSReadlineOption -EditMode Windows

Gemeinsamkeiten und Unterschiede

Genau wie in der klassischen Windows PowerShell spielt die Groß- und Kleinschreibung der Namen für Commandlets, Funktionen und Variablen in PowerShell Core keine Rolle, das heißt, Get-Process und get-process bedeuten das Gleiche. Betriebssystemspezifische Namen, etwa Umgebungsvariablen, sind unter Linux und macOS gleichwohl case-sensitive.

Wenn in einer Umgebungsvariablen wie PATH oder PSModulePath mehrere Verzeichnisse vorkommen, sind sie unter Windows mit einem Semikolon getrennt, unter Linux und macOS aber mit einem Doppelpunkt. Die Commandlets liefern bei den Letzteren Instanzen von .NET-Klassen; Get-Process beispielsweise Instanzen der Klasse System.Diagnostics.Process. Wie die Windows PowerShell greift auch Core auf die PATH-Variable zurück, um systemeigene Befehle zu suchen, wenn ein eingegebener Befehl kein Commandlet ist.

Unter Windows ist ps ein Alias für Get-Process und übergibt Instanzen der .NET-Klasse System.Diagnostics.Process. Unter Linux und macOS ist ps ein eingebauter bash-Befehl für die Prozessliste, der auch unter Core eine Zeichenkette (System.String) liefert. Gleiches gilt für ls, cat, man et cetera.

Dir und cd sind in Core Aliase für die Commandlets Get-ChildItemv beziehungsweise Set-Location. Anders als in Linux-Shells akzeptiert Core nicht nur unter Windows, sondern auch unter Linux beide Schrägstricharten in Pfaden, zum Beispiel dir c:/users/hs und dir c:\users\hs. Dies führt allerdings dazu, dass PowerShell Dateien mit einem Backslash im Namen nicht verarbeiten kann.

Skriptdateien sollten wie in Windows auf .ps1 enden, damit Core sie direkt ausführen kann. Explizite Ausführungsrechte wie bei bash-Skripten muss man nicht vergeben.

Eine Skriptausführungsrichtlinieneinstellung wie unter PowerShell gibt es nicht unter Linux und macOS. Get-ExecutionPolicy liefert unrestricted. Set-ExecutionPolicy scheitert mit „Operation ist not supported on this platform“.

Powershell und bash: unterschiedlicher Start von Skripten

Aus der bash heraus startet man ein PowerShell-Skript mit pwsh ./name.ps1. Aus der PowerShell heraus muss man bash voranstellen: bash ./name.sh. PowerShell fasst den Begriff eines Laufwerks weiter als die Betriebssysteme. Während unter Windows zahlreiche Informationsspeicher als PowerShell-Laufwerke aufgefasst werden (darunter auch das Active Directory sowie die Registrierungs- und SQL-Server-Datenbanken), bieten Linux und macOS nur das Dateisystem (/) und Umgebungsvariablen sowie die PowerShell-Konstrukte Variablen, Funktionen und Aliase.

Unix-Dateisysteme kennen keine Dateiattribute und daher kann man dort auch Parameter wie -Attributes bei Get-ChildItem und den Zugriff auf die Attributes-Eigenschaft von Dateisystemobjekten nicht einsetzen. Unter Linux und macOS versteckt man Dateien und Ordner, indem der Name mit einem Punkt beginnt. Wie unter Windows nimmt man versteckte Dateien und Ordner mit dem Parameter -force bei Get-ChildItem (alias dir) in die Ausgabemenge auf.

Weitere wichtige Hinweise zum Einsatz unter Linux und macOS zeigt der Kasten „Gemeinsamkeiten und Unterschiede“.

Core 6.0 bietet weniger Funktionen als der Vorgänger. Zudem ist die Linux- und die macOS-Version gegenüber der Windows-Ausführung funktional abermals reduziert. Erst kommende Versionen sollen wieder den gewohnten Umfang bieten. Einige der bisher verfügbaren Kern-Commandlets gibt es noch nicht unter Core. Dazu gehören:

– alte Commandlets für die Windows Management Instrumentation (WMI), Version 1;

– der Start von Workflows (es gibt die Basistechnik Windows Workflow Foundation nicht in .NET Core);

– das Verwalten lokaler Benutzer und Gruppen;

– der Zugriff auf Leistungsindikatoren;

– das Verwenden von Snap-ins, es gibt in Core nur noch Module;

– alle Commandlets für die Ereignisprotokolle;

– das Nutzen der Zwischenablage;

– Unterstützung für Transaktionen.

Das Fehlen der genannten Funktionen rührt insbesondere daher, dass das aktuelle .NET Core die für Commandlets benötigten Basisklassen nicht kennt. Erst mit dem Windows Compatibility Pack, das zusammen mit .NET Core 2.1 Mitte des Jahres 2018 erscheinen soll, will Microsoft einige der fehlenden Funktionen nachrüsten. Unter Linux und macOS fehlen alle Commandlets

– für Dienste, etwa Start-Service;

– für die Computerverwaltung;

– für das Common Information Model (CIM, alias WMI v2);

– für das Nutzen von COM-Objekten mit dem Parameter –com im Commandlet New-Object;

– für File-Catalog;