Weg von der Maus, hin zur Kommandozeile

Windows und die Kommandozeile – ein Überblick für Entwickler
Kommentare

Windows ist eine feine Sache; alles, was erledigt werden muss, kann mithilfe der Maus getan werden. So war es jedenfalls einmal – gewissermaßen war das die Idee der grafischen Benutzeroberfläche in ihren Anfangszeiten. Gerade für Entwickler hat sich seit dieser Zeit allerdings viel verändert, sodass heute oft die Kommandozeile für bestimmte Aufgaben bevorzugt wird.

Ich persönlich finde die Kommandozeile gut. Nach den uralten Heimcomputern von Commodore und Sinclair, auf denen ich meine ersten Codezeilen schrieb – diese hatten gewissermaßen natürlich eine Kommandozeile, aber eigentlich war das der eingebaute Basic-Interpreter –, konzentrierte ich mich einige Jahre lang auf den Atari ST, wo mit GEM alles besser sein sollte. Im Vergleich zum gelegentlichen Erlebnis mit CP/M schien mir das auch so zu sein. Dann wurde ich irgendwann 15 und alle sprachen von DOS, und dort wurde ich erstmals mit der gruseligen Kommandozeilenumgebung der damaligen Microsoft-Welt konfrontiert. Natürlich gab es gute Gründe, warum DOS in der PC-Welt Dominanz erreichte, aber die Kommandozeile zählte sicherlich nicht dazu!

Nachdem ich ein paar Jahre später den Weg zu OS/2 fand und von dort aus zu IBM AIX, SunOS, Solaris, BSD und Linux, fand ich heraus, wie leistungsfähig eine gute Kommandozeilenumgebung sein kann. Die wunderbare Shell ksh gab es leider nicht überall, aber schon in den frühen 90er Jahren wurde die Entwicklung von bash aktiv vorangetrieben. Irgendwann entdeckte ich dann zsh, bis heute meine bevorzugte Umgebung.

Ich finde es selbst beängstigend, dass ich nun seit 25 Jahren mit einer gleichbleibenden Umgebung arbeite, wenn Kommandos gefragt sind. Solche Lebenszeiten von Konzepten ist man im IT-Umfeld nicht gewohnt – gar nicht zu reden von spezifischen Implementationen! Das Grundkonzept von Unix bildet auch die Grundlage effektiver Arbeit in einer Shell: Einfache Programme mit klar definierten Verantwortlichkeiten sind die Bausteine, aus denen große Resultate zusammengesetzt werden.

Windows wollte anders

Diese Idee war in Windows nicht von Beginn an akzeptiert. Dort gab und gibt es viele relativ monolithische Prozesse, die unterschiedliche Systemaufgaben wahrnehmen. Manche dieser Programme verfügen eventuell über einige Kommandozeilenparameter, aber im Wesentlichen sind das Windows-Applikationen mit grafischer Bedienoberfläche, oder eventuell Dienste, die auf die richtige proprietäre Weise im System integriert werden müssen.

Ausnahmen gab es seit Windows NT im Ressource Kit, wo dem geplagten Systemadministrator einige Werkzeuge in Kommandozeilenversionen zur Verfügung gestellt wurden. Offenbar erkannte Microsoft zu dieser Zeit, dass Routineaufgaben oft einfacher mit Kommandos zu erledigen sind. Es mangelte allerdings noch immer sehr an den Möglichkeiten, mithilfe dieser Kommandos Automatisierung zu betreiben; die alten DOS-Batch-Dateien waren sehr eingeschränkt, und die Shell selbst bot wenige (und schlecht funktionierende) Möglichkeiten, mithilfe von Pipes oder Ein-/Ausgabeumleitung Kommandos miteinander zu verbinden.

Schließlich stellte Microsoft Ende 2006 Windows PowerShell vor. Damit sollte dem fortgeschrittenen Windows-Benutzer endlich eine leistungsfähige Kommandozeilenumgebung an die Hand gegeben werden, und PowerShell wurde tatsächlich schnell zum Standardwerkzeug für System- und Netzwerkadministratoren in der Windows-Welt.

Ein grundsätzliches Problem gibt es allerdings für PowerShell-Benutzer: Die Arbeit mit der Shell gleicht dem Umgang mit einer Programmierumgebung, da dort im Kern mit .NET-Klassen gearbeitet wird. Die Shell leistet gute Arbeit, ein Unix-ähnliches Konzept umzusetzen, indem sie den Zusammenbau kleiner Elemente zu komplexen Kommandos oder Skripten ermöglicht. Die besagten kleinen Elemente sind allerdings nicht etwa allgemein verwendbare Systemkommandos, die zuvor schon existierten und dem Anwender vertraut sind, sondern .NET-Klassen und darauf basierende „cmdlets“. Offensichtlich erschließt sich dieser Ansatz einem Nicht-Programmierer nicht leicht, und besonders in den Anfangszeiten von PowerShell gab es relativ wenige cmdlets, die den Umgang mit dem zugrundeliegenden .NET vereinfachten.

Bash oft einfacher

