Schlagwort-Archive: Shell

Bash on Ubuntu on Windows

Noch ist „Bash on Ubuntu on Windows“ Beta, aber das Ding wird bald allgemein unter Windows Einzug halten. Das Windows Subsystem for Linux (WSL) ist wesentlich mehr als nur eine Bash-Shell: Es bildet das komplette Dateisystem eines Ubuntu ab und enthält unter /bin und /usr/bin alle typischen Kommandozeilenwerkzeuge. Über die Ubuntu-Repositories und apt-get install können weitere Werkzeuge nachinstalliert werden. Trotz noch bestehender Mängel ist der Eindruck evident, dass hier Microsoft in Zusammenarbeit mit Canonical (Ubuntu) ein ehrgeiziges und nachhaltiges Projekt auf die Beine stellt.

Einrichtung und erster Eindruck

Als Vorbereitung ist unter Windows 10 zunächst via Startmenü über „Einstellungen -> Update und Sicherheit -> Für Entwickler“ der „Entwicklermodus“ zu aktivieren.

Danach wird in der Systemsteuerung unter „Programme und Features -> Windows Features aktivieren“ das Paket „Windows Subsystem für Linux“ angeboten und kann durch ein Häkchen und „OK“ installiert werden. Dieser Vorgang wird auch in Zukunft optional bleiben, da typische Windows-User eine Linux-Shell in der Regel nicht vermissen.

Optionales Feature: Das Linux-Subsystems wird kein Windows-Standard, sondern muss vom Nutzer nachgerüstet werden.
Optionales Feature: Das Linux-Subsystems wird kein Windows-Standard, sondern muss vom Nutzer nachgerüstet werden.

Nach dieser Aktion findet sich im Windows-Startmenü das neue Programm „Bash on Ubuntu on Windows“, das den kleinen Bash-Launcher aufruft (bash.exe). Falls das Startmenü den Link nicht anbietet, starten Sie die bash.exe manuell in Cmd-Konsole im Pfad \Windows\System32.

Neuerdings (2016 noch nicht beobachtet) kann sich noch eine kleine Hürde einstellen: Wenn der Aufruf der bash.exe mit der Meldung „Zur Verwendung dieses Features muss die Legacykonsole deaktiviert werden“ scheitert. klicken Sie rechts auf die Titelleiste der Cmd.exe und deaktivieren auf der Registerkarte „Optionen“ das Kästchen vor „Legacykonsole“:

Danach erledigt der Aufruf der bash.exe die eigentliche Installation des minimalen Ubuntu vom Canonical-Server. Am Ende werden Sie aufgefordert, ein (sudo-berechtigtes) Benutzerkonto und dessen Passwort anzulegen. Ab sofort ist die Bash-Shell einsatzbereit.

Die eigentliche Ubuntu-Umgebung befindet sich im User-Kontext unter \user\[Konto]\AppData\Local\lxss, darunter liegt das Dateisystem \user\[Konto]\AppData\Local\lxss\rootfs mit der üblichen Verzeichnisstruktur und etwa 550 MB nach der Installation. Diese Ordner werden vom Windows-Explorer versteckt, sind aber mit direkter Eingabe in die Explorer-Adresszeile ebenso wie mit der Cmd-Kommandozeile problemlos zu erreichen.
Die Benutzung der „Bash on Ubuntu on Windows“ unterscheidet sich bei einfacheren Aufgaben weder funktional noch leistungstechnisch von einer Ubuntu-Shell. Wer sich schon mal mit der weitaus hakeligeren Cygwin-Bash beschäftigt hat, wird in jeder Hinsicht positiv überrascht sein. Es gelingt uns mühelos, mit dem ssh-Client Verbindung zu unseren Servern aufzunehmen, was künftig die Windows-Clients Putty und Kitty weitgehend überflüssig machen könnte.

Bevorzugte Werkzeuge wie htop, nmap, inxi oder mc sind über apt-get problemlos nachinstalliert. Da der Midnight Commander hier auch SSH beherrscht, ist sehr bequemer Austausch des Windows-Systems mit Linux-Servern garantiert.

