Moderne Linux-Tools: Neue CLIs als Ersatz für klassische Befehle

• Vorstellung verschiedener moderner Kommandozeilen-Tools, die die Effizienz bei der Arbeit unter Linux steigern
• Enthalten sind viele leistungsorientierte Tools, die klassische Unix-Befehle modern ersetzen oder erweitern und häufig mit Rust, Go u. a. entwickelt wurden

Tools zum Anzeigen und Durchsuchen von Dateien

• bat : Erweiterte Version des cat-Befehls mit Syntax-Highlighting und besserer git-Integration
• exa : Moderner Dateilisten-Viewer als Ersatz für ls/tree, wird derzeit aber nicht mehr gepflegt
• eza : Fork von exa, bietet ein modernes ls/tree
• lsd : Next-Generation-ls mit Unterstützung für bestehende Kompatibilität und eleganterer Ausgabe
• broot : Baumförmiger Datei-Browser mit verbesserter Navigation
• nnn : Leichtgewichtiger und schneller Datei-Manager fürs Terminal

Analyse von Datei- und Verzeichnisgrößen

• ncdu : Bietet eine textbasierte, intuitive du-Oberfläche
• dust : Einfacherer du-Ersatz, implementiert in Rust
• duf : Tool zur Analyse der Festplattennutzung mit verbesserter Bedienbarkeit gegenüber df

Datei- und Codesuche

• fd : Kompakter und schneller find-Ersatz mit hoher Benutzerfreundlichkeit
• ripgrep : Ultraschneller grep-Ersatz mit Unterstützung für .gitignore
• ag : Code-Suchtool ähnlich ack, aber noch schneller
• fzf : Universelles Fuzzy-Suchtool; lässt sich in Pipelines und vielen anderen Kontexten einsetzen
• bfs : find-Ersatz auf Basis von Breadth-First Search

Git-/diff-Viewer im Terminal

• delta : Visualisiert Ergebnisse von git und diff besonders gut lesbar

Befehlsverlauf und -verarbeitung

• mcfly : Verbessert Suche und Navigation im Shell-Verlauf grundlegend; mit besserer Suchqualität und intuitiver UI

Datenverarbeitung

• choose : Intuitiverer und schnellerer Ersatz für cut und teilweise awk
• jq : Datenparser, der sich wie ein sed speziell für JSON verwenden lässt
• sd : Benutzerfreundlicheres Find/Replace als Ersatz für sed

System-/Prozessüberwachung

• bottom : Plattformübergreifender grafikbasierter System- und Prozessmonitor
• glances : Verbesserte Version von top/htop
• gtop : Dashboard-artiger Systemmonitor fürs Terminal
• procs : In Rust geschriebener Ersatzbefehl für ps

Benchmarking und Netzwerk

• hyperfine : Automatisierungstool für CLI-Benchmarks
• gping : Ping-Tool mit grafischer Ausgabe

HTTP-Clients

• httpie : Moderner und benutzerfreundlicher HTTP-Client für die CLI; gut geeignet zum Testen von Entwickler-APIs
• curlie : Tool, das die Power von curl mit der Benutzerfreundlichkeit von httpie kombiniert
• xh : Leistungsorientierter Ersatz für httpie

Verzeichniswechsel und Editor

• zoxide : Smarter cd-Befehl, inspiriert von z
• micro : Terminal-Texteditor mit modernen Funktionen

Neuere CLI-Dienstprogramme

• up : Pipeline-Tool mit Echtzeitvorschau, mit sofortiger Sicht auf die Befehlsausgabe

Hilfe- und Dokumentationstools

• ManKier : Zusammengefasste man-Seiten mit sauber aufbereiteten Befehlserklärungen
• tldr : Kompakte, beispielorientierte Zusammenfassungen von man-Seiten
• tealdeer : In Rust implementierte tldr-Version mit schneller Ausführung
• explainshell : Analysiert Befehlsargumente automatisch und erklärt ihre Bedeutung visuell
• cheat.sh : Online-Hilfsdienst, der tldr und Cheatsheets kombiniert

GUI-Tools

• baobab : GUI-basierter Analysator für Festplattennutzung
• stacer : GUI-Tool für Systemoptimierung und Monitoring, inklusive Dienstverwaltung

[GN⁺]

Hacker-News-Kommentare

• Diese Tools mögen objektiv besser sein, aber ich habe gemerkt, dass es ein endloser Aufwand ist, sie jedes Mal neu einzurichten, wenn man ein OS frisch installiert, eine VM startet oder sich per SSH verbindet. Es ist ermüdend, jede Umgebung einzeln zu konfigurieren, und ich möchte auch nicht an einem Ort neue Tools und an einem anderen traditionelle Tools gemischt verwenden. Die klassischen Tools richtig zu beherrschen, macht das Leben letztlich am einfachsten

  • Manche Menschen verbringen die meiste Zeit auf ihrem eigenen Rechner, deshalb ist der Mehrwert solcher Komfortverbesserungen für sie groß. Trotzdem können sie die klassischen Tools auch einigermaßen bedienen, sodass das für gelegentliche Arbeit auf anderen Servern ausreicht. Nicht jeder ist ein Systemadministrator, der den ganzen Tag auf vielen verschiedenen Servern eingeloggt sein muss

  • Manche Tools sind so viel besser, dass sie den kleinen Aufwand der Installation absolut wert sind. Ich komme mit den klassischen Tools gut klar, aber fd oder ripgrep sind einfach immer besser

  • Einer der Hauptgründe, warum ich Nix wirklich liebe, ist, dass ich in fast jeder Umgebung das gleiche Setup haben kann (solange es linux oder macOS ist, kümmere ich mich nur um diese beiden). Es gibt mehrere Möglichkeiten, Nix ohne Root-Rechte zu installieren, sodass ich meine Umgebung praktisch überall nachbauen kann. Natürlich reichen auch die klassischen Tools aus, wenn es kein Nix gibt. Man muss sich nicht für nur eines von beiden entscheiden, man kann beides haben

  • Wenn ich ein OS neu installiere, muss ich ohnehin die benötigten Pakete mit apt-get, pacman, dnf, brew oder Ähnlichem installieren, und meinen Browser oder Editor installiere ich ebenfalls separat. Wenn ich mich per SSH einlogge, kann ich ohnehin keine GUI verwenden, aber das ist für mich kein Grund, GUI-Tools zu meiden. Selbst wenn sich die Tool-Zusammenstellung zwischen privater und gemeinsamer Umgebung unterscheidet, halte ich das nicht für ein großes Problem. Zum Beispiel ersetzt bat cat nicht vollständig, sondern macht das Leben einfach durch Syntax-Highlighting angenehmer. Wenn es nicht installiert ist, benutze ich es eben nicht

  • Meiner Meinung nach ist es im Sinne der UNIX-Philosophie „eine Sache gut machen“ gerade der Kern solcher einfachen Utilities, dass man sie leicht austauschen kann, wenn eine bessere Alternative auftaucht. Für die Karriere ist es richtig, zuerst die klassischen Werkzeuge zu lernen, aber ich finde, man sollte neue Alternativen unbedingt ebenfalls lernen. Für mich sind weniger bat oder eza hilfreich als vielmehr Alternativen wie fd (als find-Ersatz) oder sd (als sed-Ersatz), die wirklich Zeit sparen

