Eza : un remplaçant moderne et maintenu de `ls`

 (github.com/eza-community)
3 points par GN⁺ 2024-07-23 | 1 commentaires | Partager sur WhatsApp
  • eza est un outil CLI moderne qui remplace la commande de listage de fichiers ls sur Unix/Linux, avec pour objectif d’offrir davantage de fonctionnalités et de meilleurs réglages par défaut
  • Il distingue les types de fichiers et les métadonnées par couleurs, reconnaît les liens symboliques, les attributs étendus et les informations Git, et se présente sous la forme d’un binaire unique petit et rapide
  • Par rapport à exa, il ajoute la correction du Grid Bug, les hyperliens, les détails des points de montage, les contextes SELinux, l’état des dépôts Git, des dates relatives lisibles, des correctifs de sécurité, les couleurs de terminal bright et la configuration theme.yml
  • Il peut être installé sur Windows, macOS et Linux, et dans un environnement Nix flake, il peut être compilé puis exécuté avec nix run github:eza-community/eza
  • Son système d’options n’est pas totalement identique à celui de ls, mais il permet d’ajuster finement l’affichage du listage de fichiers via les options d’affichage, de filtrage, de liste longue et de thème

L’expérience de remplacement de ls proposée par eza

  • eza est une alternative moderne à ls, l’ancienne commande de listage de fichiers incluse dans les systèmes Unix et Linux
  • Son objectif principal est de proposer une version plus riche en fonctionnalités et plus conviviale que ls
  • Il distingue les types de fichiers et les métadonnées par des couleurs
  • Il reconnaît les liens symboliques, les attributs étendus et les informations Git
  • Il est petit, rapide et distribué sous forme de binaire unique

Fonctionnalités ajoutées par rapport à exa

  • eza inclut de nombreuses fonctionnalités absentes de exa
    • correction du « The Grid Bug » introduit dans exa 2021
    • prise en charge des hyperliens
    • affichage des détails des points de montage
    • affichage des contextes SELinux
    • affichage de l’état des dépôts Git
    • dates relatives lisibles par un humain
    • plusieurs correctifs de sécurité
    • prise en charge des couleurs de terminal bright
    • correctifs de bugs mineurs et autres changements
    • fichier de configuration theme.yml pour personnaliser les couleurs et les icônes

Exécution et installation

  • Dans un environnement prenant en charge Nix flake, vous pouvez essayer eza avec la commande suivante
    • nix run github:eza-community/eza
  • Nix compile ensuite eza avant de l’exécuter
  • Pour passer des arguments, ajoutez les options après --, comme ceci
    • nix run github:eza-community/eza -- -ol
  • eza est disponible sur Windows, macOS et Linux
  • Les méthodes d’installation selon la plateforme et la distribution sont détaillées dans INSTALL.md

Organisation des options en ligne de commande

  • Les options d’eza sont très proches de celles de ls, sans être totalement identiques

  • Options d’affichage

    • -1, --oneline : affiche un élément par ligne
    • -G, --grid : affiche les éléments en grille, c’est l’option par défaut
    • -l, --long : affiche les détails étendus et les attributs
    • -R, --recurse : parcours récursif des répertoires
    • -T, --tree : affiche récursivement les répertoires sous forme d’arborescence
    • -F, --classify=(when) : affiche un indicateur de type à côté du nom du fichier
    • --colour=(when), --color=(when) : définit quand utiliser les couleurs du terminal
    • --icons=(when) : définit quand afficher les icônes
    • --hyperlink=(when) : définit quand afficher les éléments comme hyperliens
    • --absolute=(mode) : définit la manière d’afficher le chemin absolu des éléments

  • Options de filtrage

    • -a, --all : affiche les fichiers cachés et les dotfiles
    • -d, --treat-dirs-as-files : liste les répertoires comme des fichiers ordinaires
    • -L, --level=(depth) : limite la profondeur de récursion
    • -s, --sort=(field) : définit le champ de tri
    • --group-directories-first : affiche les répertoires en premier
    • --group-directories-last : affiche les répertoires en dernier
    • -D, --only-dirs : affiche uniquement les répertoires
    • -f, --only-files : affiche uniquement les fichiers
    • --git-ignore : ignore les fichiers présents dans .gitignore
    • -I, --ignore-glob=(globs) : ignore les fichiers correspondant à des motifs glob séparés par des barres verticales
    • passer --all deux fois affiche aussi les répertoires . et ..

