Des alternatives à grep, ls et find

Posté par  (site web personnel) . Édité par Xavier Teyssier, Davy Defaud et palm123. Modéré par Xavier Teyssier. Licence CC By‑SA.
Étiquettes :
69
19
mar.
2018
Ligne de commande

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

  • # langue

    Posté par  (site web personnel) . É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  . É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  . É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  (site web personnel) . É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  . É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.

          • [^] # Re: langue

            Posté par  (site web personnel) . É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  (Mastodon) . É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  (site web personnel) . É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  (site web personnel, Mastodon) . É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  (Mastodon) . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel, Mastodon) . É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  (site web personnel) . É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  . É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  . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . Évalué à 8.

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

    Tcho !

  • # D'autres

    Posté par  (site web personnel) . É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  (site web personnel) . É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  . É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  (site web personnel) . É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  . É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  . Évalué à 4.

    Comme autre alternative à ls, on peut aussi citer colorls

  • # J'aime pas les "alternatives"

    Posté par  . É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  . É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  . É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  . É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  . É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  . É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  (site web personnel) . É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  . É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  . É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  . É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  (site web personnel) . É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  . É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  (site web personnel) . É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  . É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  . É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  (Mastodon) . É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.

      Jami: beabb2b063da0a2f0a2acaddcd9cc1421245d5de

      • [^] # Re: J'aime pas les "alternatives"

        Posté par  (site web personnel) . É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  . É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  . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . Évalué à 3.

          Heu, cscope, je viens de faire un essai rapidement et ça a l'air nettement moins pratique :

          1. Ça ne fait que du C et dérivés
          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 (avec CTRL-D pour quitter, ce n'est pas super intuitif)
          3. Il construit une base de références (comme ctags) et laisse traîner un fichier cscope.out
          4. 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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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  . É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  . É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  (Mastodon) . É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  (site web personnel) . É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  (Mastodon) . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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  . É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 tex
      il 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  . Évalué à 4.

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

  • # htop

    Posté par  (site web personnel) . Évalué à 10.

    Une autre alternative que j'utilise c'est htop au lieu de top

  • # Alternatives à d'autres softs

    Posté par  . É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

  • # PAs très accueillant chez exa

    Posté par  . É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.