Des alternatives à grep, ls et find

Posté par Bruno Michel (site web personnel) le 19 mars 2018 à 13:20. Édité par Xavier Teyssier, Davy Defaud et palm123. Modéré par Xavier Teyssier. Licence CC By‑SA.

Étiquettes :

mar.

2018

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

Les alternatives à grep ne manquent pas. Déjà, la commande grep de son shell peut être soit le grep du projet GNU ou celui du projet BSD. Il y a aussi le grep intégré à Git. Et d’autres outils sont apparus ces dernières années, citons ack-grep, ag (the silver searcher), pt (the platinum searcher) et le petit dernier ripgrep.

Ces outils se battent pour savoir lequel est le plus rapide ou a le plus de fonctionnalités. 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 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. Exa est aussi capable d’afficher le statut Git des fichiers et répertoires.

Fd

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 : 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.

Aller plus loin

Ripgrep (707 clics)
Exa (560 clics)
Fd (465 clics)

# langue

Posté par Nicolas Boulay (site web personnel) le 19 mars 2018 à 13:40. Évalué à 1.

Les outils pourraient être écrit en ocaml, c'est le cas de nombreux compilateurs. Mais j'imagine que la complexité qui pourrait être géré par Ocaml n'est pas assez grande dans ce genre d'outil pour justifier le surcout de développement. Ensuite, il me semble que Rust dispose de beaucoup des constructions sympa fonctionnelles.

Go n'est pas fait pour ça. Go, c'est pour faire du serveur web applicatif, pas un outils en ligne de commande, même si c'est possible, bien sûr.