Für die direkte Zusammenarbeit mit Windows ist das Windows-Systemlaufwerk automatisch unter /mnt/c gemountet, was nach der Definition einiger Bash-Aliases schnell zum komfortablen Datenaustausch zwischen Windows-Desktop und Linux-Shell führt.

Weitere interne oder externe Laufwerke des Windows-Rechners sind gemäß den dort verwendeten Laufwerksbuchstaben unter /mnt/d, /mnt/e und so fort zu finden.

Der Befehl

uname -a

meldet brav ein 64-Bit-„GNU/Linux“ und

lsb_release -a

ein Ubuntu 14.04.5 LTS.

Zweimal das Verzeichnis /usr/bin: Das Dateisystem des Linux-Subsystems befindet sich im Benutzerkonto unter \Users\[Konto]\AppData\local\lxss.

Für Linux-Entwickler? Für Linux-User?

Schon das Freischalten des Subsystems mit der Option „Entwicklermodus“ macht deutlich, welche Zielgruppe Microsoft mit der „Bash on Ubuntu on Windows“ in erster Linie im Auge hat. Es sind Entwickler, die unter Linux mit Python, Ruby, Git und Gnu-Compiler arbeiten und dies theoretisch künftig auch unter Windows erledigen können. Microsoft behauptet allerdings auch, mit der Bash einfach nur eine gute Kommandoshell anbieten zu wollen, die dann auch normale Nutzer ansprechen soll (und natürlich solche, die an Bash gewöhnt sind). Einige Möglichkeiten tun sich da in der Tat zwanglos auf, zumal der Launcher bash.exe auch Parameterangaben vorsieht – etwa:

bash.exe myscript.sh
bash.exe -c "mc ~"

„Bash on Ubuntu on Windows“ ist ein unglaublich ambitioniertes Projekt, das jetzt schon überraschend viel kann und das unbedingt weitere Beobachtung verdient.

Der Vergleich zwischen der 2016 veröffentlichten „Bash on Ubuntu on Windows“ mit der aktuellen (Stand: 09.03.2017) zeigt, dass Microsoft und Canonical fleissig weiterentwickeln. Diverse Mängel bei der Bedienung, bei der Eingabe von Sonderszeichen  oder beim Scrollen im Editor, sind weitestgehend ausgeräumt.