Während dieser Anfangszeit beschäftigte ich mich selbst einige Zeit mit PowerShell, stellte allerdings schnell fest, dass sich die Automatisierungsaufgaben, mit denen ich zu tun hatte, damit schlecht umsetzen ließen. Zum Beispiel wollte ich ein Skript schreiben, das Dateien aus einem SVN-Repository in ein Zip-Archiv packen sollte, nachdem zuvor ein Filter einige unerwünschte Elemente aus der Verzeichnishierarchie ausschloss. Als Bash-Skript waren das in aller Komplexität nur acht Zeilen Code – beim (abgebrochenen) Versuch einer PowerShell-Umsetzung stellte sich schnell der Eindruck ein, dass ich ebenso gut ein Kommandozeilenprogramm in C# schreiben könnte.

Natürlich hängt die Effektivität der PowerShell vom Einsatzfall ab. Windows-Administratoren haben es oft mit relativ komplexen Daten- und Konfigurationsstrukturen zu tun. Microsoft vereinfachte viele Aufgaben dadurch, dass den Komponenten einer Windows-Server-Installation PowerShell-Bibliotheken beigelegt wurden, mit deren Hilfe sich die Administration dieser Komponenten automatisieren ließ. Für solche Aufgaben ist PowerShell ein sehr wertvolles Werkzeug! Ich finde es trotzdem bedauerlich, dass dieser Schritt nicht auf der Basis von Systemkommandos in Kombination mit einer Unix-ähnlichen Shell gemacht wurde. Letztlich ist PowerShell ein Anachronismus aus der Zeit, in der Microsoft vorübergehend .NET als Ersatz für Betriebssystems-APIs betrachten wollte.

Anderswo fand zur selben Zeit eine andere Revolution statt: die Erfindung von Ruby on Rails. Bereits 2007 wurde dieses neue Framework mit Mac OS X ausgeliefert, und viele Webentwickler auch in der Microsoft-Welt fanden begeistert heraus, wie einfach der Umgang mit den Werkzeugen von Rails war. Plötzlich fand die Entwicklungsarbeit zu einem guten Teil an der Kommandozeile statt, und dieser Ansatz hat sich seitdem mit vielen anderen Werkzeugen, Umgebungen und Plattformen weiter verbreitet. Node und npm, Yeoman und Git, und seit .NET Core auch wesentliche Elemente der Entwicklungswelt von Microsoft, zwingen Entwickler dazu, an der Kommandozeile zu arbeiten. Und nun gibt es gar eine integrierte Linux-Umgebung mit bash in Windows 10; alles im Zeichen der Entwicklereffizienz!

Geliebte Konsole

Meiner Beobachtung nach teilen sich Entwickler auf der Windows-Plattform in Hinsicht auf die wachsende Bedeutung der Kommandozeile in zwei Hauptgruppen auf. Die Ansicht der ersten Gruppe lässt sich so zusammenfassen: „Ich verwende Windows, weil ich Linux & Co nicht mag und Mausbedienung an der grafischen Oberfläche gut finde – ich hasse jeden Moment, den ich an der Kommandozeile verbringen muss und halte ständig nach Alternativen Ausschau.“

Dem gegenüber hat die zweite Gruppe etwa folgende Meinung: „Ich bin froh, dass Entwicklung auch in Windows an der Kommandozeile betrieben werden kann, und ich freue mich, dass heute mächtige Hilfsmittel schneller zu mir gelangen, Updates einfacher sind und die Austauschbarkeit mit anderen Plattformen zu einem greifbaren Ziel wird.“ Interessant finde ich, dass beide Gruppen eines gemeinsam haben: Kenntnisse zum Umgang mit der Kommandozeile sind dünn gesät, die Vorteile werden nur zufällig beim Einsatz von Copy-&-Paste-Beispielen von Stack Overflow genutzt, und die Motivation, die neue Umgebung im Detail kennenzulernen, ist gering.

Falls Sie sich von meinen letzten Sätzen ausgeschlossen oder gar persönlich angegriffen fühlen, dürfen Sie sich gern einer dritten Gruppe zugehörig fühlen, in der Entwickler entweder bereits umfassende Kenntnisse der Kommandozeilenumgebung mitbringen oder eifrig daran arbeiten, diese zu erlangen – diese Gruppe ist allerdings meiner Ansicht nach bisher bedenklich klein!

Innere Werte

Ich wünschte, mehr Entwickler wüssten den Wert der Kommandozeilenumgebungen zu schätzen, die sie in ihrer täglichen Arbeit mehr und mehr verwenden. Letztlich ist die Verfügbarkeit solcher Umgebungen – besonders bash/Linux unter Windows – der Tatsache zu verdanken, dass sich nach vielen Jahren der gedankliche Ansatz aus Unix soweit durchgesetzt und bewiesen hat, dass selbst Microsoft sich genötigt sieht, diesem Weg zu folgen.