"La première sécurité est la liberté"
- [^] # Re: langue
  
  Posté par arnaudus le 19 mars 2018 à 13:57. Évalué à 10.
  
  Go n'est pas fait pour ça.
  
  J'ai toujours eu du mal avec les langages qui sont censés être faits pour quelque chose et pas pour autre chose. Certains langages se sont avérés très utiles en dehors de la niche pour laquelle ils avaient été conçus ; c'est parfois rafraichissant (et parfois déroutant, voire décourageant). D'une manière générale, quand on code quelque chose, mais vaut le faire dans un langage qu'on maitrise et qu'une communauté suffisamment grande maitrise, plutôt que dans un langage de niche super adapté.
  - [^] # Re: langue
    
    Posté par aiolos le 19 mars 2018 à 14:10. Évalué à 10. Dernière modification le 19 mars 2018 à 14:10.
    
    Surtout qu'affirmer
    
    Go, c'est pour faire du serveur web applicatif, pas un outils en ligne de commande, même si c'est possible, bien sûr.
    
    C'est globalement assez faux. C'est un langage qui a été en premier lieu conçu pour la programmation système. On le trouve utilisé dans pas mal de projets d'assez, voir très, bas niveau (J'ai en tête le projet Linuxboot/NERF, présenté ici même, par exemple).
  - [^] # Re: langue
    
    Posté par Nicolas Boulay (site web personnel) le 19 mars 2018 à 16:59. Évalué à 5.
    
    Ce que je veux dire c'est que la communauté autour du langage, et les bibliothèques disponibles sont très axé web.
    
    Mais c'est un langage générique, on peut tout faire avec, le travail sera simplement moins prémâché.
    
    "La première sécurité est la liberté"
    - [^] # Re: langue
      
      Posté par abriotde (site web personnel, Mastodon) le 20 mars 2018 à 14:03. Évalué à 1.
      
      Go a un gros défaut c'est que généralement les exécutable sont assez gros ce qui les rends relativement long a lancer. Ils embarque beaucoup de choses (une sorte de VM je crois). Si pour un OS ou pour une grosse application, ça n'a pas d'impact pour une ligne de commande qui fais juste un "ls" c'est rédhibitoire.
      
      Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
      - [^] # Re: langue
        
        Posté par Bruno Michel (site web personnel) le 20 mars 2018 à 15:10. Évalué à 6.
        
        Les exécutables en go font quelques Mo pour des outils en ligne de commande du type de ceux cités dans la dépêche. Par exemple, gops fait 3,9 Mo chez moi et peco, cité dans un autre commentaire de cette dépêche, fait 4,8 Mo. Pour comparer, Le binaire de ripgrep (Rust) fait 3,8 Mo, celui d'exa (Rust) 1,7 Mo.
        
        Les 4 programmes cités ci-dessus s'exécutent en moins d'un centième de seconde, le plus rapide étant peco (Go).
        
        [^] # Re: langue
        
        Posté par Yth (Mastodon) le 20 mars 2018 à 21:10. Évalué à 5.
        
        ls -sh $(realpath $(which grep)) 152K /bin/grep time for i in $(seq 1000); do grep; done 2>/dev/null real 0m2.073s user 0m1.116s sys 0m0.267s
        
        Soit dans les 2 millièmes de secondes avec le coût de la boucle bash sous-optimisée.
        
        Je veux bien que moins d'un centième de seconde ça suffise à ne pas percevoir la latence, mais bigre, c'est lent et lourd (11 à 32 fois plus gros) ces alternatives !
        Ça veut justement dire que ça reste des alternatives à utiliser en mode interactif, pour leur meilleure ergonomie, quand le temps d'écriture de la commande est titanesque par rapport au temps de chargement du programme, mais pas forcément quelque chose d'exploitable dans de la programmation shell.
        
        Yth.
        
        [^] # Re: langue
        
        Posté par Bruno Michel (site web personnel) le 21 mars 2018 à 09:09. Évalué à 7.
        
        Heu, 2 millièmes de seconde, c'est moins d'un centième de seconde. C'est une valeur plus précise mais ça ne suffit pas à dire si c'est vraiment plus rapide. Je n'ai pas voulu donner une valeur précise parce que ça dépend de l'ordinateur, de ce que ça fait à l'initialisation.
        
        Mais bon, si tu tiens vraiment à comparer, voilà ce que ça donne sur mon ordinateur :
        
        $ time for i in $(seq 1000); do ls ; done >/dev/null real 0m1,709s user 0m1,176s sys 0m0,618s $ time for i in $(seq 1000); do exa ; done >/dev/null real 0m1,138s user 0m0,890s sys 0m0,271s $ time for i in $(seq 1000); do grep -V ; done >/dev/null real 0m1,681s user 0m1,179s sys 0m0,607s $ time for i in $(seq 1000); do rg -V ; done >/dev/null real 0m2,335s user 0m1,486s sys 0m0,945s
        
        Pour de la programmation shell, c'est utilisable, mais si tu veux partager ce script avec d'autres personnes, c'est effectivement probablement mieux de rester avec les grep, ls et find de base pour éviter aux autres de devoir installer les alternatives.
        
        [^] # Re: langue
        
        Posté par Tonton Th (Mastodon) le 21 mars 2018 à 23:49. Évalué à 3.
        
        time for i in $(seq 1000); do grep; done 2>/dev/null
        
        ~ $ time for i in $(seq 1000); do grep; done Usage: grep [OPTION]... PATTERN [FILE]... Try 'grep --help' for more information.
        
        2000 lignes plus loin…
        
        Usage: grep [OPTION]... PATTERN [FILE]... Try 'grep --help' for more information. real 0m15.105s user 0m10.459s sys 0m3.348s ~ $
        
        Donc, oui, si tu veux spiter des centaines de fois le même message d'erreur, c'est bien, mais pas forcément quelque chose d'exploitable dans la vrai vie, sauf pour bencher les xterms…
        
        [^] # Re: langue
        
        Posté par Yth (Mastodon) le 22 mars 2018 à 08:48. Évalué à 3.
        
        @mylinux grep pond ses messages d'erreur sur stderr et la subtilité de 2>/dev/null sert à ne pas les afficher dans le terminal et donc à ne pas bencher le terminal.
        Comme on parlait du démarrage du programme, pour comparer justement le surcoût possible des versions go, rust et cie, évidemment on n'allait pas tester sur un vrai grep compliqué dans les sources du noyau Linux ou pire dans celles de openjdk.
        
        Le commentaire fort pertinent juste au dessus permet en fait de constater que de différence il n'y en a pas de significative, et donc on peut maintenant ignorer ce faux problème et se concentrer sur l'efficacité du traitement.
        
        Merci de ta collaboration sur l'éclairage du débat…
        
        Yth.
        
        [^] # Re: langue
        
        Posté par darkleon (site web personnel) le 22 mars 2018 à 14:54. Évalué à 8. Dernière modification le 22 mars 2018 à 14:56.
        
        gops fait 3,9 Mo chez moi
        
        N'empêche que les outils deviennent un peu trop obèses à mon goût, quand on parle de plusieurs méga-octets. J'ai l'impression que le rapport signal/bruit devient ridicule.
        gops qui fait 3.9Mo, c'est seulement 250 fois plus que le zx81-16k ou 4x plus que l'Amiga 500 (ou atari 520 st, ou 286 ou mac, ou ce que vous aviez à l'époque avec 1Mo …) ou 12% de la RAM de mon premier PC pentium, et tout ça pour lister des process ! XXXXXXXXXX
        
        Quelques exemples en ligne de commande C (et encore si on compare au zx81, c'est déjà abuser, vu que ce sont des process qui ne font que des opérations mémoire, I/O et console en flux).
        
        Sur une RHEL 7.2 "de base"
        ls -lh /usr/bin/ps
        -rwxr-xr-x. 1 root root 98K Aug 2 2017 /usr/bin/ps
        ls -lh /usr/bin/top
        -rwxr-xr-x. 1 root root 105K Aug 2 2017 /usr/bin/top
        ls -lh /usr/bin/htop
        -rwxr-xr-x. 1 root root 161K Jul 24 2016 /usr/bin/htop
        ls -lh /usr/bin/ls
        -rwxr-xr-x. 1 root root 115K Sep 7 2016 /usr/bin/ls
        ls -lh /usr/bin/grep
        -rwxr-xr-x. 1 root root 156K May 27 2017 /usr/bin/grep
        ls -lh /usr/bin/find
        -rwxr-xr-x. 1 root root 195K Jun 1 2015 /usr/bin/find
        
        Une comparaison avec un autre domaine, 4Mo, c'est la taille du Roman de Victor Hugo les misérables sur le projet Gutenberg, + de 500.000 mots et 2000 pages.
        M'étonnerait que GOP face 2000 écrans 80x25 en code.
        (exemple inspiré de cet article : http://idlewords.com/talks/website_obesity.htm )
        
        XXXXXXXXXX Je suis très content d'avoir 8Go de Ram chez moi et au boulot, ainsi que des SSD performants et une résolution graphique HD (pas encore 4K :-) ), j'apprécie grandement l'évolution des performances brutes du matériel.
        
        Mais bon, quand on met en perspective, 4Mo à l'époque des 16bits, c'était de la mémoire de "workstation" (ça serait 16-32Go aujourd'hui) et des films d'animations 3D ont été réalisés sur ce genre de matériel, et maintenant, ça serait juste suffisant pour lister des process ?
        
        Après je fais le constat comme beaucoup de gens (cf article website_obesity) et je le déplores, mais le "Time To Market" fait qu'on surconsomme les ressources hardware (et les applications ne sont ni mieux, ni plus performantes, ni plus rapides à développer, juste avec plus de vocabulaire pipo-bimbo marketing pour vendre du service/support).
        
        [^] # Re: langue
        
        Posté par Nicolas Boulay (site web personnel) le 22 mars 2018 à 16:03. Évalué à 3.
        
        Pour réduire la taille des binaires, il faut être capable de détecter le code objet inutile. En toute logique, Go (golang) possède toutes l'information pour faire le ménage. Encore faut-il accepter le surcout à la compilation.
        
        "La première sécurité est la liberté"
        
        [^] # Re: langue
        
        Posté par darkleon (site web personnel) le 22 mars 2018 à 16:37. Évalué à 1.
        
        C'est quand même dommage dans un monde ou on automatise tout (intégration continue, usine logicielle) que la compilation finale pour "RELEASE" ne se fasse pas avec la suppression de tout le poids mort (au moins le code mort, voire les informations de debug).
        
        Et puis même si on a de super SSD et de la RAM, ça fait une différence de temps entre charger, trouver le point d'entrée et exécuter 100ko et 4Mo.
        
        [^] # Re: langue
        
        Posté par Nicolas Boulay (site web personnel) le 22 mars 2018 à 16:43. Évalué à 3.
        
        Il faut retrouver l'histoire de dev de GOLD le nouveau linker de GCC qui fait ses optimisations de code mort. C'est un problème assez complexe.
        
        "La première sécurité est la liberté"
        
        [^] # Re: langue
        
        Posté par darkleon (site web personnel) le 22 mars 2018 à 16:56. Évalué à 2.
        
        Pas plus que le % de couverture de code par les tests.
        En plus, quand je pensais code mort, je pensais plutôt a des fonctions inutilisées d'une bibliothèque (ou carrément d'une bibliothèque linké alors qu'aucune méthode n'est utilisée).
        
        Plutôt que des bouts de code inaccessible (un "if" toujours à false par exemple) qui tombe dans le "problème de l'arrêt" qui est indécidable et donc aucune méthode ne sera parfaite pour éliminer ce genre de code mort.
        
        Si un programme "Hello World" qui ne demande qu'un "printf" se retrouve lié statiquement avec une bibliothèque de plusieurs Mo, pour le coup, c'est du code mort facilement éliminable en liant uniquemnt "printf" et ses fonctions dépendantes.
        
        [^] # Re: langue
        
        Posté par Nicolas Boulay (site web personnel) le 23 mars 2018 à 11:26. Évalué à 3.
        
        Si un programme "Hello World" qui ne demande qu'un "printf" se retrouve lié statiquement avec une bibliothèque de plusieurs Mo, pour le coup, c'est du code mort facilement éliminable en liant uniquemnt "printf" et ses fonctions dépendantes.
        
        Justement non. Ce n'est pas simple. Historiquement les compilateurs fonctionnaient toujours par morceau pour gérer la pénurie de mémoire des ordinateur (d'où les .o du C). Pour enlever les fonctions inutiles, il faut être capable de détecter toutes les appels de fonction en scannant le code entier. J'imagine qu'aujourd'hui on doit pouvoir décortiquer en mémoire, un programme entier, mais cela donne forcément une taille limite.
        
        Je me rappelle d'un hello-world avec une boite de dialogue en Lisaac, celui-ci, comme le go, récupérait tout le code et en faisait de la bouillis. Au final, le binaire faisait 12ko.
        
        "La première sécurité est la liberté"
        
        [^] # Re: langue
        
        Posté par Tonton Th (Mastodon) le 23 mars 2018 à 13:45. Évalué à 3.
        
        Historiquement les compilateurs fonctionnaient toujours par morceau pour gérer la pénurie de mémoire des ordinateur (d'où les .o du C).
        
        Probablement parce qu'il fallait pas mal de mémoire pour compiler, et aussi, et surtout, pour avoir des fichiers objet intermédiaires très granulaires, au niveau de la fonction.
        
        Pour enlever les fonctions inutiles, il faut être capable de détecter toutes les appels de fonction en scannant le code entier.
        
        Et c'est le travail de l'éditeur de liens : il scanne les .o et construit un arbre de dépendance pour n'inclure dans les exécutables que le code effectivement appelé. C'est pour ça que (avec certains linkers anciens), il fallait spécifier deux fois des .a (ou .lib) en cas de dépendances tordues…
        
        [^] # Re: langue
        
        Posté par Nicolas Boulay (site web personnel) le 23 mars 2018 à 15:07. Évalué à 3.
        
        Et c'est le travail de l'éditeur de liens : il scanne les .o et construit un arbre de dépendance pour n'inclure dans les exécutables que le code effectivement appelé. C'est pour ça que (avec certains linkers anciens), il fallait spécifier deux fois des .a (ou .lib) en cas de dépendances tordues…
        
        De mémoire, les linkers ne scannaient rien du tout, il ne faisait qu’agglomérer les .o que l'on lui donnait, et donnait une adresse mémoire au objet du .o.
        
        "La première sécurité est la liberté"
        
        [^] # Re: langue
        
        Posté par arnaudus le 22 mars 2018 à 17:45. Évalué à 2.
        
        Mouais, sans savoir déja ce qu'il y a dans le binaire, ça semble un peu compliqué de dire que c'est de la faute du compilo, du développeur de l'outil, des bibliothèques externes, etc. On peut très bien imaginer des dépendances qui font des pyramides de dépendances, et ça ça n'est pas forcément facile à prédire.
        
        [^] # Re: langue
        
        Posté par barmic le 22 mars 2018 à 18:08. Évalué à 4.
        
        ls -lh /usr/bin/grep -rwxr-xr-x. 1 root root 156K May 27 2017 /usr/bin/grep
        
        Ah ?
        
        Si on ajoute les bibliothèques ?
        
        Chez moi :
        
        ls -1sh /lib/x86_64-linux-gnu/ld-2.23.so /lib/x86_64-linux-gnu/{libc-2.23.so,libdl-2.23.so,libpcre.so.3.13.2,libpthread-2.23.so} =grep 208K /bin/grep* 160K /lib/x86_64-linux-gnu/ld-2.23.so* 1,8M /lib/x86_64-linux-gnu/libc-2.23.so* 16K /lib/x86_64-linux-gnu/libdl-2.23.so 448K /lib/x86_64-linux-gnu/libpcre.so.3.13.2 136K /lib/x86_64-linux-gnu/libpthread-2.23.so*
        
        On est à peu près à 2.7Mio, soit 3 000 cartes perforées de 920o ! (mais où va le monde !)
        
        [^] # Re: langue
        
        Posté par darkleon (site web personnel) le 22 mars 2018 à 18:54. Évalué à 5.
        
        Ok la comparaison liaison statique et liaison dynamique est encore plus injuste si on multiplie les processus.
        100 gop = 390 mo
        100 grep = 11 mo + 2,7 mo
        En plus ce sont des bibliothèques de base, donc quasiment tous les processus os ont du les ouvrir.
        
        Pour le clin d'oeil des cartes perforées, je suis très content d'avoir du matériel moderne sur mon bureau. Mais force est de constater qu'on fait pédaler toute cette puissance dans la choucroute.
        
        On ne va pas acheter une baguette à la boulangerie du coin avec un 38 tonnes.
        
        [^] # Re: langue
        
        Posté par darkleon (site web personnel) le 22 mars 2018 à 20:37. Évalué à 2. Dernière modification le 22 mars 2018 à 20:37.
        
        Oups, je me corrige sur le calcul des 100 greps : 156 ko x 100 = 15,25 Mo + 2,7 Mo <~ 18 Mo
        L'ordre de grandeur de comparaison liason statique/dynamique n'est pas bouleversé :-)
      - [^] # Re: langue
        
        Posté par Stéphane Klein (site web personnel) le 20 mars 2018 à 23:06. Évalué à 2.
        
        ls embarque beaucoup de choses (une sorte de VM je crois)
        
        Pas de VM pour Go.
        
        Extrait l'article Wikipedia: « It is a compiled, statically typed language in the tradition of Algol and C, with garbage collection, limited structural typing,[3] memory safety features and CSP-style concurrent programming features added. »
- [^] # Re: langue
  
  Posté par Bruno Michel (site web personnel) le 19 mars 2018 à 14:07. Évalué à 7.
  
  Go n'est pas fait pour ça. Go, c'est pour faire du serveur web applicatif, pas un outils en ligne de commande, même si c'est possible, bien sûr.
  
  Oui, mais Rust n'a pas spécialement été conçu pour ça non plus. Si je me souviens bien, j'avais lu quelques articles il y a quelques années qui vantait Go pour écrire des outils purement en ligne de commande, notamment à cause de la compilation statique des bibliothèques en Go, qui simplifie le déploiement.
  - [^] # Re: langue
    
    Posté par Nicolas Boulay (site web personnel) le 19 mars 2018 à 17:01. Évalué à 6.
    
    Justement, le fait que go ne fasse qu'un seul binaire sans dépendance facilite surtout la vie d'un serveur. C'est un des problèmes que voulaient régler les ingénieurs Google qui codaient avant en C++.
    
    "La première sécurité est la liberté"
    - [^] # Re: langue
      
      Posté par un_brice (site web personnel) le 21 mars 2018 à 07:18. Évalué à 6.
      
      C++ permet cela, c'est la manière dont il est utilisé à Google. En interne Go tends plutôt à remplacer Python, il est trop tôt pour dire si pytype inversera la tendance.
- [^] # Re: langue
  
  Posté par Boiethios (site web personnel) le 19 mars 2018 à 14:24. Évalué à 6.
  L'explication est que :
  - Rust est le seul des langages cités à ne pas avoir de garbage collector et surtout qui permet de facilement écrire du code sans allocations (tout sur la stack)
  - Rust permet de faire de la programmation concurrente en garantissant la non corruption de données, ce qui est très utile dans ce genre de programmes.
# Peco

Posté par Cascador (site web personnel) le 19 mars 2018 à 13:58. Évalué à 8.

ripgrep +1 ! Comme alternative à grep, j'aurais aussi parlé de peco (GitHub, Article).

Tcho !
# D'autres

Posté par anaseto le 19 mars 2018 à 14:28. Évalué à 9.

il est plus surprenant de ne pas retrouver d'outils en Go, en D, en OCaml ou en Haskell.

Le platinium searcher que tu cites (pt), est en fait écrit en Go. Il y a aussi sift en Go. En C++ il y a ucg, mais j'ai pas testé, et il y en a d'autres. Après, c'est possible en effet que ripgrep soit le plus avancé de tous ces projets, en tous cas l'auteur semble étudier la chose à fond.
- [^] # Re: D'autres
  
  Posté par Boiethios (site web personnel) le 19 mars 2018 à 17:08. Évalué à 2.
  
  Effectivement, comme le dit BurntSushi dans son article, il est le développeur de la lib Regex en Rust, réputée pour être très rapide. Je pense qu'il connaît son affaire :D
- [^] # Re: D'autres
  
  Posté par 16aR le 22 mars 2018 à 02:30. Évalué à 3.
  
  En effet, l'auteur de la dépèche à mal fait sa recherche, car des outils Go en ligne de commande, il y en a à foison.
  Perso, je suis devenu développeur Go à plein temps et j'adore, et du coup je regarde principalement des projets en Go. Mais avant d'avancer des choses comme quoi rust n'a pas d'outils du genre, j'aurais un peu cherché. (d'autant plus ironique que pt est bien en Go comme anaseto l'a fait remarquer :p)
  
  Comme outil sympa en Go, il y a https://github.com/junegunn/fzf et pleins d'autres, mais je ne vais pas les énumérer ici par manque de temps.
  - [^] # Re: D'autres
    
    Posté par Bruno Michel (site web personnel) le 22 mars 2018 à 08:48. Évalué à 9.
    
    pleins d'autres, mais je ne vais pas les énumérer ici par manque de temps.
    
    C'est dommage, ce serait intéressant de parler de ces outils dans un commentaire, ou plus ambitieux une dépêche ou un journal. Je ne demande qu'à découvrir ces outils et je suis sûr que d'autres lecteurs du site sont comme moi.
    - [^] # Re: D'autres
      
      Posté par trancheX le 12 juin 2018 à 11:19. Évalué à 1.
      C'est un peu tard mais j'ajoute mes quelque découvertes en plus de peco déjà cité par cascador, j'utilise blush qui est un grep like permettant de facilement chercher plusieurs termes et d'avoir un résultat avec des couleurs différentes pour chaque terme; il y a aussi grepp (pas testé)
      
      Et pour quelque autre outils sympa en ligne de commande en go :
      
      xsv qui est très bien comme pager de sql
      
      jsonui explorateur de json en ligne de commande, en fait j'ai joué avec mais je l'utilise jamais (rarement besoin)
      
      … je suis sûr que la liste va s'allonger, car même si Rust/C/C++ sont des langages plus système que Go (pas de GC), il est tout de même très facile de faire du système en Go (docker et u-root sont des bons exemples).
      Après même si je suis un développeur très enthousiastes de Go, j'utilise le meilleur outil quelque soit le langage utilisé pour le construire.
# colorls

Posté par kna le 19 mars 2018 à 14:33. Évalué à 4.

Comme autre alternative à ls, on peut aussi citer colorls
# J'aime pas les "alternatives"

Posté par LaBienPensanceMaTuer le 19 mars 2018 à 16:11. Évalué à 10.

Pour avoir longtemps été sysadmin, j'aime pas trop les alternatives: tu passes des jours/semaines/mois à prendre en main le nouvel outil de la mort qui tue qui va te faire gagner 0,0001 secondes pour te rendre compte qu'au boulot, aucun de ces outils n'est:
* Pré-installé par défaut.
* Installable par le gestionnaire de paquet.

Se cogner une recompilation sur ta machine perso passe encore.
Mais faire le boulot de packaging et de déploiement sur quelques centaines de serveurs pour gagner quelques pouillièmes de secondes, je vois clairement pas l'intérêt.

Et dire que, dans une ancienne boite, on était forcé de coder les scripts shell en pur /bin/sh pour être sûr qu'il s'exécute aussi bien sous Linux que sous Solaris ou AIX …

Dernière petite chose, je donnerai une mention spéciale pour fd:

il a une sortie colorée et ignore les fichiers listés dans un .gitignore

Je trouve ça grave personnellement qu'une alternative à find se permette d'ignorer des fichiers "silencieusement"…
- [^] # Re: J'aime pas les "alternatives"
  
  Posté par Cheuteumi le 19 mars 2018 à 16:24. Évalué à 0.
  
  Grave ? En quoi est-ce grave que l’outil te supprime de la sortie des fichiers présents dans une liste puisque c’est une fonctionnalité ?
  
  Si tu ne veux pas de cette fonctionnalité tu n’utilises pas l’outil. Perso c’est ce que je souhaite quand je cherche des fichiers dans un dépôt git, la plupart du temps en tout cas.
  
  Ce qui est grave c’est que l’on utilise mal des outils, ou que les fonctionnalités soient cachées et puissent induire en erreur les utilisateurs.
  - [^] # Re: J'aime pas les "alternatives"
    
    Posté par LaBienPensanceMaTuer le 19 mars 2018 à 18:12. Évalué à 10.
    
    C'est de mélanger deux concepts ("chercher des fichiers" mais "pas ceux dans le .gitignore") qui me parait être une aberration en terme ingénierie logicielle. Si encore l'outil s'était appelé "git-find", je dis pas…
    Et de ce coup, pourquoi ne pas ignorer également le contenu des fichiers .cvsignore ? .hgignore ? Pourquoi ce choix, très arbitraire ?
    
    De plus, je ne vois personnellement, je ne vois pas l'apport de cet outil dans ce use-case par rapport à un bon vieux
    
    find . -iname "toto.*.gz"|grep -vE '(.git|.swp$)'
    
    Ca me fait penser à un collègue qui, pour se simplifier la vie a définit une tonne d'alias aux commandes usuelles (genre ll="ls -l" mais en plus poussé): après quelques années d'utilisation de ces alias:
    1. Il s'y perd régulièrement.
    2. Il ne sait plus faire la différence entre "commande de base linux" et "alias maison" et pond donc régulièrement des scripts qui ne fonctionnent que sur sa machine.
    2. Il ne sait plus se servir d'un système "de base" sans son ~/.bashrc …
    
    Mais encore une fois, c'est une question de point de vue, et point de vue grandement orienté par l'usage que tu fais de l'informatique dans ton quotidien.
    - [^] # Re: J'aime pas les "alternatives"
      
      Posté par j_m le 19 mars 2018 à 21:14. Évalué à 7.
      
      De plus, je ne vois personnellement, je ne vois pas l'apport de cet outil dans ce use-case par rapport à un bon vieux
      
      find . -iname "toto.*.gz"|grep -vE '(.git|.swp$)'
      
      Ca n'a pas l'air de parser le .gitignore. Tu es sur que ca marche?
      - [^] # Re: J'aime pas les "alternatives"
        
        Posté par LaBienPensanceMaTuer le 20 mars 2018 à 09:50. Évalué à -1. Dernière modification le 20 mars 2018 à 10:07.
        
        Ah non, ça ne parse pas le .gitignore, c'était un exemple juste pour ne pas afficher la sortie de certains fichiers.
        
        Pour parser le .gitignore, ce serait plus un truc dans ce genre:
        
        /tmp/plop$ ls COINCOIN LOL LOL.gz lol.txt toto.gz /tmp/plop$ cat .gitignore toto.* lol.* LOL /tmp/plop$ find . |grep -vE $(cat .gitignore|tr '\n' '|'|sed -e 's/|$//') . ./COINCOIN ./.gitignore
        
        C'est pas hyper élégant, je pense qu'on doit pouvoir faire mieux, mais ça fait le job :)
        
        [^] # Re: J'aime pas les "alternatives"
        
        Posté par ckyl le 20 mars 2018 à 10:14. Évalué à 7.
        
        mais ça fait le job :)
        
        Non. Voir https://git-scm.com/docs/gitignore -> Pattern format.
        
        Bash étant turing complet tu vas bien finir par implémenter la gestion correcte de cette petite fonctionnalité. N'oublie pas que le .gitignore n'est pas forcément dans CWD il peut être plus haut (tu es dans un projet) ou bien plus bas et multiple (CWD ou ses fils contient plusieurs projets). Une fois que tu auras trouvé la solution tu pourras recopier ça à chaque fois que tu utilises grep. Ou alors tu mets ça dans un outils réutilisable que tu pipe mais alors ton appel standard à grep va toujours être un pipe de 3km de long alors tu vas faire un alias ou enrober ça dans un outil. Oh wait…
        
        Ensuite tu passes aux fonctionnalités suivantes comme les globing pattern, la recherche dans les fichiers compressés, la recherche multi-threadée, la gestion d'encoding .
        
        Dans une vue ops d'intervention se limiter aux outils standards est cohérent (standard pouvant varier selon les environnements on peut aller jusqu'à strictement POSIX). Les outils dont on parle sont eux parfaitement adaptés aux problématiques dev. Leur comportement par défaut correspond souvent à ce que l'on veut et les cas d'utilisations courants sont couverts avec quelques options simples plutôt que des kilomètres de pipe à base de sed | cut | awk | parallel | grep -v | variables d'environnement obscures.
        
        Et on peut facilement maitriser les deux monde si on évolue dans les deux mondes.
        
        [^] # Re: J'aime pas les "alternatives"
        
        Posté par LaBienPensanceMaTuer le 20 mars 2018 à 19:11. Évalué à 1.
        
        Ok, j'ai présumé, à tort, que le format des .gitignore consistait en une simple regexp par ligne…. My bad.
        
        [^] # Re: J'aime pas les "alternatives"
        
        Posté par Bruno Michel (site web personnel) le 20 mars 2018 à 10:22. Évalué à 7.
        
        Dans le .gitignore des projets sur lesquels je fais des recherches, il y a des commentaires, des lignes vides, des **, des / en début de ligne et des négations avec !.
        
        Ça peut ressembler à ça :
        
        # Locales **/locales/* !**/locales/en.json # Default !.gitkeep
        
        ou à ça :
        
        /cozy-stack* /debian
    - [^] # Re: J'aime pas les "alternatives"
      
      Posté par Cheuteumi le 22 mars 2018 à 22:00. Évalué à 2.
      
      find permet de supprimer des occurrences de fichiers selon un pattern… c’est toujours une aberration ?
      - [^] # Re: J'aime pas les "alternatives"
        
        Posté par Kerro le 23 mars 2018 à 20:00. Évalué à 0.
        
        Ne fait pas semblant de pas piger : find le fait uniquement lorsque tu le demandes.
        
        [^] # Re: J'aime pas les "alternatives"
        
        Posté par Cheuteumi le 23 mars 2018 à 20:06. Évalué à 5. Dernière modification le 23 mars 2018 à 20:06.
        
        De la même manière que fd permet d’ignorer le .gitignore avec -I : https://github.com/sharkdp/fd#command-line-options
        
        Je ne fais pas semblant de ne pas comprendre, je trouve insupportable que l’on vienne vomir sur des outils qui ont des paramétrages par défaut autres que les outils existants similaires, alors que ce sont des alternatives, affichées en tant que tel, et non des remplaçants.
