Shelltools in Rust – was zum Teufel?

Etablierte Kommandozeilenwerkzeuge für Linux und Unix wie ls oder grep existieren als Nachbau neuerdings auch in Rust, und mancher verbindet mit der Reimplementierung große Hoffnung in Sachen Komfort, Performance und Robustheit. Was motiviert die Macher dieser Werkzeuge, wie praktisch sind sie im Alltag und lohnt sich für passionierte Admins ein Blick über den Tellerrand?

Von Martin Gerhard Loschwitz

Wenn Filme- und Serienmacher Hacker bei der Arbeit zeigen, muss dafür üblicherweise der Quelltext von Programmen oder die Kommandozeile herhalten, auf der manchmal sogar Befehle wie ip mit der korrekten Ausgabe zu sehen sind. Passionierte Systemadministratoren können da nur lachen – denn natürlich wissen sie, dass hier nichts Sinistres vonstattengeht, sondern dass Werkzeuge wie ls, du oder grep einfach Bestandteil der Arbeit sind.

Die meisten Administratoren haben die gängigen Befehle so weit verinnerlicht, dass sie unmittelbar nach dem Öffnen einer Shell oder nach dem Aufbau einer SSH-Verbindung quasiautomatisch ein paar CLI-Befehle absetzen: ls, um zu schauen, welche Dateien lokal vorhanden sind, ps, um zu erfahren, was auf dem System los ist, w, um die gerade eingeloggten Nutzer zu zeigen, und so weiter.

Etwas Seltsames allerdings geht seit einer Weile vor sich im Land der Kommandozeile: Eine kleine Gruppe von Enthusiasten ist dabei, Rust-Versionen der gängigen CLI-Werkzeuge zu bauen und die alteingesessenen Werkzeuge durch diese neuen Versionen zu ersetzen. Modernes Teufelszeug, wirft mancher Administrator da intuitiv ein. Wer dem Thema so begegnet, liefert aber eine zumindest unterkomplexe Analyse der Situation.

Muss man das ernst nehmen?

Was als akademisches Projekt für Rust-Eiferer begonnen haben mag, hat sich nämlich längst zu einer ernst zu nehmenden Bewegung entwickelt, und die Rust-Versionen der CLI-Standardwerkzeuge sind längst mehr als einfache Klone. So verweisen die Entwickler von Tools wie ripgrep statt grep, eza statt ls und procs statt ps beispielsweise darauf, dass Rust als extrem effiziente Programmiersprache gilt, die für den Bau von CLI-Werkzeugen wie geschaffen sei. Gerade wer sich mit grep, sed oder awk schon mal durch größere Datenmengen gewühlt hat, weiß, dass das schnell eine zeitraubende Angelegenheit wird. ripgrep, ruplacer und frawk sollen hier durch deutliche Performancezugewinne punkten.

Obendrein ist Rust für sein robustes Memory Handling bekannt, sodass typischerweise aus mangelhafter Speicherverwaltung resultierende Sicherheitslecks und Stabilitätsprobleme erst gar nicht entstehen können. Zugegeben: Bugs in ls oder ps lassen sich selten ausnutzen, um Systeme zu übernehmen. Unmöglich ist das aber nicht. Bei Rust, so die Rust-Fans, sei die Wahrscheinlichkeit dafür viel geringer.

Grund genug, sich die verfügbaren Rust-Klone bestehender CLI-Werkzeuge einmal genauer anzuschauen und dabei über den Elefanten zu sprechen, der offensichtlich im Raum steht: Versenken die Rust-Fans viel Zeit in ein Hobby, das außerhalb der Rust-Gemeinde niemandem nützt – oder können die in Rust verfassten Alternativen zu klassischen CLI-Werkzeugen einen tatsächlichen Mehrwert gegenüber ihren etablierten Vorfahren bieten?

Quer durchs Gemüsebeet

