URL: https://linuxfr.org/news/des-alternatives-a-grep-ls-et-find Title: Des alternatives à grep, ls et find Authors: Bruno Michel Xavier Teyssier, Davy Defaud et palm123 Date: 2018年03月17日T15:05:45+01:00 License: CC By-SA Tags: grep, ls, find, ripgrep et rust Score: 69 Les outils en ligne de commande comme `ls`, `grep` et `find` existent depuis de nombreuses années et, même s’ils continuent de s’améliorer, il est parfois intéressant de regarder les alternatives. Je vais vous parler de `ripgrep`, `exa` et `fd`. ---- [Ripgrep](https://github.com/BurntSushi/ripgrep) [Exa](https://the.exa.website/) [Fd](https://github.com/sharkdp/fd) ---- ## Ripgrep Les alternatives à _grep_ ne manquent pas. Déjà, la commande `grep` de son shell peut être soit le [_grep_ du projet GNU](https://www.gnu.org/software/grep/) ou [celui du projet BSD](https://wiki.freebsd.org/BSDgrep). Il y a aussi le [_grep_ intégré à Git](https://git-scm.com/docs/git-grep). Et d’autres outils sont apparus ces dernières années, citons [_ack-grep_](https://beyondgrep.com/), [_ag_ (_the silver searcher_)](https://geoff.greer.fm/ag/), [_pt_ (_the platinum searcher_)](https://github.com/monochromegane/the_platinum_searcher) et le petit dernier [_ripgrep_](https://github.com/BurntSushi/ripgrep). Ces outils se battent pour savoir lequel est le plus rapide ou a [le plus de fonctionnalités](https://beyondgrep.com/feature-comparison/). Personnellement, j’utilise _ripgrep_ car il est très rapide, réalise par défaut une recherche récursive dans les répertoires (un gros manque de GNU grep selon moi, mais c’est probablement bien trop tard pour changer le comportement de GNU grep), a une présentation par défaut des résultats que j’apprécie, et il sait chercher dans des fichiers compressés (gzip, bzip2, xz) avec l’option `-z`. ## Exa Lister des fichiers est un besoin de base dans un terminal et `ls` remplit bien ce besoin. [Exa](https://the.exa.website/) est une alternative à `ls` que j’utilise pour ses couleurs, qui viennent par défaut et que je trouve plus agréables que celles de `ls`. Il propose également une vue arborescente des répertoires et fichiers, qui remplace plutôt [`tree`](http://mama.indstate.edu/users/ice/tree/). Exa est aussi capable d’afficher le statut Git des fichiers et répertoires. ## Fd [Fd](https://github.com/sharkdp/fd) peut remplacer avantageusement `find`. Je n’utilise que très peu l’un ou l’autre, mais `fd` a une syntaxe plus facile à retenir et il est, d’après ses tests, plus rapide que `find`. Il utilise par défaut l’encodage UTF-8, il a une sortie colorée et ignore les fichiers listés dans un `.gitignore`. Et surtout, ça fait deux fois moins de caractères à taper pour le nom de la commande. ;-) ## Les points communs ### Vitesse On retrouve beaucoup de benchmarks autour de ces outils, les performances sont un vrai enjeu. Mettre trois secondes au lieu de quinze secondes peut paraître anecdotique pour des recherches un peu compliquées, mais cette différence peut casser le rythme : si une commande prend plus de dix secondes, je vais sûrement commencer à aller voir ailleurs. ### Fonctionnalités et comportement par défaut Ces outils ont beaucoup de fonctionnalités : les options que l’on peut passer en ligne de commande permettent de changer fortement leurs comportements. Ceci dit, en pratique, je n’utilise que peu d’options (et quasiment toujours les mêmes). En revanche, j’apprécie beaucoup que ces outils cherchent à avoir le comportement par défaut le plus utile. ### Intégration avec Git Ces outils ont tous une intégration avec [Git](https://git-scm.com/) : `ripgrep` et `fd` savent lire les fichiers `.gitignore` et `exa` sait afficher l’état Git des fichiers. Ce n’est pas un critère très important à mes yeux car je suis à l’aise avec Git en ligne de commande. Mais c’est intéressant de noter à quel point `git` est devenu incontournable en ligne de commande. ### Rust Un fait remarquable est que les trois outils présentés sont écrits en Rust. Il faut croire que ce langage convient bien pour écrire des outils en ligne de commande. C’est un domaine où le temps d’exécution est important (quand on lance une commande, c’est appréciable que le retour soit instantané ou en tout cas très rapide). Les langages de script (JavaScript, Ruby, Python) ont un temps de lancement de leur machine virtuelle qui peut casser cette impression de vitesse, je comprends donc que les développeurs d’outils en ligne de commande puissent s’en éloigner. En revanche, il est plus surprenant de ne pas retrouver d’outils en Go, en D, en OCaml ou en Haskell. Peut‐être que les lecteurs de _LinuxFr.org_ auront une explication à cela.

AltStyle によって変換されたページ (->オリジナル) /