Collection d’outils Linux modernes : de nouveaux CLI pour remplacer les commandes classiques

• Présentation de divers outils en ligne de commande modernes qui améliorent l’efficacité du travail sous Linux
• Beaucoup remplacent ou modernisent les commandes Unix traditionnelles, avec un fort accent sur les performances, notamment via des outils développés en Rust, Go, etc.

Outils d’affichage et d’exploration des fichiers

• bat : version enrichie de la commande cat avec coloration syntaxique et intégration renforcée avec git
• exa : visionneuse moderne de listes de fichiers remplaçant ls/tree, mais dont la maintenance est désormais arrêtée
• eza : fork de exa, fournissant un ls/tree moderne
• lsd : ls de nouvelle génération, compatible avec l’existant et offrant une sortie plus soignée
• broot : explorateur de fichiers en arborescence avec navigation améliorée
• nnn : gestionnaire de fichiers en terminal léger et rapide

Analyse de l’espace utilisé par les fichiers et répertoires

• ncdu : fournit une interface intuitive pour du en mode texte
• dust : alternative plus simple à du, implémentée en Rust
• duf : outil d’analyse de l’usage disque à l’ergonomie améliorée par rapport à df

Recherche de fichiers et de code

• fd : alternative concise et rapide à find, avec une excellente ergonomie
• ripgrep : alternative à grep ultra-rapide avec prise en charge de .gitignore
• ag : outil de recherche dans le code, proche de ack mais plus rapide
• fzf : moteur de recherche floue universel, utilisable dans des pipelines et dans bien d’autres contextes
• bfs : alternative à find basée sur le breadth-first

Visionneuses Git/diff dans le terminal

• delta : visualise plus lisiblement les résultats de git et diff

Historique et traitement des commandes

• mcfly : améliore de façon marquante la recherche et la navigation dans l’historique du shell, avec une meilleure pertinence et une UI intuitive

Traitement des données

• choose : alternative plus intuitive et plus rapide à cut et à certains usages de awk
• jq : parseur de données utilisable comme un sed dédié au JSON
• sd : outil de remplacement de sed, pour un find/replace plus familier

Supervision système et processus

• bottom : moniteur système/processus graphique multiplateforme
• glances : version améliorée de top/htop
• gtop : moniteur système en forme de tableau de bord pour le terminal
• procs : commande de remplacement pour ps écrite en Rust

Benchmarking et réseau

• hyperfine : outil d’automatisation du benchmarking CLI
• gping : outil ping avec affichage graphique

Clients HTTP

• httpie : client HTTP moderne et convivial pour le CLI, bien adapté aux tests d’API pour développeurs
• curlie : outil qui combine la puissance de curl avec l’ergonomie de httpie
• xh : alternative à httpie axée sur les performances

Navigation entre répertoires et éditeurs

• zoxide : commande cd intelligente inspirée de z
• micro : éditeur de texte pour terminal doté de fonctionnalités modernes

Nouvelles utilitaires CLI

• up : outil de pipeline avec aperçu en temps réel, permettant de voir immédiatement la sortie des commandes

Outils d’aide et de documentation

• ManKier : pages man résumées avec des explications de commandes claires
• tldr : résumé concis des pages man centré sur des exemples
• tealdeer : implémentation Rust de tldr, avec une exécution rapide
• explainshell : analyse automatiquement les arguments d’une commande et explique visuellement leur signification
• cheat.sh : service d’aide en ligne combinant tldr et cheatsheets

Outils GUI

• baobab : analyseur d’usage disque avec interface graphique
• stacer : outil GUI d’optimisation et de supervision système, avec gestion des services incluse

[GN⁺]

Commentaires Hacker News

