Bash und Powershell sind Verwandte, aber wie in jeder großen Familie weisen die Zweige des Stammbaums manchmal sehr unterschiedliche Formen auf.

Seit unserem letzten Blick auf die Kommandozeilen unter Windows und Linux sind einige Jahre ins Land gegangen [1] – es ist an der Zeit, zu schauen, wie sich die beiden Kontrahenten in einem halben Jahrzehnt entwickelt haben. Ein Vergleich der Windows Powershell und der Bash zeigt, wer in Sachen modernes Skripten die Nase vorn hat.

Die Windows Powershell war 2006 unter Windows Vista ein kompletter Neuanfang für Microsofts Kommandozeile (siehe Kasten “Neuanfang”). Die Bash unter Linux dagegen stand seit jeher im Mittelpunkt des Systems (siehe Kasten “Bewährtes”). Kontinuierlich entwickelten die Beteiligten an dem Projekt die Schnittstelle weiter. Es stellt sich dabei die Frage: Ist die Bash gereift und vermag sich mit neuen Ansätzen zu messen, oder trägt sie eher schwer an ihrem Erbe?

Vergleich der Konzepte

Zu den wichtigsten Eigenschaften einer Skriptsprache gehört das Verknüpfen zweier Kommandos. Das setzt voraus, dass ein Kommando die Ausgaben eines anderen erhält, versteht und zur gewünschten Ausgabe aufbereitet. Die Bash nutzt in der Regel reinen Text als Ein- und Ausgabe. So liefert der folgende Aufruf die Größe und den Namen der größten drei Dateien im Verzeichnis /var/log:

$ ls -l /var/log | sed 's/ \+/,/g' | cut -d',' -f 5,9 | sort -g | tail -3
267453,kern.log
443742,kern.log.1
584584,lastlog

Bei der Windows Powershell sind alle Ein- und Ausgaben Objekte. Es wandern also ganze Datenstrukturen von Kommando zu Kommando. Das setzt voraus, dass sich die Objekte an bestimmte Vorgaben halten. Um eine ähnliche Ausgabe wie mit der oben gezeigten Pipe unter Windows zu erhalten, brauchen Sie das Wissen um die Eigenschaften der entsprechenden Objekte:

PS> Get-ChildItem -Directory | Sort-Object -Property Length | Select-Object Length,Name -Last 3
   Length Name
   ------ ----
 597379 Manual.pdf
 5715026 Applications.in.Ruby.pdf
 27318109 AnnualCatalogue_de-EU.pdf

Dass bei der Bash die Ausgaben als Text vorliegen, erleichtert freilich das Anpassen der Optionen zum Verarbeiten des nächsten Programms. Meist läuft es dabei auf Ausprobieren hinaus – das klappt bei der Powershell nur eingeschränkt.

Im Beispiel brauchen Sie die Eigenschaften Length und Name. Intuitiv hätten Sie vielleicht als Eigenschaft für die Dateigröße auf Size getippt, statt auf Length. Um die Eigenschaften eines Objekts also sicher zu kennen, bleibt oft nur der Griff zur Dokumentation.

Dabei gestaltet sich der obige Aufruf aus der Powershell 3.0 schon einfacher als aus den Vorgängerversionen: Anfangs kannte das CmdletGet-ChildItem die Option -Directory noch nicht. Daher galt es, ein zusätzliches Cmdlet zum Ausfiltern von Verzeichnissen – Where-Object {-not $_.PSIsContainer} – in die Pipe einzubauen, denn nur Verzeichnisse haben die Eigenschaft PSIsContainer.

Der Unterschied bei der Ein- und Ausgabe von Daten ist nur einer von vielen zwischen Bash und Powershell, jedoch springt er sofort ins Auge. Grundsätzlich unterscheiden sich die Konzepte der beiden Shells: Die Bash zielt auf Arbeitsteilung ab, die Powershell orientiert sich an den Aufgaben. Das verstärkte sich noch in den Versionen 3.0 und 4.0.

Steile Lernkurve

Die Bash kommt mit knapp 40 internen Funktionen und 100 Hilfsprogrammen zurecht. Die Powershell 4.0 verfügt bereits über 299 eingebaute Cmdlets. In der Version 2.0 (Windows 7) waren es noch 251. Jedes Cmdlet verfügt über Optionen, von denen mit jeder Version der Powershell neue hinzukommen.

So verfügt das Cmdlet Get-Content ab Version 3.0 (Windows 8) nun über die Option -Tail Anzahl, welche die Entwickler augenscheinlich dem Unix-Programm Tail entlehnt haben. Für einen Einstieg in die Neuerungen der Powershell helfen kurze Übersichten von Microsoft [4].

Die Cmdlets erscheinen im Vergleich zu den Builtins der Bash als Miniprogramme. Dies spüren Sie immer dann, wenn die letzte Verwendung eines Cmdlet schon etwas zurückliegt. Dann braucht es meist einen Blick in die Referenz, um die korrekten Parameter und Optionen zu finden. Im Gegenzug erledigen die Cmdlets komplexere Aufgaben in einem Aufruf. Um etwa alle Links in der Webseite linux-user.de auszugeben, genügt ab Powershell 3.0 der Aufruf aus Listing 1.