- [^] # Re: J'aime pas les "alternatives"
  
  Posté par Bruno Michel (site web personnel) le 19 mars 2018 à 17:27. Évalué à 10.
  
  Pour avoir longtemps été sysadmin, j'aime pas trop les alternatives
  
  La plupart des admin/sys que je connais n'aiment pas les alternatives et essayent souvent de travailler avec une configuration proche de celle de base pour bash et vim. Je comprends que lorsque l'on passe souvent d'une machine à l'autre, il est plus efficace de bien connaître les outils par défaut que d'essayer d'avoir de meilleurs défauts.
  
  Je trouve ça grave personnellement qu'une alternative à find se permette d'ignorer des fichiers "silencieusement"…
  
  Mais find lui-même se permet d'ignorer des fichiers silencieusement : par défaut, il ne suit pas les liens symboliques et il saute les deux premières entrées de tous les répertoires (en général, c'est . et .., mais pas sur tous les systèmes de fichiers).
  - [^] # Re: J'aime pas les "alternatives"
    
    Posté par Kangs le 19 mars 2018 à 19:59. Évalué à 2.
    
    de travailler avec une configuration proche de celle de base pour bash et vim
    
    Perso, pour avoir un environnement bash/ksh et une configuration vim sous linux qui me va, j'ai un tar.gz que je copie systématiquement, une fois extrait j'ai un script que je source. C'est pratique et permet de facilement s'y retrouver.
    
    Le plus chiant c'est quand on change de client et d'OS, il y a toujours de petites adaptations à effectuer.