• Ces outils sont peut-être objectivement meilleurs, mais j’ai réalisé que devoir les configurer à chaque nouvelle installation d’OS, à chaque VM lancée ou à chaque connexion SSH, c’est une galère sans fin. Refaire la configuration dans chaque environnement est épuisant, et je n’ai pas envie d’utiliser un mélange de nouveaux outils dans un endroit et d’outils traditionnels ailleurs. Bien maîtriser les outils classiques est au final ce qui simplifie le plus la vie

  • Certaines personnes passent l’essentiel de leur temps sur leur propre machine, donc ce gain de confort a beaucoup de valeur. Elles savent quand même suffisamment se servir des outils classiques, donc pour intervenir occasionnellement sur d’autres serveurs, c’est largement suffisant. Tout le monde n’est pas administrateur système à devoir se connecter toute la journée à une multitude de serveurs différents

  • Certains outils sont tellement meilleurs qu’ils valent largement la petite gêne de l’installation. Je maîtrise bien les outils classiques, mais fd et ripgrep sont toujours meilleurs

  • Si j’aime autant Nix, c’est justement parce qu’il me permet d’avoir quasiment la même configuration partout (tant que l’environnement que j’utilise est Linux ou macOS, ce sont les deux seuls cas qui m’importent). Il existe plusieurs méthodes d’installation de Nix qui ne nécessitent pas les droits root, ce qui me permet de recréer mon environnement partout. Bien sûr, sans Nix, les outils classiques restent tout à fait suffisants. Ce n’est pas un choix exclusif, on peut avoir les deux

  • Quand on réinstalle un OS, il faut de toute façon installer les paquets nécessaires avec apt-get, pacman, dnf, brew, etc., et installer aussi séparément son navigateur, son éditeur et le reste. En SSH, on n’a pas d’interface graphique de toute façon, mais ce n’est pas une raison pour éviter les outils GUI. Je ne pense pas que ce soit un gros problème d’avoir une combinaison d’outils différente entre environnement personnel et environnement partagé. Par exemple, bat ne remplace pas complètement cat, il ajoute juste la coloration syntaxique et rend la vie plus agréable. S’il n’est pas installé, on s’en passe simplement

  • À mon avis, si on se réfère à la philosophie UNIX du « faire une seule chose et bien la faire », le fait même de pouvoir remplacer facilement ces utilitaires simples quand une meilleure alternative apparaît est au cœur du concept. Apprendre d’abord les outils classiques est pertinent pour sa carrière, mais je pense qu’il faut aussi apprendre les nouvelles alternatives. Personnellement, plus que bat ou eza, ce sont les alternatives qui font gagner du temps comme fd (remplaçant de find) ou sd (remplaçant de sed) que je trouve vraiment utiles

• Quand on doit se connecter à des centaines de serveurs, sur plusieurs réseaux et chez plusieurs clients, les outils personnalisés n’ont presque aucune valeur. Dans 90 % des environnements, ils ne sont pas installés. Moi, j’ajoute juste quelques éléments à ansible-config et je les déploie en automatique, mais je garde une liste très courte. 95 % des systèmes que je gère sont sous Debian ou Ubuntu, donc la base est presque la même partout, et j’ajoute seulement des choses comme ack, etckeeper, vim, pv, dstat

  • Le mot-clé ici, c’est « serveur ». Beaucoup de programmes légèrement améliorés pour sysadmins n’ont peut-être pas tant de valeur, mais certains sont de vrais outils de dev utilisés dans l’environnement de développement, donc il suffit de les installer sur le petit nombre de machines où l’on programme. ripgrep (excellent grep récursif), jq (processeur JSON sans véritable équivalent dans la boîte à outils Unix de base), hyperfine (benchmarking) en sont de bons exemples

  • Comme je travaille à la fois sur Windows et Linux, des outils cross-platform aussi bons que ripgrep sont vraiment pratiques

  • Je me demande s’il existe un outil ou une extension SSH capable d’apporter automatiquement ce genre d’apps dans une session SSH distante. Si ce sont de petits binaires, on pourrait les copier dans un dossier temporaire et les utiliser, et on peut imaginer automatiser ce processus. La vraie question, c’est la sécurité et l’éventuel besoin de privilèges supplémentaires. Au fond, tout repose sur la portabilité de ces apps. Moi aussi, je me pose souvent la question

  • emacs fonctionne presque comme un système d’exploitation à part entière, ce qui permet de retrouver un environnement familier sur n’importe quel système. C’est de là que vient la phrase « GNU is my operating system, linux is just the current kernel ». Du point de vue d’un admin chevronné, c’est pour cela que je recommande à quelqu’un qui débute sous Linux de commencer par la commande info et de lire toute sa documentation. Cela permet de dépasser largement la plupart des administrateurs. Quand on connaît les outils intégrés, la documentation est bonne, l’écriture de scripts devient facile, et c’est précisément le cœur de la philosophie Linux. À une époque, il n’y avait même pas nano, seulement vi, mais aujourd’hui il est simple d’ajouter un éditeur TUI via l’automatisation CI/CD

  • J’ai du mal avec ces commentaires du type « moi, je suis ce genre de personne ». Beaucoup de gens se moquent complètement du fait de ne pas installer d’outils personnalisés à distance. L’idée est simplement de profiter de leurs avantages au moins sur sa machine locale

• Je pense que ce tableau gagnerait à avoir une colonne supplémentaire du type « quel problème cet outil résout-il ? ». Et pour moi, « implémenté en Rust » n’est pas un critère différenciant

  • Il m’est déjà arrivé d’assister à une réunion d’entreprise où quelqu’un présentait « écrit en Go » comme un élément différenciant. #facepalm

  • Beaucoup d’entrées du tableau mentionnent bien un problème concret, par exemple « syntax highlight », « ncurses interface » ou « more intuitive ». En revanche, des formulations comme « écrit en Rust », « moderne » ou « meilleur » n’aident pas vraiment

  • L’objectif principal de la plupart de ces outils, c’est d’améliorer l’UX

  • Utiliser une licence non GPL n’est pas non plus un élément différenciant

  • Une bonne partie de ces outils ont aussi l’avantage d’être disponibles sur Windows