Liste longue et informations liées à Git

  • Les options de liste longue sont disponibles avec --long ou -l
  • Des options sont proposées pour la taille des fichiers et les permissions
    • -b, --binary : affiche la taille des fichiers avec des préfixes binaires
    • -B, --bytes : affiche la taille des fichiers en octets sans préfixe
    • -o, --octal-permissions : affiche les permissions au format octal
    • --no-permissions, --no-filesize, --no-user, --no-time : supprime l’affichage de chaque champ correspondant
  • Des options sont proposées pour le système de fichiers et les métadonnées
    • -H, --links : affiche le nombre de liens physiques
    • -i, --inode : affiche le numéro d’inode
    • -M, --mounts : affiche les détails de montage, disponible uniquement sur Linux et macOS
    • -Z, --context : affiche le contexte de sécurité
    • -@, --extended : affiche les attributs étendus et leur taille
    • --total-size : affiche la taille récursive des répertoires
  • L’affichage d’informations Git est également pris en charge
    • --git : affiche l’état Git de chaque fichier suivi ou ignoré
    • --git-repos : affiche l’état Git de chaque répertoire suivi
    • --git-repos-no-status : indique seulement si un répertoire est un dépôt Git, avec de meilleures performances
    • --no-git : ignore toujours --git, --git-repos, --git-repos-no-status et supprime l’affichage de l’état Git
  • Les formats de date pris en charge sont default, iso, long-iso, full-iso, relative, ou un format personnalisé de la forme +<FORMAT>
    • exemple : +%Y-%m-%d %H:%M affiche au format 2023-09-30 13:00
    • pour plus de détails sur les chaînes de format, consultez la page de manuel eza(1) et la documentation de chrono
  • Les pages de manuel sont disponibles dans le répertoire man du dépôt et, depuis la version [0.18.13] - 2024-04-25, aussi via man eza dans le terminal

Personnalisation du thème

  • eza a récemment ajouté la prise en charge du fichier theme.yml
  • Dans theme.yml, vous pouvez définir les options de thème auparavant disponibles via les variables d’environnement LS_COLORS et EXA_COLORS
  • Il propose aussi des options permettant d’assigner des icônes différentes selon le type de fichier et l’extension
  • Si les variables d’environnement existantes sont définies, elles continuent de fonctionner pour assurer la rétrocompatibilité et restent prioritaires
  • Des thèmes prêts à l’emploi sont disponibles dans le dépôt officiel eza-themes, où vous pouvez aussi contribuer
  • Un fichier de thème d’exemple est disponible dans docs/theme.yml
  • Le fichier de thème doit être placé dans le répertoire indiqué par la variable d’environnement EZA_CONFIG_DIR, ou sera recherché par défaut dans $XDG_CONFIG_HOME/eza
  • Pour plus de détails, consultez eza_colors-explanation.5.md et docs/theme.yml

Contribution

  • Pour contribuer à eza, vous devez suivre le code of conduct
  • Les informations concrètes pour participer au développement se trouvent dans CONTRIBUTING.md

À lire aussi

