ps | grep 'sshd' | awk '{print $1}' | xargs kill
Vier Befehle. Jeder für sich dumm, zusammen brillant. Das ist die Unix-Philosophie. Es ist ein Orchester aus kleinen, scharfen Werkzeugen, die Text verarbeiten. Es ist schnell, es ist universell, es ist elegant.
Und dann kam Microsoft.
In Redmond blickte man auf dieses elegante System und sagte: “Text? Wie primitiv! Text ist unstrukturiert! Das muss doch… besser gehen. Wir brauchen… Objekte!”
Und so gebar man PowerShell.
Der Wahn der Objekt-Pipeline
PowerShell ist das, was passiert, wenn ein Komitee aus Enterprise-Architekten versucht, bash neu zu erfinden, aber nur VBScript im Kopf hat.
- Unix-Shell: “Hier ist eine Zeile Text. Mach was draus.”
- PowerShell: “Hier ist ein 35MB großes .NET-Laufzeit-Objekt-Handle vom Typ
System.Diagnostics.Process. Bitte wähle die Property.NamemittelsSelect-Object, filtere es mitWhere-Object {$_.Name -like 'sshd'}, und dann pipe es anStop-Process. Hoffentlich. Wenn die .NET-Version stimmt.”
Wo wir grep und awk haben, zwingt uns PowerShell, in Verb-Substantiv-Schablonen (Get-Process, Set-ItemProperty, Invoke-WebRequest) zu denken. Es ist keine Shell, es ist eine sprechende API-Dokumentation.
Die “Lesbarkeit” (Ein Trugschluss)
“Aber es ist so lesbar!”, rufen die Verfechter.
Ja, Get-ChildItem -Path C:\ -Recurse -Filter *.log | Select-String -Pattern 'ERROR' ist vielleicht für einen Windows-Admin lesbarer als find / -name "*.log" -exec grep "ERROR" {} +.
Aber was passiert, wenn es komplex wird?
Die Unix-Shell gibt dir sed, awk, perl – Werkzeuge von chirurgischer Präzision, um Text zu zerlegen.
PowerShell gibt dir noch mehr .NET-Methodenaufrufe. Man tippt nicht mehr, man programmiert. Man versucht, sich zu erinnern, ob es .Length oder .Count war, oder ob man [System.Text.Encoding]::UTF8 übergeben muss.
Das “Eine-Shell-für-Alles”-Problem
Das Schlimmste ist nicht die Syntax. Es ist die Hybris. Die Unix-Shell weiß, dass sie dumm ist. Sie verlässt sich auf externe Programme.
PowerShell glaubt, sie sei das Betriebssystem. Sie will alles sein: Shell, Skriptsprache, Konfigurationsmanager (DSC) und Paketmanager (PowerShellGet). Sie ist der systemd-Ansatz für die Kommandozeile: ein Monolith, der alles halb gut macht und beim Starten einen Kaffee trinken geht.
Man muss ja fast dankbar sein für den Schmerz, den uns PowerShell zugefügt hat. Er hat eine neue Generation von Shells inspiriert, die sich gefragt hat: “Geht das auch ohne den .NET-Overhead und die Syntax eines 90er-Jahre-Visual-Basic-Kurses?”
Hier kommt NuShell ins Spiel.
NuShell ist der rebellische Teenager, der sich angeschaut hat, was Mama (Unix/Text) und Papa (PowerShell/Objekte) gemacht haben, und beschlossen hat: “Ich kann das besser.”
Es ist der Versuch, das Gute an PowerShell zu nehmen – nämlich die Idee strukturierter Daten – und sie mit der Eleganz und Interaktivität einer modernen Shell zu kreuzen.
Was NuShell richtig macht (und PowerShell nie verstanden hat):
Strukturierte Daten, aber leichtgewichtig: Wo PowerShell dir schwere .NET-Objekte um die Ohren wirft, gibt dir NuShell einfache Listen und Tabellen. Es parst
ls(oderps) automatisch in eine Tabelle, die du sofort filtern, sortieren und abfragen kannst.Beispiel gefällig? Statt
ps aux | grep 'sshd' | awk '{print $2}'machst du in NuShellps | where name =~ 'sshd' | get pid. Das ist die Lesbarkeit von PowerShell, aber ohne das Gefühl, man würde ein Enterprise-Framework booten.Keine zwei Welten: In der Unix-Shell kämpfst du mit
awkundsedgegen Text-Streams. In PowerShell kämpfst du mit Objekt-Properties. NuShell versucht, alles in seine Pipeline zu integrieren. Es kann JSON, YAML, TOML und sogar CSVs nativ verstehen und als Tabellen behandeln. Es ist eine Shell für das API-Zeitalter.Es ist nicht Windows: Es ist in Rust geschrieben. Es ist schnell. Es fühlt sich nicht an, als würde man bei jedem Befehl eine halbe DLL-Bibliothek laden.
Fazit
Die Unix-Philosophie hat uns gezeigt, wie man aus Einfachheit komplexe Systeme baut.
PowerShell hat uns gezeigt, wie man ein einfaches Problem (Text verarbeiten) nimmt und es in ein komplexes, speicherhungriges, objektorientiertes Framework-Problem verwandelt, für das man eine eigene IDE (VS Code mit PowerShell-Extension) braucht.
Es ist der ultimative Management-Trick: Es sieht aus wie eine moderne Lösung, aber im Kern ist es nur ein weiterer Versuch, uns von einfachen, mächtigen Werkzeugen wegzudrängen und uns in ein proprietäres (ja, auch wenn es “Open Source” ist) Ökosystem zu sperren.
Kommentare