- [^] # Re: J'aime pas les "alternatives"
  
  Posté par Matthieu Moy (site web personnel) le 19 mars 2018 à 18:39. Évalué à 2.
  
  Solution à tous tes problèmes : git grep. C’est installé sur toutes les machines bien administrées, non ;-) ?
  
  Plus sérieusement, en temps que sysadmin je comprends ta position. Mais en temps que développeur ce sont des outils relativement faciles à installer (et là j'enlève le smiley sur le fait que git grep doit être présent, si c'est pas lui c'est hg grep), et c'est bien plus que 0,0001 seconde de gagnée d'avoir un outil qui ignore les fichiers générés (c'est long de chercher du texte dans des .o et .so, et c'est pénible d'avoir des matchs dans les *~ et autres fichiers de backups !).
- [^] # Re: J'aime pas les "alternatives"
  
  Posté par dinomasque le 20 mars 2018 à 10:01. Évalué à 8.
  
  Tu as bien raison, c'est comme ces clones alternatifs d'UNIX développés par des hippies communistes.
  C'est même pas supporté par le constructeur des serveurs et stations propriétaires.
  
  Franchement, ces jouets n'ont aucun avenir face à AIX, IRIX, HP-UX, Solaris, SCO UNIX, …
  
  ;-)
  
  BeOS le faisait il y a 20 ans !
  - [^] # Re: J'aime pas les "alternatives"
    
    Posté par LaBienPensanceMaTuer le 20 mars 2018 à 19:12. Évalué à 4.
    
    GNU/Linux a réellement apporté quelque chose face à ses concurrents propriétaires: gratuité, ouverture du code source, dynamisme, communauté.
    Les apports des alternatives évoquées dans ce journal ne me semble pas suffisant pour que je m'y intéresse. Encore une fois, cela ne représente que mon point de vue …