• Wenn man sich in viele Netzwerke und bei Kunden auf Hunderte Server einloggen muss, lohnt sich der Einsatz eigener Spezialtools fast gar nicht. In 90 % der Umgebungen sind solche Tools ohnehin nicht installiert. Ich ergänze in ansible-config nur ein paar Dinge und verteile sie automatisiert, halte die Liste aber sehr knapp. 95 % der Systeme, die ich verwalte, sind Debian oder Ubuntu, sodass die Basis fast identisch ist, und ich füge nur Dinge wie ack, etckeeper, vim, pv und dstat hinzu

  • Der entscheidende Punkt ist hier „Server“. Viele leicht verbesserten Programme für Sysadmins sind womöglich nicht besonders wertvoll, aber einige sind echte Dev-Tools für Entwicklungsumgebungen und müssen daher nur auf den wenigen Maschinen installiert werden, auf denen man programmiert. ripgrep (ein hervorragendes rekursives grep), jq (ein JSON-Prozessor, für den es im Unix-Standardwerkzeugkasten keine Alternative gibt) und hyperfine (Benchmarking) sind typische Beispiele

  • Da ich zwischen Windows und Linux arbeite, sind starke plattformübergreifende Tools wie ripgrep wirklich praktisch

  • Ich frage mich, ob es tatsächlich ein Tool oder eine SSH-Erweiterung gibt, die solche Apps automatisch in eine entfernte SSH-Session mitbringt. Wenn es kleine Binärdateien sind, könnte man sie in einen temp-Ordner kopieren und benutzen, und auch die Automatisierung dieses Vorgangs ist vorstellbar. Die Frage ist nur, ob das sicherheitstechnisch unproblematisch ist und keine zusätzlichen Rechte erfordert. Letztlich hängt alles an der Portabilität dieser Apps. Ich denke darüber selbst oft nach

  • emacs funktioniert fast wie ein eigenes Betriebssystem, sodass man auf jedem System eine vertraute Umgebung bekommt. Daher kommt auch der Spruch „GNU is my operating system, linux is just the current kernel“. Aus Sicht eines erfahrenen Admins ist das auch der Grund, warum ich jemandem, der Linux neu lernt, empfehle, mit dem Befehl info anzufangen und dieses Handbuch vollständig zu lesen. Damit kann man den meisten Administratoren weit voraus sein. Wenn man weiß, welche eingebauten Tools es gibt, und die Manpages gut sind, wird das Schreiben von Skripten leicht, und genau das ist der Kern der Linux-Philosophie. Früher gab es Zeiten, in denen nicht einmal nano da war und nur vi verfügbar war, heute ist es dank CI/CD-Automatisierung einfach, auch einen TUI-Editor hinzuzufügen

  • Mit solchen Kommentaren nach dem Muster „Ich bin halt so ein Typ Mensch“ kann ich wenig anfangen. Viele Leute interessiert es gar nicht, dass man Custom-Tools nicht auf entfernten Systemen installiert. Es geht darum, selbst auf dem lokalen Rechner solche Tools zu installieren und die Vorteile mitzunehmen

• Ich fände es gut, wenn diese Tabelle eine zusätzliche Spalte hätte: „Welches Problem löst dieses Tool?“ Und Dinge wie „in Rust implementiert“ halte ich nicht für ein Unterscheidungsmerkmal

  • Ich hatte einmal in einem Firmenmeeting einen absurden Moment, als jemand „in Go geschrieben“ als Unterscheidungsmerkmal verkauft hat. #facepalm

  • Viele Einträge in der Tabelle nennen tatsächlich konkrete Probleme wie „syntax highlight“, „ncurses interface“ oder „more intuitive“. Aber Formulierungen wie „in Rust geschrieben“, „modern“ oder „better“ helfen meiner Meinung nach nicht weiter

  • Das primäre Ziel der meisten Tools ist eine bessere UX

  • Auch eine Nicht-GPL-Lizenz ist kein Unterscheidungsmerkmal

  • Schön ist auch, dass viele dieser Tools unter Windows nutzbar sind

• Solche Tool-Listen machen immer Spaß. Die meisten Leute können wahrscheinlich ein oder zwei Werkzeuge daraus gut gebrauchen. Für mich sind ripgrep und jq unverzichtbar. ripgrep ist der beste grep-Ersatz, der einem Drop-in am nächsten kommt, und jq löst ein Problem, das ich wirklich hatte. lsd und dust würde ich gern ebenfalls ausprobieren. Auch wenn ich ein neues Tool nicht direkt selbst brauche, bin ich dankbar, dass Leute ihre Zeit in so etwas investieren. Dass damit der Werkzeugkasten der ganzen Community Stück für Stück besser wird, ist großartig

  • Ich würde wahrscheinlich zuerst fzf wählen. Ich mag es deutlich lieber als rg oder jq

  • ripgrep verhält sich anders als grep und ist daher in der Praxis kein echter Drop-in-Ersatz. Es ist ein großartiges Programm, aber eben nicht vollständig kompatibel

  • Linux-Admins wie ich haben alle ihre eigene streng kuratierte Liste solcher Tools. Ich habe mir eher ein GPL-basiertes Stack zusammengestellt, und dieses Format von ikrima.dev gefällt mir besonders gut