• Ce genre de liste d’outils est toujours un plaisir. La plupart des gens trouveront probablement ici un ou deux outils qui leur seront vraiment utiles. Pour moi, ripgrep et jq sont indispensables. ripgrep est le meilleur remplaçant direct de grep, et jq résout un problème que j’avais absolument besoin de résoudre. Je vais peut-être aussi essayer lsd et dust. Même quand un nouvel outil ne m’est pas directement utile, j’apprécie que des gens y consacrent du temps. Le fait d’améliorer progressivement la boîte à outils de toute la communauté est remarquable

  • Je choisirais fzf en premier. Je le préfère de très loin à rg ou jq

  • ripgrep ne se comporte pas comme grep, donc ce n’est pas en réalité un remplaçant direct. C’est un excellent programme, mais il n’est pas totalement compatible

  • Les admins Linux comme moi ont tous ce genre de liste soigneusement ficelée. Moi, j’ai plutôt construit mon camp autour d’une pile GPL, et j’aime particulièrement le format de ikrima.dev

• Je vis dans le terminal, mais ces outils ne résolvent aucun problème que j’ai tout de suite, ou bien ils ne sont pas installés sur mon système, et pourtant ils ont d’une manière ou d’une autre des dizaines de milliers d’étoiles sur GitHub. Je ne comprends vraiment pas d’où vient cette popularité

  • Quelqu’un qui vit plongé dans sa bibliothèque musicale peut tout aussi bien trouver étrange qu’un artiste qui n’est ni dans sa bibliothèque ni à son goût vende des millions d’albums. Blague à part, j’aimerais demander si tu as déjà vraiment essayé ce genre d’outils. Moi non plus, je ne comprenais pas pourquoi les gens utilisaient vim, puis quand je l’ai vraiment utilisé, j’ai compris

  • Tu n’utilises pas fzf ? La vie en terminal doit être vraiment difficile. Avec les plugins de shell, c’est extrêmement utile : Ctrl+R pour faire une recherche floue dans bash_history, Ctrl+T pour chercher de façon floue parmi les fichiers du répertoire courant, sans avoir à lancer la commande directement

  • La boîte à outils Unix de base est déjà tellement solide qu’on peut très bien travailler uniquement avec elle. Beaucoup d’alternatives sont meilleures, mais elles ne sont pas indispensables, et en plus elles ne sont généralement pas installées par défaut

  • Par curiosité, existe-t-il une manière élégante, avec les seuls outils Unix intégrés, de faire un grep récursif uniquement sur certains fichiers selon leur extension tout en ignorant les fichiers cachés (.git, etc.) ? Par exemple, la commande rg -g '*.foo' bar correspond à un cas d’usage que j’emploie très souvent. Même chose avec fd pour trouver des fichiers correspondant à une expression régulière ou à un glob. Je n’ai pas trouvé de méthode propre avec les outils de base

  • Je me demande quel genre de travail on peut faire toute la journée dans le terminal sans ressentir le besoin d’améliorer sa boîte à outils. J’aurais presque envie de demander si la personne écrit elle-même tous ses outils

• En mode sombre, le texte des liens est beaucoup trop peu visible, c’est difficile à lire

• Pour moi, seul jq résout vraiment un problème concret qui n’est pas correctement couvert par les outils existants. Tout le reste relève surtout de préférences, de performances, de mise en évidence syntaxique ou du fait d’être implémenté en Rust

• J’aimerais bien qu’une équipe sorte une véritable suite d’outils avec une conception cohérente sur les paramètres, les couleurs, les tableaux, etc.

• Pendant longtemps, j’ai utilisé htop plutôt que top parce que je le trouvais plus accessible, mais le fait que htop n’affiche pas les threads du noyau par défaut m’a gêné pour identifier la cause d’incidents. Depuis, je suis revenu à top, qui montre toutes les informations et auquel je fais davantage confiance. Les interfaces de htop/btop me semblent proches du simple spectacle

• Cet article date de 2023. La plupart des « outils modernes » ont peut-être déjà été mis à jour, et de nouvelles alternatives plus tendance sont peut-être apparues

  • Comme il y a énormément d’outils, même si seule la moitié survit, cela reste déjà très précieux

  • Mon expérience est plutôt l’inverse. La plupart de ces outils ne font que « réinventer » une fois de plus les puissants outils GNU de base, à condition d’y consacrer le temps nécessaire pour vraiment les apprendre