Natürlich sollte auch festgestellt werden, dass der Unix-Ansatz von neuer Relevanz ist, besonders im Windows-Umfeld der komplexen Konfigurationsstrukturen und proprietären Binärprotokolle. Entwickler haben schon immer viel mit Textdateien zu tun gehabt, denn darin steht schließlich unser Code. Aber im Umfeld des Codes finden sich Trends, immer weiter Richtung Text zu gehen, und gleichzeitig Richtung Einfachheit – so haben wir vielfach die Idee XML hinter uns gelassen, insbesondere die komplexeren Teile davon, wie XSLT oder XSD. In einer technischen Welt, die immer weiter zusammenwächst, muss Kommunikation einfach sein, und es stellt sich heraus, dass dies auch mit einfachen Protokollen und Formaten erreicht werden kann. Dadurch verlieren die Vorteile, die PowerShell unter Windows für sich behaupten konnte, an Bedeutung. Je einfacher Formate und APIs sind, desto besser stehen sie in Einklang mit der Unix-Idee.

Im Detail ist ein gewisses Zögern unter Entwicklern sicherlich verständlich, denn oft versuchen Anhänger etwa von Linux, ihren nicht so eingestellten Bekannten das System auf fragwürdigem Weg schmackhaft zu machen. Die Vorschläge, die dann gern gemacht werden, sind oft auf Anhieb nicht leicht verständlich, oder einfach wenig gehaltvoll. Zum Beispiel fand ich ein Kommando ähnlich dem Folgenden auf einer Webseite, die „tolle Sachen, die man mit Linux machen kann“, auflistet. Das Kommando gibt auf eher umständlichem Weg eine Liste der Dateien im Verzeichnis /etc aus, sortiert nach der Dateigröße, und reduziert lediglich auf diese Größe sowie den Dateinamen:

/bin/ls -al --sort=size /etc | tr -s ' ' | cut -d ' ' -f 5,9

Ich habe zwar in meinem Leben zahllose solche Kommandozeilen geschrieben, aber ich sehe ein, dass ich damit allein niemanden von der Nützlichkeit der Kommandozeile überzeugen kann. Nun möchte ich aber den Begriff etwas ausdehnen: Es geht schließlich um das gesamte Umfeld einer Unix-artigen Umgebung, nicht nur um die Tatsache, dass dort Kommandos mit der Tastatur eingegeben werden. Diese Umgebung umfasst viele sehr mächtige Werkzeuge, die oft übersehen und letztlich neu erfunden werden.

Manches, was es schon gibt, ist gut

Gerade vor einigen Tagen habe ich etwa für einige Zeit darüber nachgedacht, warum es in der JavaScript-Welt so viele unterschiedliche Tools gibt, um die Kompilation von Code oder die Erstellung gewisser Entwicklungsresultate zu automatisieren. Grunt und Gulp sind heute Standards in diesem Bereich, speziell für die Nutzung mit JavaScript entwickelt und ausgestattet mit einer komplexen Infrastruktur von Plug-ins.

Natürlich gibt es ähnliche Funktionalität auch in npm und diversen anderen JavaScript-Tools, und, ausgerichtet an den Vorlieben anderer Programmierer, rake für Ruby, cake für C#, Ant für Java und viele andere mehr. Ich habe einige Recherchen in diesem Bereich hinter mich gebracht, nur um festzustellen, dass all diese Implementationen eigentlich keine echten Vorteile mitbringen gegenüber ihrem Urvater: Make aus dem Jahre 1977. Viele Blogger scheinen mir zuzustimmen in dieser Einschätzung, und irgendwo habe ich dieses Zitat gelesen (den englischsprachigen Ursprung finde ich leider nicht mehr): Manche Probleme sind tatsächlich schon in den 70er Jahren von Männern mit Bärten gelöst worden.

Fazit

Ich empfehle Ihnen sehr, sich mit der neuen alten Umgebung, in der sich Softwareentwicklung in diesen Jahren mehr und mehr abspielt, vertraut zu machen. Aus gutem Grund zeigt sich das Konzept von Unix und seinen Kommandozeilenumgebungen stabil und mächtig, 47 Jahre nach dem Beginn seiner Entwicklung. Es ist leicht erkennbar, dass dies in der Softwarewelt einen herausragenden Stellenwert hat, und mit dem Einzug von Linux in Windows wird noch ein Stück deutlicher, dass die Geschichte von Unix in absehbarer Zeit nicht zu Ende geht.

Vermeiden Sie für sich selbst, Ihr Team und Ihre Firma, das Rad neu zu erfinden. Investieren Sie etwas Zeit, um die Möglichkeiten dieser neuen Welt im Detail kennenzulernen, und profitieren Sie von den Erkenntnissen anderer. Zum Abschluss, von mir persönlich und etwas polemisch: Programmierung ist keine Tätigkeit, die sich dauerhaft nur mithilfe einer Maus ausüben lässt.

Windows Developer

Windows DeveloperDieser Artikel ist im Windows Developer erschienen. Windows Developer informiert umfassend und herstellerneutral über neue Trends und Möglichkeiten der Software- und Systementwicklung rund um Microsoft-Technologien.

Natürlich können Sie den Windows Developer über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist der Windows Developer ferner im Abonnement oder als Einzelheft erhältlich.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -