Eza: ein moderner und gepflegter ls-Ersatz

 (github.com/eza-community)
3 Punkte von GN⁺ 2024-07-23 | 1 Kommentare | Auf WhatsApp teilen
  • eza ist ein modernes CLI-Tool als Ersatz für den Unix/Linux-Befehl ls zum Auflisten von Dateien und soll mehr Funktionen sowie bessere Standardeinstellungen bieten
  • Es unterscheidet Dateitypen und Metadaten per Farbe, erkennt symbolische Links, erweiterte Attribute und Git-Informationen und wird als kleine, schnelle Einzel-Binary bereitgestellt
  • Gegenüber dem bisherigen exa wurden Korrekturen für den Grid Bug, Hyperlinks, Details zu Mount Points, SELinux-Kontexte, Git-Repository-Status, menschenlesbare relative Datumsangaben, Sicherheitskorrekturen, bright-Terminalfarben und die Konfiguration über theme.yml hinzugefügt
  • Es lässt sich unter Windows, macOS und Linux installieren; in Nix-flake-Umgebungen kann es mit nix run github:eza-community/eza gebaut und ausgeführt werden
  • Das Optionsschema ist nicht vollständig identisch mit ls; über Anzeige-, Filter-, Long-Listing- und Theme-Einstellungen lässt sich die Ausgabe von Dateilisten fein anpassen

Die ls-Ersatz-Erfahrung, die eza bietet

  • eza ist eine moderne Alternative zum alten Dateilisten-Befehl ls, der in Unix- und Linux-Betriebssystemen enthalten ist
  • Das grundlegende Ziel ist, eine funktionsreichere und benutzerfreundlichere Version als ls bereitzustellen
  • Dateitypen und Metadaten werden farblich unterschieden
  • Symbolische Links, erweiterte Attribute und Git-Informationen werden erkannt
  • Es ist klein, schnell und wird als Einzel-Binary bereitgestellt

Zusätzliche Funktionen gegenüber exa

  • eza enthält zahlreiche Funktionen, die es in exa nicht gab
    • Korrektur von „The Grid Bug“, der in exa 2021 eingeführt wurde
    • Unterstützung für Hyperlinks
    • Ausgabe von Details zu Mount Points
    • Ausgabe von SELinux-Kontexten
    • Ausgabe des Git-Repository-Status
    • Menschenlesbare relative Datumsangaben
    • Mehrere Sicherheitskorrekturen
    • Unterstützung für bright-Terminalfarben
    • Kleinere Bugfixes und Änderungen
    • Konfigurationsdatei theme.yml zum Anpassen von Farben und Icons

Ausführung und Installation

  • In Umgebungen mit Nix-flake-Unterstützung kann eza mit folgendem Befehl ausprobiert werden
    • nix run github:eza-community/eza
  • Nix baut eza und führt es anschließend aus
  • Um Argumente zu übergeben, werden die Optionen wie folgt nach -- angehängt
    • nix run github:eza-community/eza -- -ol
  • eza ist für Windows, macOS und Linux verfügbar
  • Installationsanleitungen nach Plattform und Distribution finden sich in INSTALL.md

Aufbau der Kommandozeilenoptionen

  • Die Optionen von eza sind denen von ls sehr ähnlich, aber nicht vollständig identisch

  • Anzeigeoptionen

    • -1, --oneline: ein Eintrag pro Zeile
    • -G, --grid: Einträge als Grid anzeigen; dies ist der Standard
    • -l, --long: erweiterte Details und Attribute anzeigen
    • -R, --recurse: Verzeichnisse rekursiv durchsuchen
    • -T, --tree: Verzeichnisse rekursiv als Baum anzeigen
    • -F, --classify=(when): Typindikator neben Dateinamen ausgeben
    • --colour=(when), --color=(when): festlegen, wann Terminalfarben verwendet werden
    • --icons=(when): festlegen, wann Icons angezeigt werden
    • --hyperlink=(when): festlegen, wann Einträge als Hyperlinks angezeigt werden
    • --absolute=(mode): festlegen, wie absolute Pfade von Einträgen angezeigt werden

  • Filteroptionen

    • -a, --all: versteckte Dateien und Dotfiles anzeigen
    • -d, --treat-dirs-as-files: Verzeichnisse wie normale Dateien auflisten
    • -L, --level=(depth): Rekursionstiefe begrenzen
    • -s, --sort=(field): Sortierfeld festlegen
    • --group-directories-first: Verzeichnisse zuerst anzeigen
    • --group-directories-last: Verzeichnisse zuletzt anzeigen
    • -D, --only-dirs: nur Verzeichnisse anzeigen
    • -f, --only-files: nur Dateien anzeigen
    • --git-ignore: Dateien aus .gitignore ignorieren
    • -I, --ignore-glob=(globs): Dateien ignorieren, die zu durch Pipes getrennten Glob-Mustern passen
    • Wenn --all zweimal übergeben wird, werden auch die Verzeichnisse . und .. angezeigt

Lange Listen und Git-bezogene Informationen

  • Bei Verwendung von --long oder -l stehen Long-Listing-Optionen zur Verfügung
  • Es werden Optionen für Dateigröße und Berechtigungen bereitgestellt
    • -b, --binary: Dateigröße mit binären Präfixen anzeigen
    • -B, --bytes: Dateigröße ohne Präfix in Byte anzeigen
    • -o, --octal-permissions: Berechtigungen im Oktalformat anzeigen
    • --no-permissions, --no-filesize, --no-user, --no-time: Ausgabe des jeweiligen Felds unterdrücken
  • Es werden Optionen für Dateisystem und Metadaten bereitgestellt
    • -H, --links: Anzahl der Hardlinks anzeigen
    • -i, --inode: inode-Nummer anzeigen
    • -M, --mounts: Mount-Details anzeigen, nur unter Linux und macOS verfügbar
    • -Z, --context: Sicherheitskontext anzeigen
    • -@, --extended: erweiterte Attribute und Größe anzeigen
    • --total-size: Größe rekursiver Verzeichnisse anzeigen
  • Auch Git-bezogene Ausgaben werden unterstützt
    • --git: Git-Status jeder getrackten oder ignorierten Datei anzeigen
    • --git-repos: Git-Status jedes getrackten Verzeichnisses anzeigen
    • --git-repos-no-status: nur anzeigen, ob ein Verzeichnis ein Git-Repository ist; schneller
    • --no-git: --git, --git-repos und --git-repos-no-status immer ignorieren und die Ausgabe des Git-Status unterdrücken
  • Als Zeitformat werden default, iso, long-iso, full-iso, relative oder benutzerdefinierte Formate in der Form +<FORMAT> unterstützt
    • Beispiel: +%Y-%m-%d %H:%M gibt im Format 2023-09-30 13:00 aus
    • Details zu Format-Strings stehen in der Manual Page eza(1) und in der chrono documentation
  • Die Manual Pages sind im man-Verzeichnis des Repositorys einsehbar und seit Version [0.18.13] - 2024-04-25 auch im Terminal über man eza verfügbar

Theme-Anpassung

  • eza hat kürzlich Unterstützung für die Datei theme.yml hinzugefügt
  • In theme.yml können die bestehenden Theme-Optionen festgelegt werden, die bislang über die Umgebungsvariablen LS_COLORS und EXA_COLORS verfügbar waren
  • Außerdem gibt es Optionen, um je nach Dateityp und Erweiterung unterschiedliche Icons festzulegen
  • Wenn die bestehenden Umgebungsvariablen gesetzt sind, funktionieren sie aus Gründen der Abwärtskompatibilität weiterhin und haben Vorrang
  • Vorgefertigte Themes können im offiziellen Repository eza-themes angesehen oder dort beigetragen werden
  • Eine Beispiel-Theme-Datei befindet sich in docs/theme.yml
  • Die Theme-Datei wird in dem Verzeichnis abgelegt, das über die Umgebungsvariable EZA_CONFIG_DIR angegeben ist, oder standardmäßig unter $XDG_CONFIG_HOME/eza gesucht
  • Weitere Details stehen in eza_colors-explanation.5.md und docs/theme.yml