Um es gleich am Anfang klar zu sagen: Nur die ganz harten Rust-Fans wünschen sich, dass das Gros der Admins seine lieb gewonnenen Shell-Utils wegwirft und ab sofort stattdessen exklusiv mit den jeweiligen Rust-Varianten arbeitet. Das dürfte in den meisten Fällen schon deshalb auch praktisch unmöglich sein, weil es die gängigen CLI-Werkzeuge schon so lange gibt, dass ihre Nutzung wie beschrieben vielen Admins längst in Fleisch und Blut übergegangen ist. Die Muße, sich eine ganze Weile dazu zu zwingen, statt ps lieber procs einzugeben, bis dieses ebenso fast schon unbewusst den Weg durch die Finger auf die Tastatur findet, dürften die wenigsten Admins haben.

Das bedeutet aber nicht, dass die in Rust verfassten Alternativen zu den gängigen CLI-Werkzeugen sich zu bestimmten Einsatzzwecken oder zu besonderen Anlässen nicht hervorragend als Ergänzung zu ihren Gegenstücken in C verwenden ließen. Und eben darauf läuft es in den meisten Fällen auch erst mal hinaus. Aus Sicht interessierter Admins stellt sich damit vor allem die Frage, welche bekannten Tools überhaupt Rust-Alternativen besitzen und was diese leisten. Ein paar Rust-Verfechter haben zu diesem Thema übersichtliche Tabellen zusammengetragen, die einen guten ersten Eindruck der Wahlmöglichkeiten bieten (siehe ix.de/zmcw). Und diese langen Listen machen schnell deutlich: Den Rust-Enthusiasten ist es mit ihrem Anliegen durchaus ernst (siehe auch Tabelle „Rust-Tools und ihre C-Pendants“).

Entsprechend umfangreich ist die Liste der Standardwerkzeuge, die mittlerweile auch in Rust zur Verfügung stehen. Naturgemäß stellt sich den Entwicklern dabei eine Herausforderung: Wie sollen die Werkzeuge heißen? Ein echtes Drop-in Replacement würde einen identischen Namen voraussetzen. Das verbietet sich auf den meisten Systemen aber, weil es ansonsten unvermeidbar zu einem Chaos aus C- und Rust-Werkzeugen käme. Die allermeisten Autoren von Rust-Werkzeugen haben sich also für einen Mittelweg entschieden: Die Werkzeuge selbst heißen zwar anders, beherrschen im Wesentlichen aber dieselben Kommandozeilenparameter wie das jeweilige Ursprungswerkzeug aus der GNU-Kollektion.

Auch das ist an dieser Stelle ja durchaus noch zu beachten: Dass cp, ls und Konsorten nämlich nicht nur in der – unter Linux üblicherweise genutzten – Version des GNU-Projekts zur Verfügung stehen, sondern ihrerseits eigentlich ein Nachbau der jeweiligen BSD-Kommandos sind. Die unterstützten Parameter unterscheiden sich zwischen den BSD-Varianten und den GNU-Versionen dabei heute oft noch im Detail. Wer beispielsweise regelmäßig auf macOS arbeitet und dort das Terminal nutzt, hat die zu Darwin gehörenden Kommandozeilenwerkzeuge vorinstalliert, die von den BSD-Versionen abstammen. Tools wie grep und ps quittieren einen Aufruf, der auf einem Linux-System klappen würde, dann oft bloß mit einer Fehlermeldung.

Damit das Chaos sich nicht in die Rust-Welt fortsetzt, entscheiden sich die meisten Rust-Entwickler zumindest für teilweise Kompatibilität mit den jeweiligen GNU-Werkzeugen. Das bedeutet auch, dass es in Skripten recht einfach ist, von der C-Variante auf die Rust-Variante umzustellen. Denn ein Kommando wie ls -la wird dann einfach zu eza -la, ansonsten ändert sich aber kaum etwas (siehe Abbildung 1). Überhaupt ist eza ein gutes Beispiel dafür, dass sich mit den Rust-Nachbauten der gängigen CLI-Werkzeuge sinnvoll arbeiten lässt.