• Ich lebe im Terminal, aber diese Tools lösen entweder keine Probleme, die ich gerade habe, oder sie sind auf meinem System nicht installiert, und trotzdem haben sie irgendwie Zehntausende GitHub-Stars. Ich verstehe ehrlich nicht, warum sie so populär sind

  • Jemand, der in seiner Musikbibliothek lebt, kann auch ratlos sein, wenn Künstler Millionen Platten verkaufen, die nicht seinem Geschmack entsprechen oder in seiner Bibliothek fehlen. Spaß beiseite: Ich würde gern fragen, ob du solche Tools selbst schon einmal ausprobiert hast. Früher habe ich auch nicht verstanden, warum Leute vim benutzen, aber nachdem ich es richtig verwendet hatte, wusste ich warum

  • Du benutzt kein fzf? Dann muss das Leben im Terminal wirklich anstrengend sein. Statt Dinge direkt auszuführen, kann man mit den Shell-Plugins per Ctrl+R die bash_history und per Ctrl+T die Dateien im aktuellen Verzeichnis fuzzy durchsuchen, und das ist extrem nützlich

  • Das Unix-Kernwerkzeugset ist so robust, dass man auch nur mit den Standardtools gut arbeiten kann. Viele Ersatztools sind zwar besser, aber nicht zwingend notwendig, und die meisten sind eben standardmäßig nicht installiert

  • Nur aus Neugier: Gibt es mit den eingebauten Unix-Tools eine elegante Möglichkeit, rekursiv nach nur einer bestimmten Erweiterung zu grep-en und dabei versteckte Dateien (.git usw.) zu ignorieren? Ein Befehl wie rg -g '*.foo' bar ist für mich zum Beispiel ein Muster, das ich ständig benutze. Dasselbe gilt für die Suche mit fd nach Dateien passend zu einem Regex oder Glob. Mit Bordmitteln habe ich dafür keine saubere Lösung gefunden

  • Ich frage mich, welche Arbeit man den ganzen Tag im Terminal macht, wenn man überhaupt keinen Wunsch hat, das Toolset zu verbessern. Schreibt man am Ende vielleicht alle Tools selbst?

• Im Dark Mode ist der Linktext kaum sichtbar, deshalb ist das Lesen anstrengend

• Ich finde, nur jq löst wirklich ein echtes Problem, das man mit den bestehenden Tools nicht vernünftig lösen kann. Der Rest sind meist Unterschiede bei Präferenz, Performance, Highlighting oder eben eine Rust-Implementierung

• Ich wünschte, ein Team würde einmal eine konsistente Tool-Suite herausbringen, bei der Parameter, Farben, Tabellen usw. durchgängig einheitlich gestaltet sind

• Lange Zeit habe ich htop statt top benutzt, weil es zugänglicher wirkte, aber dass htop standardmäßig keine Kernel-Threads zeigt, wurde mir bei der Ursachenanalyse von Störungen zum Hindernis. Seitdem bin ich wieder zu top zurückgekehrt, weil es alle Informationen zeigt und verlässlicher ist. UIs wie bei htop oder btop wirken auf mich eher wie Show als wie echter Nutzen

• Dieser Artikel ist von 2023. Viele dieser „modernen Tools“ wurden vielleicht inzwischen schon aktualisiert, und neue, trendigere Sachen könnten dazugekommen sein

  • Gerade weil es so viele Tools gibt, ist es schon wertvoll genug, wenn nur die Hälfte davon überlebt

  • Meine Erfahrung ist eher das Gegenteil. Die meisten dieser Tools sind letztlich nur eine weitere „Neuerfindung“ der enorm mächtigen GNU-Standardtools, wenn man nur bereit ist, Zeit zu investieren und sie richtig zu lernen