1 commentaires

 
GN⁺ 2024-07-23
Commentaires Hacker News

  • Dans les listes de répertoires, les dates lisibles par un humain sont particulièrement agaçantes
    Quand je cherche quelque chose que j’ai copié dans un dossier hier vers 11 h du matin et que tout s’affiche comme « 1 day ago », ça ne m’aide pas. J’ai besoin de la date et de l’heure ; les forums comme HN devraient aussi afficher la date/heure exacte, puis ajouter « 7 hours ago » à côté si nécessaire.
    Je ne comprends pas pourquoi on retire volontairement de l’information, et je me demande si c’est une conséquence de tendances comme le défilement infini.

    • D’accord. GitHub affiche aussi des choses comme « foo.cpp modified last year » pour les commits, et si l’on n’a aucun moyen de voir les informations de date/heure supplémentaires, ça n’a aucun sens.
    • Je me dis que les sites pourraient utiliser une balise HTML pour ça. Même s’ils choisissent un format lisible par un humain, s’ils conservent l’heure réelle, une extension pourrait la remplacer ou la superposer.
      J’essaie de toujours le faire quand j’écris du HTML.
      (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ti...)
    • C’est vraiment une anti-fonctionnalité surprenante. Le moment où ça change est aussi ambigu. Quand « 1 day ago » devient-il « 2 days ago » ? Chez Google, c’est au bout de 48 heures, donc si vous regardez au bout de 47 heures, ça affiche « 1 day ago » et vous fait croire que c’est arrivé hier.
      Même si vous vous souvenez qu’une date précise était le lendemain de l’anniversaire d’un ami et que vous essayez de retrouver un élément, si l’affichage se limite à « three months ago », vous devez fouiller un mois de données.
    • C’est un réglage, on peut donc le changer pour le format de date souhaité.
    • Je déteste cette approche. Elle a probablement commencé avec les startups Web 2.0, ou s’est répandue à cette époque via les applis web / applis sociales de sociétés comme Google.
      Il suffit de fournir d’abord l’heure détaillée, et d’ajouter aussi l’indication « il y a quelques jours » si on le souhaite.

  • Il y a aussi lsd, mais je préfère toujours eza
    Pour ceux que ça intéresse, voici des outils modernes en ligne de commande que j’utilise aujourd’hui à la place d’anciens outils : bat est un cat avec coloration syntaxique, difftastic est un meilleur diff, gdu est un ncdu pour SSD, zoxide est un cd moderne, fd est une alternative à find, rg est ripgrep, fzf est un outil de recherche floue, jless est un visualiseur JSON avec repli à la souris, dra sert à télécharger/installer des assets de releases, lazygit est une TUI Git, lazydocker est une TUI Docker, yazi est un gestionnaire de fichiers avec prévisualisation d’images, zellij est un meilleur tmux/screen, et starship est un outil de configuration de prompt utilisable avec plusieurs shells.

    • Pour ajouter quatre outils que j’utilise souvent : task est une alternative aux Makefile, hyperfine est un outil de benchmark, vegeta est un outil de test de charge, et sd est un sed meilleur et plus intuitif.
      Il y a aussi le trio JSON : jq est le processeur JSON bien connu, jc convertit la sortie de nombreux outils CLI en JSON, et gron rend le JSON facile à passer à grep.
    • Attention : fd et rg ignorent par défaut les éléments inclus dans .gitignore. Si vous les considérez comme de simples remplaçants de find, vous risquez d’être surpris. La discussion liée se trouve en [0].
      Quand on recommande ce genre d’outils, il faut le préciser clairement. C’est facile à manquer si l’on ne lit pas la documentation. Personnellement, j’aimerais que ces outils de remplacement des coreutils gardent des valeurs par défaut plus proches de celles des outils d’origine. S’ils se présentent comme « une alternative simple, rapide et conviviale à find », ils devraient respecter les valeurs par défaut d’origine afin de réduire les surprises pour les nouveaux utilisateurs. Les alias existent, donc je préfère mettre alias fd='fd --ignore' dans ~/.${SHELL##*/}rc plutôt que alias fd='fd --no-ignore'.
      Astuce : si vous voulez utiliser la version sans alias, utilisez \command. Par exemple, j’utilise alias grep='grep --color=always --no-messages --binary-files=without-match, mais l’option de couleur modifie la représentation des caractères et peut provoquer des erreurs lorsqu’on pipe vers curl. Ça n’arrive pas dans tous les pipelines, mais la première fois c’est assez déroutant. On peut le vérifier avec echo "Hello world" | \grep --color=always "Hello" | hexdump, puis !!:s^always^never.
      [0] https://github.com/sharkdp/fd/issues/612
    • Ce lien contient aussi une longue liste d’outils supplémentaires dont je n’avais jamais entendu parler, mais qui ont l’air intéressants.
      https://github.com/ibraheemdev/modern-unix
    • J’aime le fait que la plupart de ces outils soient écrits en Rust.
    • Je n’ai pas eu l’impression que zellij soit meilleur que screen. Les onglets/écrans ne sont pas numérotés correctement, donc pour basculer directement il faut compter soi-même, et c’est difficile à accepter.

  • GNU ls est maintenu. Il y a eu des commits affectant le fichier ls.c les 2024-06-24 et 2024-06-27, il y a moins d’un mois.
    La liste de diffusion GNU Coreutils est également assez active. Ce projet semble utiliser « maintained » au sens de « activement développé ».

    • Il semble qu’ici il s’agisse de exa, dont eza est un fork. exa n’a pas été maintenu pendant environ un an avant que la seule personne ayant les droits d’écriture sur le dépôt ne le marque officiellement comme deprecated.
      Maintenant que le fork existe depuis un bon moment, tout le monde ne connaît pas exa, et l’intention de cette formulation est devenue beaucoup moins claire. Vu qu’il y a des réactions similaires, il est peut-être temps de mettre le texte à jour.
    • Ici, « maintained » ne veut pas dire que ls n’est pas maintenu, mais que c’est une alternative maintenue, en tant que fork d’exa, l’alternative à ls qui n’est plus maintenue.

  • Depuis que je suis passé au shell fish, mon utilisation de ls a chuté de 100 %. La commande intégrée Alt + l affiche le contenu du répertoire, ce qui est très pratique, et l’historique du shell est aussi plus propre

    • Dans Bash aussi, on peut garder un historique plus propre en ajoutant des commandes comme ls à la variable d’environnement HISTIGNORE : https://superuser.com/questions/232885/can-you-share-wisdom-...
    • Bon conseil. Ce qui a éliminé la plupart de mon usage de ls dans fish, c’est une configuration qui lance automatiquement ls quand je change de répertoire
      function ls_on_cd --on-variable PWD
      ls
      end
    • Les utilisateurs de Bash peuvent aussi binder des raccourcis clavier de ce genre. J’ai associé les touches de la rangée de repos de la main droite à des fonctions comme __bash_ctrl_n(), et plusieurs outils dans mes dotfiles redéfinissent ces fonctions. Par exemple, si Git est installé, je configure __bash_ctrl_e() pour lancer git status et git log
    • Dans mon environnement, sans doute parce que j’ai mis un alias de ls vers eza, cette fonction semble exécuter eza. Au final, on dirait qu’elle lance simplement ls
    • J’ai ajouté ça à mes fichiers de démarrage après avoir réalisé que la plupart de mes exécutions de ls arrivaient juste après un cd. Désormais, presque tous les cd lancent automatiquement ls
      Dans Bash, ma fonction cd() appelle builtin cd "$@" && ls -l, et dans fish, après builtin cd $argv, si aucune erreur ne survient et qu’il ne s’agit pas d’un retour au home, elle exécute dir

  • Globalement, les outils de terminal qui imposent les couleurs pour distinguer les types ou attributs de fichiers me gênent. Le ls de beaucoup de distributions est aussi configuré comme ça, mais je supprime cette configuration et j’utilise les valeurs par défaut
    J’utilise un fond de terminal reposant pour les yeux, et ces schémas de couleurs finissent toujours par entrer en conflit avec le fond ou inclure des couleurs difficiles à lire. La sortie de ls ou de ses alternatives n’a pas besoin de couleur ; ce que fournit ls -AFC me suffit largement

    • Ce serait beaucoup moins problématique si les outils utilisaient le Base16 Framework[0] au lieu de modes couleur arbitraires “256 color” ou “RGB”. La sortie s’afficherait alors avec les couleurs définies par le terminal, censées être lisibles
      [0] https://github.com/chriskempson/base16
      [1] https://tinted-theming.github.io/base16-gallery/
    • De mon côté, c’est complètement l’inverse : je dépends beaucoup de la sortie colorisée
      Il devrait quand même y avoir une solution, et il suffit de définir une valeur quelconque pour $NO_COLOR. https://no-color.org
      Il est tout à fait légitime de signaler un bug aux outils qui ne vérifient pas et ne respectent pas cette variable d’environnement
    • https://no-color.org
    • Il suffit d’utiliser vivid[1] pour choisir un thème adapté au fond du terminal, puis de charger dans le shell la variable LS_COLORS générée
      [1]: https://github.com/sharkdp/vivid/

  • C’est étrange que le README n’indique pas que eza est un fork de exa

    • Il mentionne bien “eza features not in exa”, donc son existence est évoquée. Mais il n’y a ni lien ni contexte

  • Je me demande pourquoi autant de nouvelles versions des utilitaires GNU sont publiées sous licence MIT. Il semble y en avoir pas mal

    • Les utilisateurs de Rust ont globalement tendance à publier leur code sous licence permissive. Je ne sais pas s’il existe des statistiques faciles à vérifier, mais presque tout ce qu’on trouve sur crates.io, le dépôt de paquets Rust, est sous MIT ou Apache-2.0, et c’est clairement le cas des bibliothèques populaires
    • Le projet GNU n’a pas inventé ls. Les GNU coreutils, qui incluent ls, étaient eux aussi à l’origine de nouvelles versions d’utilitaires propriétaires d’AT&T ou d’utilitaires sous licence BSD
    • À ce sujet, https://github.com/uutils/coreutils est une “réécriture cross-platform en Rust des GNU coreutils”

  • Pourquoi un remplaçant de ls aurait-il besoin de Kerberos et de SSH ?
    Quand on regarde ldd /usr/bin/eza, il est lié à pas mal de bibliothèques, dont libgit2, libgssapi_krb5, libmbedtls, libssh2, libkrb5, libcrypto, libzstd, etc.

    • Pour un simple ls, ça fait quand même beaucoup trop de dépendances

  • Sur un clavier QWERTY, eza est une combinaison de trois lettres assez atroce. L’un des avantages de ls, c’est que c’est une combinaison de touches très rapide à taper
    On peut bien créer un alias, mais pour des raisons comme la compatibilité, ça me paraît un peu bizarre

    • Depuis environ 2015, j’ai mis eza, et avant ça exa, en alias de ls, ll et lll, et je n’ai jamais rencontré de problème de compatibilité
      J’ai aussi installé sl pour m’entraîner à ne pas me tromper en tapant
    • Pour un utilisateur de Dvorak, eza ressemble à une amélioration. En Dvorak, ls correspond à p- en QWERTY, donc les deux sont des touches de l’auriculaire droit
    • Peux-tu expliquer davantage pourquoi créer un alias serait bizarre ?
    • Tu peux créer un alias avec le nom que tu veux
    • C’est dans ce genre de cas que le clavier AZERTY brille

  • De toute façon, qui utilise ls ? On se contente d’utiliser l’autocomplétion avec Tab jusqu’à ce que le fichier voulu apparaisse
    Blague à part, je me demande pourquoi on affirme que ls n’est plus maintenu

    • Il me semble qu’il s’agit de exa[0], qui n’est plus maintenu, et non de ls
      [0]https://github.com/ogham/exa
    • Pour une raison ou une autre, il est devenu courant de considérer qu’un logiciel qui n’est pas mis à jour régulièrement est intrinsèquement obsolète
    • Bien sûr, ls est maintenu dans le cadre du shell ou de coreutils
      Cela dit, eza est un dérivé de exa, et à ma connaissance exa n’est plus maintenu
    • Ils mélangent délibérément « maintained » et « actively developed » pour donner l’impression que l’outil existant n’est pas maintenu