Manchen Rust-Entwicklern geht es allerdings um echte Drop-in Replacements. Mit den uutils-coreutils steht deshalb ein in Rust verfasster Werkzeugsatz zur Verfügung, der vollständige CLI-Kompatibilität zu den GNU-Werkzeugen erreichen will und jede Abweichung davon als Bug betrachtet. Hier geht es tatsächlich darum, lieb gewonnene Befehle wie ls durch ein Rust-Pendant zu ersetzen (siehe Abbildung 2 und das Interview auf Seite 58).

Ruckelige Installation

Bevor sich Werkzeuge wie eza in ihrer ganzen Schönheit verwenden lassen, offenbart ihre Installation allerdings eine der großen Schwachstellen, an denen die Rust-Werkzeuge derzeit leiden. Zumindest jene, die nicht Teil der uutils-coreutils sind. Denn es gibt keine fertige, leicht installierbare Sammlung all jener Werkzeuge, die Standard-CLI-Befehle in Besser mit anderem Namen nachbauen wollen. Jedes Werkzeug kocht stattdessen sein eigenes Süppchen, und will man alle Rust-Substitute für die gängigen CLI-Kommandos zusammentragen, ist das eine aufwendige und zeitraubende Tätigkeit (Eine möglichst vollständige Linksammlung findet sich unter ix.de/zmcw).

Für eza, also den ls-Ersatz in Rust, existiert etwa in Arch Linux eine Integration in Pacman. Für Debian GNU/Linux und die aktuellen Ubuntu-Versionen steht ein PPA-Verzeichnis zur Verfügung. In Gentoo gibt es einen Emerge-Port. Fedora legt eza als RPM-Paket bei, das sich mit dnf einfach installieren lässt. Unter macOS stellt Homebrew eine Variante des Programms bereit.

Mühsame Suche

Wer sich eza so aufs System holt, hat eben nur eza, aber noch kein einziges der vielen anderen für den Alltag nötigen Werkzeuge. Wer procs will, navigiert erst mal zu dessen GitHub-Verzeichnis und sucht die Installationsanweisungen für das eigene Betriebssystem oder die Distribution heraus. Wer das für die zwölf Standardwerkzeuge, die der Nutzer STS10 auf GitHub zusammengetragen hat, praktiziert, hat bald keine Lust mehr.

Erschwerend kommt hinzu, dass es für manche GNU-Werkzeuge nicht nur einen Rust-Ersatz gibt, sondern mehrere konkurrierende. Für diff etwa listet die erwähnte GitHub-Seite delta und difftastic als mögliche Alternativen. Noch bunter wird es bei du: Hier buhlen diskonaut, dua, dust, dutree, erdtree, pdu und tin-summer um die Gunst der Nutzer. Auch für ls steht eine Alternative zu eza in Form von lsd zur Verfügung. Und manche essenziellen Shellwerkzeuge fehlen in der Liste vollständig, etwa ein adäquater, sprich kompatibler Ersatz für awk.

Wieder andere alternative Rust-Implementierungen bekannter Shellutils sind im Netz zwar zu finden, fehlen aber auf der kuratierten Liste. Im Zweifelsfall muss der Admin also mehrere Varianten von Rust-CLI-Alternativen vergleichen und die für ihn beste, am leichtesten zu installierende oder flotteste Alternative herausfinden. Komfortabel ist das nicht, und es verleidet die Vorfreude auf den Einsatz der Rust-Werkzeuge erheblich.

Nicht immer kompatibel

Hat man sich durch den Dschungel der Alternativen und ihre Installationsvorgänge gekämpft, steht im Idealfall eine lokale Sammlung von Rust-basierten Alternativen zu den GNU- oder BSD-Varianten des Betriebssystems parat. Bei eza beispielsweise fällt auf, dass eza -la nicht klaglos als echtes Drop-in Replacement für ls funktioniert. Die Ausgaben sind sehr ähnlich, aber nicht deckungsgleich. Shellskripte etwa, die die Ausgabe von ls interpretieren wollen, würden zumindest bei eza also schon auf die Nase fallen.