PS> (Invoke-WebRequest http://www.linux-user.de/).links
innerHTML : <IMG border=0 alt=logoOL.gif src="http://www.linux-user.de/pix/logoOL.gif" width=140 height=62>
innerText :
outerHTML : <A href="/"><IMG border=0 alt=logoOL.gif src="http://www.linux-user.de/pix/logoOL.gif" width=140
            height=62></A>
outerText :
tagName   : A
href      : /

Manchmal erscheint dieses Orientieren an Aufgaben recht einseitig, und es macht einige Aufgaben etwas umständlich. Um ein Passwort zu generieren, genügt es unter der Bash, den Datei-Deskriptor für den Zufallsgenerator auszulesen und ein wenig aufzubereiten (Listing 2).

$  echo $(< /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c10)
Kc-TUGC8cd

Um unter der Powershell 3.0 Ähnliches zu erreichen, besteht eine Möglichkeit darin, eine Systembibliothek aus dem .NET-Framework nachzuladen und ein Modul daraus zu nutzen: Es gibt im AssemblySystem.Web das Modul Security.Membership und dort die Funktion GeneratePassword (Listing 3).

PS> $Assembly = Add-Type -AssemblyName System.Web
PS> [System.Web.Security.Membership]::GeneratePassword(10,3)
lGv%.ua]Wl

Bei der Powershell stellt sich die Frage: Wie kommen Sie an die Information, welche Objekte welche Methoden anbieten, und in welcher der mehreren Tausend Systembibliotheken versteckt sich eine Funktion GeneratePassword? Hinter der Antwort steckt Fleißarbeit: Es erfordert ein Studium der extrem umfangreichen Referenz zum .NET-Framework [5], um dessen Möglichkeiten richtig auszureizen.

Hilfestellung

Um in der Bash herauszufinden, welches Kommando weiterhilft, genügt ein Aufruf von apropos Stichwort. Das listet alle Kommandos auf, in deren Hilfeseiten das Stichwort vorkommt. Will man nur wissen, welche Optionen ein Kommando unterstützt, liefert meist ein Aufruf desselben ohne Parameter eine kurze Übersicht. Und falls Sie den Umgang mit der Bash besser beherrschen möchten, hilft ein Blick in die Bash-Referenz [6].

Bei der Powershell gibt es zwar ein Cmdlet Get-Help, oft hilft das jedoch insbesondere Einsteigern beim Umgang mit komplexen Objekten nicht weiter. Microsoft hat der Powershell daher eine kleine Entwicklungsumgebung mitgegeben, die nebenbei eine interaktive Übersicht über die Befehle enthält. Sie erlaubt es, die Eigenschaften eines Cmdlets zu erforschen und darüber hinaus zu testen, wie man es aktiviert beziehungsweise konfiguriert (Abbildung 1).

Abbildung 1: Die Entwicklungsumgebung Powershell ISE ist Bestandteil der Powershell-Installation.

Das Powershell Integrated Scripting Environment ISE erweist sich als ziemlich nützlich, da es nicht nur den Umgang mit Cmdlets erleichtert, sondern auch einen Debugger enthält. Damit führen Sie Skripte schrittweise aus, was die Fehlersuche erleichtert. Außerdem besteht damit die Möglichkeit, direkt aus der Ferne eine Powershell auf einem anderen Computer zu starten, ähnlich wie mit SSH unter Linux. Damit das klappt, muss auf dem Zielcomputer der Administrator per Enable-PSRemoting -Force den Remote-Zugriff erlauben. Damit startet der WinRM-Dienst, der den Zugang bereitstellt.

Für viele Admins unter Linux stellt sich die Frage einer Entwicklungsumgebung für Skripte gar nicht: Leistungsfähige Editoren wie Vim oder Emacs verfügen über zahlreiche Funktionen, die das Scripting erleichtern, wie etwa Syntax-Highlighting, komplexe Funktionen zum Navigieren in Skripten und eingebaute Makrosprachen. Derartige Editoren zählten bislang unter Windows so nicht zum Standardumfang.

Fazit

Die Beispiele zeigen, wie unterschiedlich die Konzepte der Shells ausfallen. Zwar erleichtern Aliase wie ls, mkdir und ps den Umstieg für Admins von Unix auf Windows, aber ob diese Rechnung aufgeht, darf man getrost bezweifeln.

Die Powershell spielt ihre Stärken beim Administrieren der Server-Anwendungen von Microsoft aus. Die Cmdlets sind so zugeschnitten, dass sie häufige Aufgaben in wenigen Schritten erledigen. Dass anstelle von einfachem Text ganze Objekte zur Kommunikation dienen, ist eher dem darunterliegenden Framework geschuldet als einer Vereinfachung für die Administration.

Die Bash verfolgt einen vollständig anderen Ansatz: Beim Shell-Skripting geht es nicht um das Verwalten von Produkten, sondern um möglichst vielseitige Werkzeuge. Für komplexere Aufgaben stehen spezialisierte Interpreter wie Perl und Ruby bereit. Das System an sich verwalten Sie aber vor allem mit der Bash.