Auch grafische Linux-Programme starten anstandslos, wenn unter Windows der X-Server xming (https://sourceforge.net/projects/xming/) installiert ist aud läuft. Grafische Tools hat das Ubuntu zwar zunächst nicht an Bord, sie sind aber über apt-get ebenso nachrüstbar wie Kommandozeilentools.

Als praktisches Highlight für den Benutzeralltag sehe ich die SSH-Shell-Verbindung im Midnight Commander. Umstandsloser, direkter und komfortabler  kann der unbeschränkte Dateiaustausch zwischen Windows und einem Linux-Server nicht stattfinden – auf der einen Seite das komplette Dateisystem des Linux-Rechners, auf der anderen Seite unter /mnt das komplette Dateisystem des Windows-Rechners. Die SSH-Clients Putty/Kitty haben bei mir weitgehend ausgedient.

Midnight-Commander mit SSH-Shell-Verbindung: Hier ist links der Windows-Desktop und rechts der Linux-Server im Bild.

Powershell für Ubuntu

Microsoft’s Powershell ist eine Kommandozeile mit genialer Technik, aber abweisender Bedienbarkeit. Die auf Linux portierte Powershell ist noch im Alpha-Stadium und zeigt neben der üblichen Sperrigkeit auch noch einige Baustellen.

„Ubuntu unter Windows“ hat einen ambitionierten und umfassenden Anspruch, befindet sich allerdings noch in der Entwicklung. Mit diesem Subsystem „Bash on Ubuntu on Windows“ hat der Linux-Admin eine Bash-Shell inklusive aller notwendigen Tools unter Windows 10 an Bord.
Den genau umgekehrten Weg geht Microsoft inzwischen mit der Powershell für Ubuntu, Cent OS, Red Hat und Mac OS X. Auch hier hat Microsoft die Admins im Visier: Ein an die Powershell gewohnter Windows-Admin findet dann auch unter Linux seinen vertrauten Kommandozeileninterpreter, und nebenbei sollen wohl auch alteingesessene Linux-Admins von der Überlegenheit der Powershell gegenüber einer Bash überzeugt werden. So ganz sicher sind wir uns da nicht…

Das Alleinstellungsmerkmal der Powershell

Eine Bash-Shell unter Linux oder der altehrwürdige Cmd-Kommandointerpreter unter Windows sind sich in einem Kernpunkt ganz nahe: Um irgendwelche Datei-, Netzwerk-, Prozess- oder Laufwerkseigenschaften oder wie auch zu ermitteln und zu verarbeiten, muss die Textausgabe irgendeines einschlägigen Kommandos gefiltert werden (mit wiederum einschlägigen Mitteln wie grep, sort, awk…), um dann das Wesentliche in eine Variable oder auf den Bildschirm zu schreiben. Das ist mühsames Handwerk und zudem fehleranfällig, sobald ein Tool seine Textausgabe marginal verändert.
Die internen Befehle der Powershell (Cmdlets) arbeiten hingegen objektorientiert. Ein Befehl

get-process

mag auf den ersten Blick nicht viel anders aussehen als ein ps -A in der Bash-Shell. Der fundamentale Unterschied zeigt sich, wenn nach

 $a=get-process

die Variable $a sämtliche Eigenschaften sämtlicher Prozesse enthält. Diese Objektmenge lässt sich dann wiederum zielgenau nach Eigenschaften filtern:

 $a | where {$_.name -like "firefox"}

Dies zeigt die wichtigsten Eigenschaften des Prozesses „firefox“ (wenn Sie der Zeile noch ein “ | select *“ anhängen, erscheinen alle Eigenschaften). Dieser Befehl

 $a | select name,cpu | sort-object cpu

sortiert die Prozesse mit der höchsten CPU-Nutzung aufsteigend und zeigt dabei nur die beiden Eigenschaften „name“ und „cpu“ an. Ein letztes Beispiel

 get-process | where {$_.cpu -gt 40} | select name,path,starttime,cpu

liefert für die Prozesse mit höherem CPU-Verbrauch vier wesentliche Eigenschaften.
Eine Einführung in die Powershell ist an dieser Stelle nicht möglich (siehe dazu den Beitrag Windows-Powershell auf meiner Web-Seite). Nur soviel: Mit die mühevollste Aufgabe in der Powershell ist es, jeweils die benötigten Eigenschaften oder Methoden eines Objekts zu ermitteln. Der einschlägige Befehl dafür lautet jeweils „get-member“:

get-process | get-member
dir /home | get-member
echo "Hallo" | get-member

Dies zeigt die Eigenschaften von Prozess-, Dateisystem- und String-Objekten.

Installieren und Einrichten unter Ubuntu

Die Installation der Powershell unter den bislang vorgesehenen Distributionen ist zunächst ganz einfach: Das unter der freizügigen MIT-Lizenz verfügbare Paket erhalten Sie unter https://github.com/PowerShell/PowerShell. Wir haben unter Ubuntu 16.04 das passende DEB-Paket geladen. Für die Installation genügt danach der Doppelklick auf das Paket, das nach unserer Erfahrung die Komponenten libunwind8 und libicu55 bereits mitbringt (Hinweise im Internet, diese gesondert nachzurüsten, sind demnach hinfällig). Auf Headless-Servern geht natürlich auch die Einrichtung mit

dpkg -i [Paketname]

auf der Kommandozeile.
Die Powershell erscheint unter Ubuntu nicht im Dash, sondern muss im Terminal mit dem Befehl powershell gestartet werden. Im Prinzip kann man nun loslegen, jedoch wird die sperrige Shell niemand verwenden, ohne sie über eine Profildatei mit Aliases und Functions etwas kommoder zurechtzulegen. Der nach der Installation eingerichtete Ordner „~/.config/PowerShell“ ist nicht der richtige Ort dafür, wie die Abfrage mit $Profile zeigt. Der Ordner muss in Kleinschreibung „~/.config/powershell“ lauten und die Profildatei exakt „Microsoft.PowerShell_profile.ps1“. Wer von Windows kommt und ein PS1-Startscript besitzt, ist mit der Kopie dieses Scripts an den beschriebenen Ort schon mal ein gutes Stück weiter.
Ein Tipp: Mit dem Aufruf

powershell -noexit -file [Pfad]/xyz.ps1

lässt sich jedes PS1-Script für eine Sitzung als Startscript definieren.
Grundsätzliche und aktuelle Beschränkungen
Wer die Powershell unter Windows einigermaßen kennt (und nur solche Nutzer kommen ernsthaft in Betracht), stellt schnell fest, dass der Umgang mit fundamentalen Objektklassen wie Dateien, Strings, Prozesse unter Linux vertraut und fehlerlos funktioniert. Aber die technischen Unterschiede machen unter Linux einige Cmdlets sinnlos (Registry) oder vorerst unportierbar (Dienste-Kontrolle mit get-service, Management-API über das wmi-object oder Windows Remote Management über WinRM). Dies relativiert die Aussagen Microsofts schon signifikant, dass ein Powershell-Kundiger seine Investitionen nun nach Linux mitnehmen kann.

Daneben gibt es auch kleine, nervige Probleme, die es aktuell zu umgehen oder auszuräumen gilt: Um den Linux-Admin nicht abzuschrecken, verzichtet die Shell auf diverse Aliases, die wiederum der Windows-Admin erwartet. So nutzt etwa eine Pipe mit „[…] | sort“ den üblichen Sort-Befehl von Linux, der Text statt Objekteigenschaften zurückgibt. Wer das Powershell-Cmdlet braucht, muss es mit „[…] | sort-object“ explizit ausschreiben.
Eine irritierende Kleinigkeit ist es, dass eine Prompt-Funktion im PS1-Startscript aktuell einen mit write-host definierten Kommandoprompt zweimal ausgibt. Die Recherche im Internet zeigt, dass man mit diesem Fehler nicht allein ist auf der Welt – allerdings so gut wie allein: Die Powershell ist unter Linux-Admins und Nutzern definitiv noch nicht angekommen.

Fazit: Eine unfertige Alpha (Microsoft) ist die Powershell für Linux nicht mehr, aber für aufgeregte Begeisterung im Linux-Lager reicht es – wenn je – derzeit nicht. Man sollte aber dieses Präzisionswerkzeug nicht unterschätzen: Insbesondere die exzellenten Möglichkeiten der String-Verarbeitung könnten auch Admins überzeugen, die ihre Konfigurationsdateien bislang mit sed & Co. manipuliert haben. Es ist ja keineswegs so, dass sich die Bash und die Powershell als Entweder-Oder konkurrieren: Ist ein Spezialjob in der Powershell erledigt, ist der Admin mit einem exit wieder zurück in der Bash-Heimat.

Mehr Infos zur Powershell für Linux

Download: https://github.com/PowerShell/PowerShell

Infos: https://msdn.microsoft.com/en-us/powershell

Quelle für Powershell-Insider mit Details über Cmdlets, die der Powershell für Linux und Mac OS X entweder fehlen oder noch nicht funktionieren: https://github.com/PowerShell/PowerShell/blob/master/docs/KNOWNISSUES.md

Microsoft-Video (50 min.): https://youtu.be/2WZwv7TxqZ0

Eine typische Powershell-Pipeline unter Ubuntu: Die Syntax ist bekannt sperrig und nötigt zur Recherche, belohnt aber mit Präzision und exakt definierbarer Ergebnismenge.