Auf macOS fällt obendrein auf, dass von der versprochenen Geschwindigkeit durch Rust nicht allzu viel zu spüren ist. Im Gegenteil: Eine flotte – nicht professionelle – Messung mit time ergibt, dass eza -la fast doppelt so lange dauert wie ls -la, sprich 0,2 Sekunden gegenüber 0,1 Sekunden. Bei rekursiven Durchläufen mit -laRS in großen, tiefen Verzeichnissen wurden die Unterschiede noch deutlicher (siehe Tabelle „ls -laRS vs. uls -laRS vs. eza -laRS“). Auf Ubuntu 24.04 waren die Zeiten von eza und ls beinahe identisch – hier liefen die Werkzeuge aber auch auf x86_64 und nicht auf AARCH64.

Noch mal etwas anders gestaltet sich die Erfahrung mit procs, dem ps-Ersatz in Rust. Hier wird schnell klar, dass den Entwicklern die Eigenschaft ihres Werkes, als Drop-in-Ersatz für das klassische ps zu fungieren, nicht sonderlich wichtig war. procs -auxw beispielsweise schlägt fehl. procs -a funktioniert, fördert anders als ps a aber nicht eine Liste aller Prozesse des Nutzers auf den Bildschirm, sondern eine Art interaktive Ansicht (siehe Abbildung 3). Sie erinnert eher an die Ausgabe von top. Das wirft procs zumindest als unmittelbaren Ersatz für ps aus dem Rennen.

Eigene Stärken

Zudem kennt das Werkzeug diverse CLI-Parameter nicht, die Administratoren im Alltag unter Linux mit den GNU-Werkzeugen regelmäßig nutzen. ps fauxw beispielsweise zeigt einen Baum der gestarteten Prozesse des Systems mit diversen Zusatzinformationen an. procs aber unterstützt von diesen Parametern nur -a. Eine Baumansicht lässt sich mittels -t erreichen, viele andere ps-Parameter sind gar nicht implementiert. Weder für Shellskripte noch für die alltägliche Nutzung kann bei procs also von einem Eins-zu-eins-Ersatz die Rede sein.

Arbeitet man mit der Riege der In-etwa-Nachbauten, lässt sich das Spiel beliebig wiederholen. difftastic etwa kommt ebenfalls mit Pager-Funktion daher wie procs, beherrscht viele CLI-Parameter von diff nicht und ist beim Aufruf mit diesem entsprechend nicht kompatibel.

Dabei soll an dieser Stelle nicht der Eindruck entstehen, als seien die Rust-Programme, die als Ersatz für die klassischen Shelltools antreten, wegen ihrer teils unvollständigen oder gar nicht gegebenen Kompatibilität zu den historischen Vorbildern schlechter oder minderwertig. Ganz im Gegenteil: Manche Rust-Programme liefern Funktionen, die man sich von den klassischen Vorbildern wünscht.

Der du-Ersatz dua ist dafür ein gutes Beispiel: Dessen Ausgabe ist auch ganz ohne die Angabe von Parametern deutlich übersichtlicher und schicker als jene des normalen du. Will man etwa eine Übersicht der Dateien im lokalen Ordner haben, sortiert nach ihrer Größe und aufsteigend, geht das auf der Shell beispielsweise mit