- [^] # Re: J'aime pas les "alternatives"
  
  Posté par Psychofox (Mastodon) le 20 mars 2018 à 10:48. Évalué à 4.
  
  Je suis sysadmin, je suis à priori d'accord avec toi. Sauf que :
  -dans le temps ça se faisait beaucoup de monter son home depuis un nfs et pouvait retrouver tous les petits outils compilés aux petits oignons en un instant. Ça ne se fait plus trop (perso j'aimais pas parce que si le nfs était down tu l'avais dans le cul) mais il est toujours possible d'avoir un nfs séparé du home pour surcharger optionnellement les profiles shells et accéder à des outils supplémentaires.
  -tout admin qui se respecte et a plus d'une poignée de machines à gérer utilise maintenant un système de gestion de configuration (ansible, puppet, salt, chef…) qui lui permet de déployer le profile de son utilisateur ainsi que des binaires sur l'ensemble du parc.
  -tout admin qui se respecte et a plus d'une poignée de machines à gérer dispose au moins d'un dépot yum/apt/whatever pour publier ses propres paquets et les installer ou bon lui semble.
  
  Le plus dur au final c'est pas de pouvoir ou pas déployer des outils et les utiliser, mais plutôt de se mettre d'accord entre x ingénieurs pour ne pas faire le même boulot x fois.
  - [^] # Re: J'aime pas les "alternatives"
    
    Posté par Bruno Michel (site web personnel) le 20 mars 2018 à 12:23. Évalué à 9.
    
    -tout admin qui se respecte et a plus d'une poignée de machines à gérer utilise maintenant un système de gestion de configuration (ansible, puppet, salt, chef…) qui lui permet de déployer le profile de son utilisateur ainsi que des binaires sur l'ensemble du parc.
    
    Les admins que je connais gèrent plusieurs parcs (un ou plusieurs pour le boulot, un pour leurs serveurs à eux, un ou plusieurs pour des associations, etc.), avec parfois différents outils de gestion de configuration et différentes distributions Linux ou BSD. Ça n'aide pas pour déployer partout les mêmes outils et configurations. Et même quand il y a un seul parc, ils n'aiment pas déployer dessus des choses qui ne sont pas strictement nécessaires.
  - [^] # Re: J'aime pas les "alternatives"
    
    Posté par LaBienPensanceMaTuer le 20 mars 2018 à 19:10. Évalué à 1.
    
    Et comme je le disais "j'ai longtemps été sysadmin" mais je ne le suis plus… j'ai "changé de bord" avant l'arrivé de Ansible, puppet & co.
    
    Après, même si installer un outil se résume à un apt-get install, je me serai mal vu le faire sur les 800 serveurs que je co-administrais :)