Mitwirken

  • Wer zu eza beitragen möchte, muss den code of conduct befolgen
  • Informationen zur praktischen Beteiligung an der Entwicklung stehen in CONTRIBUTING.md

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-07-23
Hacker-News-Kommentare

  • In Verzeichnislisten sind menschenlesbare Datumsangaben besonders störend.
    Wenn ich etwas suche, das ich gestern gegen 11 Uhr morgens in einen Ordner kopiert habe, hilft es nicht, wenn überall nur „1 day ago“ steht. Ich brauche Datum und Uhrzeit, und bei Foren wie HN genauso: erst das genaue Datum/die genaue Uhrzeit anzeigen und bei Bedarf zusätzlich „7 hours ago“ anhängen.
    Ich verstehe nicht, warum man absichtlich Informationen weglässt, und frage mich, ob das ein Ergebnis von endlosem Scrollen und ähnlichen Mustern ist.

    • Stimme zu. GitHub zeigt bei Commits auch Dinge wie „foo.cpp modified last year“ an, und wenn es keine Möglichkeit gibt, zusätzliche Datums-/Zeitangaben zu sehen, ergibt das überhaupt keinen Sinn.
    • Ich frage mich, ob Websites dafür HTML-Tags verwenden könnten. Selbst wenn man ein menschenlesbares Format wählt, könnte man die tatsächliche Zeit beibehalten, sodass Erweiterungen sie ersetzen oder überlagern können.
      Ich versuche immer, das beim Schreiben von HTML zu verwenden.
      (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ti...)
    • Das ist wirklich eine erstaunliche Anti-Funktion. Auch der Zeitpunkt des Umschaltens ist unklar. Wann wird aus „1 day ago“ eigentlich „2 days ago“? Bei Google offenbar erst nach 48 Stunden, sodass man nach 47 Stunden noch „1 day ago“ sieht und fälschlich denkt, es sei gestern passiert.
      Selbst wenn man sich ein bestimmtes Datum als den Tag nach dem Geburtstag eines Freundes merkt und etwas sucht, muss man bei einer Anzeige wie nur „three months ago“ Material aus einem ganzen Monat durchforsten.
    • Das ist eine Einstellung, man kann es also auf das gewünschte Datumsformat umstellen.
    • Ich mag diese Art nicht. Sie scheint bei Web-2.0-Startups begonnen zu haben oder sich damals über Webapps und soziale Webapps von Firmen wie Google verbreitet zu haben.
      Man sollte zuerst die genaue Zeit angeben und auf Wunsch zusätzlich „vor ein paar Tagen“ anzeigen.

  • Es gibt auch lsd, aber ich bevorzuge immer noch eza.
    Für Interessierte: Es gibt heute moderne Kommandozeilen-Tools, die ältere Werkzeuge ersetzen. bat ist cat mit Syntax-Highlighting, difftastic ein besseres diff, gdu ist ncdu für SSDs, zoxide ein modernes cd, fd eine Alternative zu find, rg ist ripgrep, fzf ein Fuzzy-Finder, jless ein JSON-Viewer mit einklappbaren Bereichen per Maus, dra lädt Release-Assets herunter und installiert sie, lazygit ist ein Git-TUI, lazydocker ein Docker-TUI, yazi ein Dateimanager mit Bildvorschau, zellij ein besseres tmux/screen, und starship ist ein Tool zur Prompt-Konfiguration für mehrere Shells.

    • Wenn ich noch vier häufig genutzte Tools ergänzen darf: task ist eine Alternative zu Makefiles, hyperfine ein Benchmark-Tool, vegeta ein Lasttest-Tool und sd ein besseres und intuitiveres sed.
      Außerdem gibt es ein JSON-Trio: jq ist der bekannte JSON-Prozessor, jc wandelt die Ausgabe vieler CLI-Tools in JSON um und gron macht JSON leichter mit grep durchsuchbar.
    • Man sollte beachten, dass fd und rg standardmäßig Einträge in .gitignore ignorieren. Wenn man sie für bloße find-Ersatztools hält, kann das überraschend sein. Eine entsprechende Diskussion steht in [0].
      Wenn man solche Tools empfiehlt, sollte man das deutlich dazusagen. Ohne die Dokumentation zu lesen, übersieht man das leicht. Ich persönlich wünschte, diese alternativen Coreutils-artigen Tools würden ihre Standardwerte näher an den Originalwerkzeugen halten. Wenn man sie als „einfache, schnelle und benutzerfreundliche Alternative zu find“ bewirbt, sollte man die Original-Defaults respektieren, um neue Nutzer nicht zu überraschen. Aliasse gibt es schließlich; ich halte alias fd='fd --ignore' in ~/.${SHELL##*/}rc für besser als alias fd='fd --no-ignore'.
      Als Tipp: Wenn man die Version ohne angewendeten Alias nutzen will, kann man \command verwenden. Ich nutze zum Beispiel alias grep='grep --color=always --no-messages --binary-files=without-match, aber die Farboption verändert die Zeichendarstellung, was bei Pipes zu curl Fehler verursachen kann. Das passiert nicht in jeder Pipe, ist beim ersten Mal aber ziemlich irritierend. Mit echo "Hello world" | \grep --color=always "Hello" | hexdump und danach !!:s^always^never kann man das prüfen.
      [0] https://github.com/sharkdp/fd/issues/612
    • Auch in diesem Link gibt es eine große Liste zusätzlicher Tools, von denen ich noch nie gehört habe, die aber interessant wirken.
      https://github.com/ibraheemdev/modern-unix
    • Ich finde es gut, dass die meisten dieser Tools in Rust geschrieben sind.
    • Ich hatte nicht den Eindruck, dass zellij besser als screen ist. Tabs/Fenster werden nicht ordentlich nummeriert, sodass man zum direkten Wechseln selbst zählen muss, und das ist für mich schwer hinnehmbar.

  • GNU ls wird gepflegt. Es gab Commits, die die Datei ls.c betreffen, auch am 2024-06-24 und 2024-06-27, also vor weniger als einem Monat.
    Die Mailingliste von GNU Coreutils ist ebenfalls ziemlich aktiv. Das Projekt scheint „maintained“ im Sinn von „aktiv weiterentwickelt“ zu verwenden.

    • Gemeint ist hier wohl exa, von dem eza ein Fork ist. exa wurde ungefähr ein Jahr lang nicht gepflegt, bis die einzige Person mit Schreibrechten auf das Repository es offiziell als deprecated markiert hat.
      Inzwischen ist seit dem Fork einige Zeit vergangen, sodass nicht mehr jeder exa kennt, und die Absicht dieser Formulierung ist dadurch viel unklarer geworden. Da es ähnliche Reaktionen gibt, ist es vielleicht Zeit, den Wortlaut zu aktualisieren.
    • Mit „maintained“ ist hier nicht gemeint, dass ls nicht gepflegt werde, sondern dass es sich um einen gepflegten Ersatz handelt, nämlich einen Fork des nicht mehr gepflegten ls-Ersatzes exa.

  • Nachdem ich auf die fish-Shell umgestiegen bin, ist meine ls-Nutzung um 100 % gesunken. Der eingebaute Befehl Alt + l zeigt den Verzeichnisinhalt an, was sehr nützlich ist, und auch der Shell-Verlauf wird dadurch sauberer

    • Auch in Bash kann man Befehle wie ls zur Umgebungsvariable HISTIGNORE hinzufügen, um die History sauberer zu halten: https://superuser.com/questions/232885/can-you-share-wisdom-...
    • Guter Tipp. Dass ich in fish den Großteil meiner ls-Nutzung eliminiert habe, lag an einer Konfiguration, die beim Verzeichniswechsel automatisch ls ausführt
      function ls_on_cd --on-variable PWD
      ls
      end
    • Auch Bash-Nutzer können solche Tastenkürzel binden. Ich habe die Home-Row-Tasten der rechten Hand an Funktionen wie __bash_ctrl_n() gebunden und es so eingerichtet, dass verschiedene Tools in meinen Dotfiles diese Funktionen überschreiben. Wenn zum Beispiel Git installiert ist, ist __bash_ctrl_e() so konfiguriert, dass git status und git log ausgeführt werden
    • In meiner Umgebung scheint diese Funktion wohl eza auszuführen, vermutlich weil ich ls als Alias auf eza gesetzt habe. Am Ende wird also einfach ls ausgeführt
    • Ich habe das in meine Startdatei aufgenommen, nachdem mir klar wurde, dass die meisten ls-Aufrufe direkt nach cd kommen. Jetzt führen fast alle cd-Befehle automatisch ls aus
      In Bash ruft die Funktion cd() builtin cd "$@" && ls -l auf, und in fish lasse ich nach builtin cd $argv bei ausbleibendem Fehler und wenn nicht ins Home-Verzeichnis gewechselt wurde dir ausführen

  • Terminal-Tools, die generell Farben erzwingen, um Dateitypen oder Attribute zu unterscheiden, finde ich unangenehm. Auch das ls vieler Distributionen ist oft so konfiguriert, aber solche Einstellungen entferne ich und verwende die Standardwerte
    Ich nutze einen terminalfreundlichen Hintergrund, aber solche Farbschemata kollidieren immer mit dem Hintergrund oder enthalten schwer lesbare Farben. Für die Ausgabe von ls oder seinen Alternativen brauche ich keine Farben; das, was ls -AFC liefert, reicht völlig aus

    • Es wäre viel weniger problematisch, wenn Tools statt beliebiger „256 color“- oder „RGB“-Farbmodi das Base16 Framework[0] verwenden würden. Dann würde die Ausgabe in vom Terminal definierten Farben erscheinen, von denen man annehmen kann, dass sie lesbar sind
      [0] https://github.com/chriskempson/base16
      [1] https://tinted-theming.github.io/base16-gallery/
    • Ich bin genau das Gegenteil und verlasse mich stark auf farbige Ausgabe
      Trotzdem sollte es eine Lösung geben, und dazu reicht es, irgendeinen Wert für $NO_COLOR zu setzen. https://no-color.org
      Bei Tools, die diese Umgebungsvariable nicht prüfen und respektieren, ist ein Bugreport absolut gerechtfertigt
    • https://no-color.org
    • Man kann vivid[1] verwenden, ein zum Terminalhintergrund passendes Theme auswählen und die erzeugte Variable LS_COLORS in die Shell laden
      [1]: https://github.com/sharkdp/vivid/

  • Es ist seltsam, dass im README nicht steht, dass eza ein Fork von exa ist

    • Mit „eza features not in exa“ wird die Existenz zwar erwähnt, aber es fehlen Link und Kontext

  • Ich frage mich, warum so viele neue Versionen von GNU-Utilities unter der MIT-Lizenz erscheinen. Davon scheint es ziemlich viele zu geben

    • Rust-Nutzer neigen generell dazu, ihren Code unter permissiven Lizenzen zu veröffentlichen. Ich weiß nicht, ob es dazu leicht zugängliche Statistiken gibt, aber im Rust-Paket-Repository crates.io ist fast alles MIT oder Apache-2.0, und bei populären Bibliotheken ist das definitiv so
    • Das GNU-Projekt hat ls nicht erfunden. GNU coreutils einschließlich ls waren ursprünglich ebenfalls neue Versionen ehemals proprietärer AT&T-Utilities oder BSD-lizenzierter Utilities
    • In diesem Zusammenhang ist https://github.com/uutils/coreutils eine „plattformübergreifende Rust-Neuschreibung der GNU coreutils“

  • Warum braucht ein ls-Ersatz Kerberos und SSH?
    ldd /usr/bin/eza zeigt, dass es gegen ziemlich viele Bibliotheken gelinkt ist, darunter libgit2, libgssapi_krb5, libmbedtls, libssh2, libkrb5, libcrypto, libzstd

    • Das sind für etwas, das ls ersetzen soll, wirklich zu viele Abhängigkeiten

  • Auf einer QWERTY-Tastatur ist eza als Dreierkombination ziemlich furchtbar. Einer der Vorteile von ls ist, dass es sich extrem schnell tippen lässt
    Man kann zwar einen Alias anlegen, aber das fühlt sich aus Gründen wie Kompatibilität irgendwie seltsam an

    • Ich setze seit etwa 2015 eza, davor exa, per Alias auf ls, ll und lll, und hatte nie Kompatibilitätsprobleme
      Ich habe auch sl installiert, um mich selbst darauf zu trainieren, es nicht falsch zu tippen
    • Aus Sicht eines Dvorak-Nutzers wirkt eza wie eine Verbesserung. In Dvorak ist ls nach QWERTY-Mapping p-, also beides Tasten für den rechten kleinen Finger
    • Kannst du genauer erklären, warum sich ein Alias seltsam anfühlt?
    • Du kannst einen Alias auf jeden beliebigen Namen setzen
    • In solchen Momenten zeigt die AZERTY-Tastatur ihre Stärken

  • Wer benutzt denn überhaupt ls? Man drückt einfach Tab-Autovervollständigung, bis die gewünschte Datei erscheint
    Spaß beiseite, ich frage mich, warum behauptet wird, dass ls nicht mehr gepflegt wird

    • Gemeint ist wohl nicht ls, sondern exa[0], das nicht mehr gepflegt wird
      [0]https://github.com/ogham/exa
    • Aus irgendeinem Grund scheint es zum Standard geworden zu sein zu glauben, dass Software im Grunde veraltet ist, wenn sie nicht regelmäßig aktualisiert wird
    • Natürlich wird ls weiterhin als Teil der Shell oder von coreutils gepflegt
      eza ist allerdings ein Fork von exa, und soweit ich weiß, wird exa nicht mehr gepflegt
    • Hier werden absichtlich „maintained“ und „actively developed“ verwechselt, damit es so aussieht, als würde das bestehende Tool nicht gepflegt