du -sh ./*  2> /dev/null | sort -h

(siehe Abbildung 4). Oder eben mit dua ohne Parameter (siehe Abbildung 5): Das liefert nicht nur eine übersichtliche farbige Liste, sondern zeigt während der Erhebung der Daten auch den Fortschritt an. Beim klassischen du wartet man stattdessen vor einer leeren Anzeige. Richtig komfortabel wird dua, wenn man es mit dua i im interaktiven Modus startet und damit nicht nur die Festplatte oder SSD durchstöbern, sondern bei der Gelegenheit gleich aufräumen kann. Das Beispiel zeigt: Die Rust-Werkzeuge liefern an vielen Stellen echten Mehrwert.

Coreutils in Rust – als echter Ersatz gedacht

Wer auf der Suche nach einem echten Ersatz für die C-Shellutils ist, muss stattdessen zu den Coreutils des uutils-Projektes wechseln (siehe Tabelle „GNU Coreutils vs. uutils-coreutils“ und ix.de/zmcw). Doch ist hier Vorsicht angesagt: Wer die Werkzeuge installiert, führt tatsächlich die Rust-Werkzeuge aus, wenn er Befehle wie cp oder ls aufruft. Manche Paketmanager umgehen das Problem, indem sie die Tools in einen Pfad außerhalb von $PATH legen und in den Aufrufpfad dann Wrapper packen, die u<Programmname> heißen, oder gleich als u<Programmname> ablegen. Auf macOS unter Homebrew wird aus ls so etwa uls.

Wer tatsächlich dauerhaft auf die Rust-Werkzeuge umsteigen möchte, fügt im ersten Fall den Ordner /usr/local/opt/uutils-coreutils/libexec/uubin der Liste der Pfade hinzu, in denen die Shell nach Programmen sucht. So oder so gilt aber: Wer die Rust-Version der Coreutils installieren möchte, tut vermutlich gut daran, zunächst in einer virtuellen Instanz zu experimentieren.

Im Test haben sich die Werkzeuge des Coreutils-Pakets von uutils dabei durchaus bewiesen. Das gilt zunächst für die CLI-Kompatibilität mit den GNU-Werkzeugen: Sämtliche Parameter für ls existieren in der Rust-Version und führen zur selben Ausgabe wie beim C-Gegenstück. Die Ausgabe von df ist identisch und lässt sich durch verschiedene Parameter steuern.

Flott unterwegs

Auch in Sachen Geschwindigkeit konnten die Werkzeuge aus der Coreutils-Sammlung von uutils punkten. Schnelle Messungen mit time ergaben, dass etwa der Aufruf von ls -ltR deutlich langsamer war als jener von uls -ltR. Hier betrug der Unterschied bei einem großen Verzeichnis mit vielen Unterverzeichnissen mehr als eine Sekunde (siehe auch Tabelle „ls -laRS vs. uls -laRS vs. eza -laRS“).

Freilich spielt der Kernel des Systems zusammen mit dem genutzten Dateisystem eine große Rolle bei der Frage nach der Dauer der Ausführung solcher Befehle. Zumindest kamen beim Schnelltest in der Redaktion aber dieselben Ordner und Kommandos zur Anwendung, um sowohl die klassischen Coreutils in C als auch ihre Rust-Pendants zu testen. Obendrein gelten die Vorteile auch nicht bei allen Programmen.

Wer die Coreutils in Rust ausprobieren möchte, findet im Netz für die meisten Distributionen fertige Pakete oder eine andere Form der Integration – auch für Debian GNU/Linux, und das ist alles andere als ein Zufall. Denn hinter den uutils-coreutils steht Sylvestre Ledru, Präsident der Mozilla-Foundation, Debian-, Ubuntu-, LLVM-, Clang-Entwickler und Rust-Fan, der die Arbeit an der Werkzeugsammlung während der Coronapandemie begann.

In der Community verankert

In einem Vortrag während der FOSDEM 2023 erklärte er die Beweggründe: Neben den erwähnten Vorteilen in Sachen Sicherheit sei Rust vor allem extrem gut portierbar. Obendrein stünden in Rust nativ viele Funktionen zur Verfügung, die man in C erst mühsam nachbauen muss. Die walkdir-Funktion etwa ermöglicht das Iterieren durch Dateisystembäume und ist die perfekte Grundlage für Werkzeuge wie cp oder rm. Einen großen Teil ihrer Geschwindigkeitsvorteile erreichen die uutils-coreutils, indem sie auf eben diese Funktionen zurückgreifen. In Form von lscolors steht – das ist fast schon witzig – in Rust sogar eine Funktion bereit, die die Ausgabe in dieselben Farben tunkt wie das ls aus den GNU Coreutils.

Sein ursprüngliches Ziel, ein Debian-System auf Basis seiner Rust-Werkzeuge zum reibungslosen Start zu bringen, hat Ledru dabei schon längst erreicht. Noch betrachtet er die Entwicklung aber nicht als abgeschlossen – noch bessere Kompatibilität zu den Coreutils sei das Ziel, und ein Quäntchen Performance sei hier und dort wohl auch noch aus den Werkzeugen herauszupressen. Wer die uutils-coreutils installiert, merkt im Alltag jedenfalls nur noch sehr selten, dass er nicht die GNU-Version der Werkzeuge nutzt.

Auch lizenzrechtlich haben die grundsätzlich sehr strengen Debian-Entwickler an den uutils-coreutils nichts auszusetzen, denn Ledru, immerhin ja einer der Ihren, hat sein Werk unter die MIT-Lizenz gestellt, die kaum irgendeine Art und Weise der Verwendung ausschließt. Ähnlich verhält es sich übrigens auch mit jenen Werkzeugen, die nicht zu den uutils-coreutils gehören: Hier findet sich zwar ein recht bunter Strauß an Lizenzen, ihnen allen ist aber gemein, dass sie als frei im Sinne der FSF, des GNU-Projekts und der Debian Free Software Guidelines gelten.

Wer die Rust-Variante der Coreutils ausprobieren möchte, findet auf der Website des Projekts dafür die nötigen Informationen (siehe ix.de/zmcw). Der einzige Wermutstropfen: Zu den Coreutils gehören alltägliche Werkzeuge wie ls und cp, das allseits beliebte grep fehlt aber ebenso wie ein Nachbau von awk oder sed. Hier muss man im Zweifelsfall also doch wieder auf Werkzeuge aus der Community zurückgreifen, deren Ziel nicht die vollständige Kompatibilität mit den jeweiligen GNU-Varianten der Programme ist – wie etwa bei procs oder eza.

Kleines Trostpflaster: Immerhin arbeitet das uutils-Projekt an zwei weiteren Sammlungen: Noch ganz am Anfang stehen die uutils-diffutils, und von den avisierten Werkzeugen find, locate, updatedb und xargs der GNU Findutils existieren zumindest schon Rust-Nachbauten von find und xargs.

Fazit

Perfekt komfortabel bettet man sich im Land der Rust-Werkzeuge auf der Shellebene bis dato also noch nicht, auch wenn sich die meisten Funktionen bereits durch bestehende Werkzeuge ersetzen lassen. Die Daten und Messwerte, die sich aus den bereits nachgebauten Rust-Werkzeugen ergeben, machen aber Lust auf mehr. Bis es beispielsweise einen Eins-zu-eins-Ersatz für diff gibt, dürfte es nur eine Frage der Zeit sein. Administratoren sollten nicht davor zurückschrecken, neue Pfade zu beschreiten und insbesondere den uutils-coreutils eine Chance zu geben.

Auch bei den In-etwa-Nachbauten und den Neuschöpfungen finden sich interessante, moderne und performante Werkzeuge, die Admins sich wiederholende Aufgaben abnehmen oder diese komfortabler gestalten. Dabei bleiben die Entwickler nicht bei den üblichen Datei- und Prozesswerkzeugen für die Kommandozeile stehen. Moderne Terminal-Emulatoren, Shells, Dateimanager, Kalkulatoren, Netzwerk- und Entwicklerwerkzeuge sowie Editoren und Viewer etwa für Text-, Markdown-, CSV- und Binärdateien können ebenso den Arbeitsalltag erleichtern (siehe Tabellen dazu). Wir werden einige von ihnen in kommenden Heften separat vorstellen. (sun@ix.de)