- [^] # Re: J'aime pas les "alternatives"
  
  Posté par djano le 04 avril 2018 à 05:49. Évalué à 3.
  
  Mais faire le boulot de packaging et de déploiement sur quelques centaines de serveurs pour gagner quelques pouillièmes de secondes, je vois clairement pas l'intérêt.
  
  Pourtant linuxbrew a l'air sympa.
  
  Si tu n'en vois pas l'intérê, c'est peut-être simplement que tu n'as pas le besoin de ces outils?
# grep et find

Posté par David Marec le 19 mars 2018 à 20:03. Évalué à 10.

[Grep] réalise par défaut une recherche récursive dans les répertoires (un gros manque de GNU grep selon moi … )

Quel est le problème avec l'option -R de grep ? Que cela ne soit pas une option par défaut ?
- il suffirait de faire un alias de grep vers grep -r -

Cela dit que grep fasse cela par défaut serait gênant.
D'abord, parce que grep va perdre du temps à parcourir dans la hiérarchie même si on n'en a pas besoin;
ensuite, je combine souvent grep et find pour sélectionner les fichiers (ou plutôt leur type) à traiter.
- [^] # Re: grep et find
  
  Posté par Bruno Michel (site web personnel) le 20 mars 2018 à 09:37. Évalué à 5.
  Effectivement, grep et ses alternatives peuvent être utiliser dans plusieurs contextes. Personnellement, je l'utilise principalement selon ses 3 formes :
  1. Je travaille dans une base de code (disons, celle de LinuxFr.org), je suis le plus souvent à la racine du dépôt et je veux chercher un nom de fonction, de variable, un texte que je veux modifier, etc. dans les fichiers versionnés. Avec ripgrep, c'est facile, c'est rg foo. L'équivalent avec grep, ça doit être quelque chose comme grep -r --color --exclude log/ --exclude tmp/ --exclude uploads/ foo ..
  2. Je cherche un motif dans un fichier ou répertoire donné (souvent pour retrouver un fichier config dans /etc dont je me rappelle une entrée mais pas le nom du fichier). Avec ripgrep, ça donne rg menu_entry /etc. Avec grep, c'est quasiment pareil : grep -r --color menu_entry /etc.
  3. Enfin, je peux vouloir filtrer la sortie d'une ligne de commande. Avec ripgrep ou grep, pas vraiment de différence, cozy-stack instances ls | [rg|grep] _test | xargs cozy-stack instances rm.
  J'ai pendant un temps eu un alias de grep pour faire grep -r --color=auto et avec ça, les cas d'usage 2 et 3 sont équivalents en termes de ligne de commande. Ripgrep est plus rapide, ça peut jouer un peu pour le cas d'usage 2. Je préfère la façon dont ripgrep affiche les résultats, mais les goûts et les couleurs, c'est très subjectif. Pour moi, la vraie différence est sur le cas d'usage 1 : c'est le besoin que je rencontre le plus souvent (je suis développeur) et ripgrep m'apporte un vrai confort. Même avec l'alias de grep, je suis obligé d'exclure les fichiers listés dans le gitignore et d'indiquer le répertoire dans lequel je veux chercher (ripgrep prend le répertoire courant par défaut). Ça m'est arrivé un paquet de fois de taper grep foo et d'attendre pendant plusieurs secondes bêtement pour juste me rendre compte que j'avais oublié de préciser de chercher dans le répertoire courant.
  
  Cela dit que grep fasse cela par défaut serait gênant.
  
  Je peux rater quelque chose, mais à mes yeux, ce n'est gênant que parce que grep existe depuis longtemps, qu'il a été utilisé de plein de manières différentes et que changer le comportement par défaut va casser certains scripts dans des cas particuliers difficiles à identifier à l'avance.
  
  D'abord, parce que grep va perdre du temps à parcourir dans la hiérarchie même si on n'en a pas besoin;
  
  Dans quel cas ça arriverait ? Dans les 3 cas d'usage ci-dessus, grep sans l'alias a cherché dans les mêmes fichiers et répertoires que grep avec l'alias pour ajouter l'option -r (ripgrep a cherché dans un peu moins de fichiers, parce que j'ai d'autres choses que juste tmp/ et log/ dans le .gitignore, mais c'était trop long de tout mettre sur la ligne de commande de grep).
  
  ensuite, je combine souvent grep et find pour sélectionner les fichiers (ou plutôt leur type) à traiter.
  
  Moi aussi, dans le cas d'usage 3, mais je n'ai jamais eu de problème que ce soit avec l'alias de grep ou avec ripgrep à ce sujet. Tu penses à quoi ?
  - [^] # Re: grep et find
    
    Posté par gouttegd le 20 mars 2018 à 10:32. Évalué à 2.
    
    Je travaille dans une base de code (disons, celle de LinuxFr.org), je suis le plus souvent à la racine du dépôt et je veux chercher un nom de fonction, de variable, un texte que je veux modifier, etc. dans les fichiers versionnés.
    
    Juste pour info, pour ce cas d’usage particulier, il y a aussi cscope, au moins si la base de code est en C (comment ça ce n’est pas le cas de LinuxFr.org ?).
    - [^] # Re: grep et find
      
      Posté par Bruno Michel (site web personnel) le 20 mars 2018 à 12:01. Évalué à 3.
      Heu, cscope, je viens de faire un essai rapidement et ça a l'air nettement moins pratique :
      
      Ça ne fait que du C et dérivés
      
      Ça a l'air bizarre à utiliser, on ne lance pas la commande et des résultats s'affichent sur la sortie standard, mais on passe par une interface en ncurses (avec CTRL-D pour quitter, ce n'est pas super intuitif)
      
      Il construit une base de références (comme ctags) et laisse traîner un fichier cscope.out
      
      Sur une recherche, il m'a proposé de choisir entre 3 lignes vides !
      
      Je dois rater quelque chose, tu l'utilises comment ?
      - [^] # Re: grep et find
        
        Posté par gouttegd le 20 mars 2018 à 12:39. Évalué à 2.
        
        Ça a l'air bizarre à utiliser, on ne lance pas la commande et des résultats s'affichent sur la sortie standard, mais on passe par une interface en ncurses
        
        C’est le mode par défaut, mais il y a aussi une interface orientée ligne, interactive (-l) ou non (-L -Xmotif, où X indique le type de motif à rechercher).
        
        Je dois rater quelque chose, tu l'utilises comment ?
        
        D’abord, construction de l’index (à répéter de temps en temps pour avoir un index à jour — on peut aussi mettre à jour l’index à chaque invocation mais on perd un peu l’intérêt de l’outil d’après moi) :
        
        $ cscope -bqR
        
        Puis, mettons par exemple que je cherche la définition d’une fonction C donnée (l’option -d empêche la mise à jour de l’index, si on a déjà un index à jour grâce à la commande précédente) :
        
        $ cscope -d -L -1start_pinentry agent/call-pinentry.c start_pinentry 272 start_pinentry (ctrl_t ctrl)
        
        Ou que je cherche les appels à cette fonction :
        
        $ cscope -d -L -3start_pinentry agent/call-pinentry.c agent_askpin 1010 rc = start_pinentry (ctrl); agent/call-pinentry.c agent_get_passphrase 1213 rc = start_pinentry (ctrl); agent/call-pinentry.c agent_get_confirmation 1325 rc = start_pinentry (ctrl); agent/call-pinentry.c agent_show_message 1398 rc = start_pinentry (ctrl); agent/call-pinentry.c agent_popup_message_start 1468 rc = start_pinentry (ctrl); agent/call-pinentry.c agent_clear_passphrase 1577 rc = start_pinentry (ctrl);
        
        (Dans certaines bases de code, grep ou n’importe quel programme similaire pourrait aussi faire la distinction entre la définition d’une fonction et ses appels, parce que certains projets utilisent la convention suivante pour définir une fonction :
        
        void ma_fonction (void)
        
        où le nom de la fonction est toujours en début de ligne. Mais ce n’est pas une convention universelle — et ça ne marche que pour les définitions de fonction.)
  - [^] # Re: grep et find
    
    Posté par Jean-Max Reymond (site web personnel) le 20 mars 2018 à 12:03. Évalué à 1.
    
    Je travaille dans une base de code (disons, celle de LinuxFr.org), je suis le plus souvent à la racine du dépôt et je veux chercher un nom de fonction, de variable, un texte que je veux modifier, etc. dans les fichiers versionnés. Avec ripgrep, c'est facile, c'est rg foo. L'équivalent avec grep, ça doit être quelque chose comme grep -r --color --exclude log/ --exclude tmp/ --exclude uploads/ foo ..
    
    Dans ce cas, tu as glimpse avec lequel j'ai longtemps travaillé dans les fichiers sources d'AIX. C'est ultra-performant, pour ne pas dire instantané et cela remplit les mêmes fonctions que grep.
    - [^] # Re: grep et find
      
      Posté par Bruno Michel (site web personnel) le 20 mars 2018 à 12:07. Évalué à 3.
      
      OK, je suppose que ça ne doit pas être ce glimpse là : http://getglimpse.com/. Tu aurais un lien ?
      
      D'un point de vue fonctionnel, quitte à installer un nouveau paquet, pourquoi installer glimpse plutôt que ripgrep ? Qu'est-ce qu'il apporte de plus ?
      - [^] # Re: grep et find
        
        Posté par Jean-Max Reymond (site web personnel) le 26 mars 2018 à 10:49. Évalué à 1.
        
        http://webglimpse.net/
        
        Fonctionnellement, il fonctionne comme locate/updatedb, c'est à dire qu'on fait une recherche dans une base de données déjà constituée plutôt que le faire dynamiquement d'où l'extrême performance
        
        [^] # Re: grep et find
        
        Posté par barmic le 04 avril 2018 à 09:30. Évalué à 2.
        
        Pour des fichiers sources, tu as déjà une base de données avec ton gestionnaire de version. Git a par exemple git grep et git ls-files.
- [^] # Re: grep et find
  
  Posté par EdB le 20 mars 2018 à 11:33. Évalué à 2.
  
  j'aime bien qu'il ne le fasse pas par défaut. Ça me permet de taper grep -irl 🙂
- [^] # Re: grep et find
  
  Posté par Yth (Mastodon) le 20 mars 2018 à 11:44. Évalué à 2.
  
  alias sgrep='grep -rsI --exclude .svn/ --exclude .hg/ --exclude .git/'
  sgrep pour source-grep.
  J'ai même lgrep pour --color=always, et slgrep pour un sgrep en couleur.
  |é avec un less -R et on a de la couleur.
  
  Je l'ai depuis des années mon git grep qui marche aussi avec subversion ou mercurial.
  Je suis d'accord avec toi, le comportement par défaut c'est bien, les alias pour un comportement spécifique voire complexe, c'est mieux que de réinventer la roue pour en changer la couleur.
  
  Yth.
  - [^] # Re: grep et find
    
    Posté par Bruno Michel (site web personnel) le 20 mars 2018 à 12:13. Évalué à 6.
    
    Non, ça ne fait pas la même chose. Un git grep, ça ignore le répertoire .git mais aussi tous les fichiers et répertoires listés dans le .gitignore, et c'est quasiment toujours ce que je veux.
    
    Quand je travaille sur un projet avec du JS, il y a toujours plein de trucs dans les node_modules et ça fait des correspondances qui ne m'intéressent pas quand je fais une recherche. Quand je travaille sur LinuxFr.org, c'est les avatars uploadés (des fichiers binaires) qui faisaient parfois des correspondances dont je ne veux pas sur des recherches. Quand je travaille sur cozy-stack, c'est le répertoire storage que je veux ignorer. Etc.
    
    Il n'y aurait besoin que d'ignorer des répertoires connus à l'avance, un alias me suffirait bien. Mais ripgrep m'apporte plus que ça.
    - [^] # Re: grep et find
      
      Posté par Yth (Mastodon) le 20 mars 2018 à 12:28. Évalué à 2.
      
      Ouais, ok, mais node c'est un monde un peu à part de ce côté là.
      Et j'ai la chance de ne pas avoir trop à y toucher :)
      
      C'est sûr que le jour où mon alias sera insuffisant, je chercherait autre chose, et je serais content que quelqu'un ait codé un truc qui marche bien.
      
      On s'éloigne un peu du ripgrep qui fait grep -r par défaut, ce qui changerait la vie, et on entre dans des cas plus complexe pour lesquels grep n'a bien sûr jamais été pensé.
      
      Yth.
    - [^] # Re: grep et find
      
      Posté par Matthieu Moy (site web personnel) le 20 mars 2018 à 23:15. Évalué à 6.
      
      Un git grep, ça ignore le répertoire .git mais aussi tous les fichiers et répertoires listés dans le .gitignore, et c'est quasiment toujours ce que je veux.
      
      Plus précisément : ça ne cherche que dans les fichiers trackés par Git. En général, ce sont tous les fichiers sauf ceux ignorés par un .gitignore, mais on peut tout à fait tracker des fichiers qui sont dans .gitignore (git add -f), et avoir des fichiers non-trackés et non-ignorés (ceux qui apparaissent dans la section Untracked files) de git status.
      
      Bref, si on veut reproduire ça avec des scripts et sans git grep, le plus proche serait un truc à base git ls-files | xargs grep, mais pas un script qui parse .gitignore.
# fzf

Posté par Dimitri Merejkowsky (site web personnel) le 19 mars 2018 à 21:15. Évalué à 3. Dernière modification le 19 mars 2018 à 21:16.

En go il y fzf, un "fuzzy finder" qui a l'avantage d'être utilisable à fois dans le terminal et dans (neo)vim.
- [^] # Re: fzf
  
  Posté par Bruno Michel (site web personnel) le 20 mars 2018 à 10:25. Évalué à 3.
  
  Ça fait plusieurs fois que je vois passer fzf et fzy et que je me dis que je devrais tester. Un avis sur pourquoi utiliser l'un plutôt que l'autre ?
  - [^] # Re: fzf
    
    Posté par anaseto le 21 mars 2018 à 14:05. Évalué à 3.
    
    fzf a plus de fonctionnalités, dont le support Unicode (ou alors fzy a un bug chez moi), et j'ai remarqué à l'utilisation que fzy attend de recevoir toute l'entrée, alors qu'avec fzf on peut commencer à taper le motif et ça filtre au fur et à mesure que l'entrée se complète, ce qui peut se faire sentir dans des cas comme locate / | fzy (cas un peu limite, mais bon).
  - [^] # Re: fzf
    
    Posté par jerome (site web personnel) le 18 avril 2018 à 19:48. Évalué à 1.
    
    Les deux ont l'air plus ou moins équivalents.
    
    Comme l'un est écrit en go et l'autre en ruby, j'utilise fzf.
    
    L'intégration dans vi est un plaisir, que ce soit pour chercher un fichier, un motif ou un buffer ouvert puis l'ouvrir sur place ou dans un split.
    
    Ça marche vite et bien. Et le code de fzf.vim est très court, ce qui n'est pas pour me déplaire.
    
    J'aime bien les projets de Junegunn, l'auteur de fzf. Tout autant que ceux de burntsushi, celui de ripgrep.
    
    <3
- [^] # Re: fzf
  
  Posté par copapa le 20 mars 2018 à 13:30. Évalué à 4. Dernière modification le 20 mars 2018 à 13:31.
  
  Autre avantage de fzf, il est possible de l'interfacer avec un raccourci clavier à son shell.
  
  https://github.com/junegunn/fzf#key-bindings-for-command-line
  
  En tapant
  vim ^Tcv texil me propose les fichiers qui correspondent (en mode fuzzy find, ici "vim perso/cv/cv.tex"), plus qu'à sélectionner celui que je veux avec les flèches (ou ^ J et ^ K) et valider avec entrée pour retrouver ma ligne de commande complétée.
  
  Possibilité également d'utiliser Tab pour sélectionner plusieurs fichiers qui seront tous insérés dans la ligne de commande. Il est même possible de sélectionner avec la souris.
  
  Dernier point indispensable, la recherche dans l'historique du shell en remplaçant ^ R. quand je me retrouve dans un bash par défaut (sans même ^ S pour rechercher en avant quand j'ai été trop vite :() je pleure un peu.
  
  bonus : cumuler rg et fzf pour rechercher dans les fichiers en mode fuzzy puis ouvrir la ligne sélectionnée dans l'éditeur : http://owen.cymru/sf-a-quick-way-to-search-for-some-thing-in-bash-and-edit-it-with-vim-2/
# Commentaire supprimé

Posté par Anonyme le 19 mars 2018 à 21:52. Évalué à 4.

Ce commentaire a été supprimé par l’équipe de modération.
# htop

Posté par Gof (site web personnel) le 20 mars 2018 à 16:18. Évalué à 10.

Une autre alternative que j'utilise c'est htop au lieu de top
# Alternatives à d'autres softs

Posté par kna le 20 mars 2018 à 18:16. Évalué à 7.

Pendant qu'on y est :
* mosh en alternative au client ssh
* shoop en alternative à scp
* httpie en alternative à curl
* mycli en alternative au client mysql
- [^] # Re: Alternatives à d'autres softs
  
  Posté par foobarbazz le 17 avril 2018 à 17:42. Évalué à 1.
  
  j'utilise souvent ack à la place de grep.
  https://beyondgrep.com/
  - [^] # Re: Alternatives à d'autres softs
    
    Posté par Lutin le 18 avril 2018 à 08:03. Évalué à 2.
    
    Pareil, j'essaye de passer à ag mais c'est pas facile, je vais sûrement finir par mettre un alias ag=ack, ce que j'avais fais avec grep quand j'ai commencé à utiliser ack.
# PAs très accueillant chez exa

Posté par Mes Zigues le 24 mars 2018 à 19:18. Évalué à -5.

"If your OS isn’t listed here, then you’ll have to download and install the binary yourself. Such is life."

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.