Journal fzf et mon terminal

Posté par  . Licence CC By‑SA.
Étiquettes :
9
10
mai
2021

Je suis un fanatique de la cli et par cli j'entends bien l'utilisation de ligne de commandes. En effet j'utilise très peu d'outils curse (vim et htop principalement). Je sais que ça fait rêver certains, mais moi je déteste même l'autocomplétion de zsh via un menu.

Outre le coté purement subjectif de ce que l'on aime ou pas, il y a une raison tout à fait objective. La cli est répétable et scriptable ce qui ne fonctionne généralement pas bien dès qu'on utilise du curses.

Néanmoins, même si j'utilise principalement des outils assez vieux (rxvt, vim, les binutils) j'aime bien regarder les nouveautés et voir comment elles peuvent m'aider. C'est par contre plutôt rare qu'un outil arrive à se frayer un chemin jusqu'à mon terminal. J'ai souvent l'impression que les nouveaux outils sont fait pour s'éviter un alias ou une fonction de terminal voir ne sont pas du tout fait pour de la cli.

Vous me voyez venir, c'est le cas de fzf dont je n'ai jamais trouvé l'utilité. Je suis tombé récemment sur un billet : Improving shell workflows with fzf qui m'a un peu plus fait réfléchir et j'ai trouvé un usage sympa à fzf !

Je m'en vais vous l'expliquer, qui sait, peut être que ça inspirera certains.

Je passe pas mal de temps à lancer des commandes depuis un même dossier :

% cmd foo/bar/bar
% cmd foo/foo/foo/foo
% cmd baz
…

(les commandes ne se suivent pas particulièrement ce sont des exemples qui sont tout à fait séparés)

Naviguer à coup de tab dans cette arborescence et assez fastidieuse même si tout à fait faisable. La solution classique avec fzf c'est bien quelque chose du genre (je dis bien du genre ça doit être raffiné) :

% cmd $(print -l **/*(/) | fzf)

On obtiens la liste des dossiers, il ne reste qu'à la filtrer et sélectionner celui qui nous intéresse et c'est bon.

Mais pas pour moi. En effet j'ai besoin de répéter plusieurs fois l'opération sur un même dossier, là où actuellement mon historique de commande me permet de simplement faire un rappel (!cmd), je dois de nouveau chercher mon dossier à chaque fois :(

Sauf avec une petite idée qui vient de zsh (je ne connais pas l'équivalent pour bash) : print -z

L'option -z permet d'écrire dans la prochaine invite de commande. Ainsi on peut se créer une commande qui en l'absence de chemin, va lancer fzf pour le trouver, mais au lieu de lancer la commande une fois que le chemin sera trouver, il l'imprime sur la prochaine invite.

% cmd
# recherche avec fzf
% cmd foo/bar

Et il suffit de valider cette dernière. Je trouve que ça permet de garder un workflow très cli tout en ayant quelque chose de plus sympa pour sélectionner.

  • # curses

    Posté par  (site Web personnel) . Évalué à 4 (+2/-0).

    En effet j'utilise très peu d'outils curse (vim et htop principalement).

    J’ai compris ce que tu voulais dire, mais c’est juste pour souligner que vim n’utilise pas curses/ncurses (et je croyais que htop non plus, mais apparemment si).

    • [^] # Re: curses

      Posté par  . Évalué à 4 (+2/-0).

      Tu as raison je voulais du du type curse, c'est à dire qui redessine l'ensemble du terminal et chope des entrées utilisateur.

      • [^] # Re: curses

        Posté par  . Évalué à 2 (+0/-0). Dernière modification le 10/05/21 à 23:33.

        TUI quoi? Hum… d'ailleurs, tu as essayé d'utiliser sed pour éditer tes fichiers? Ou bien ed, peut-être? Je suis curieux.

        • [^] # Re: curses

          Posté par  . Évalué à 2 (+0/-0).

          Non je ne suis pas contre par principe, c'est juste que dans la plupart de mes usages je privilégie. Après y avoir repenser j'utilise aussi less par exemple et tu me le fera pas abandonner facilement.

          • [^] # Re: curses

            Posté par  . Évalué à 3 (+1/-0).

            Je vois.

            La cli est répétable et scriptable ce qui ne fonctionne généralement pas bien dès qu'on utilise du curses

            Du coup, tu considères que les outils comme fdisk rentrent dans les TUI ou non? (à noter qu'il existe sfdisk en pure CLI et que je préfère largement, mais je le soupçonne moins connu, ainsi que cfdisk (découvert à l'instant pour raison de typo) qui est clairement un TUI)
            Parce que si oui, une partie de tes outils sont scriptables via, par exemple, expect.

            Idéalement, je préfère le GUI au TUI, sauf si j'ai besoin de pouvoir faire tourner l'appli sur une machine distante. Et pour traiter de grosses quantités d'informations une fois, je préfère les UI au CLI. Quand j'ai besoin d'automatiser ou de reproduire, j'utilise l'UI pour identifier les données et les actions à effectuer, ainsi que pour tester rapidement si j'arrive au résultat escompté, et ensuite j'utilise la ligne de commande pour faire mon script.
            Pour de petites tâches ponctuelles, la CLI est effectivement souvent ce que je vais utiliser.

            D'ailleurs, c'est bien pour ça que j'aime zsh: "cd d/p/t" -> "cd devel/projects/tools" est devenu vital pour moi. Une seule tab, pas d'addon. Simple (histoire de parler un peu du nal quand même).

            • [^] # Re: curses

              Posté par  . Évalué à 2 (+0/-0).

              Du coup, tu considères que les outils comme fdisk rentrent dans les TUI ou non?

              Yep, mais j'en ai pas un usage assez fréquent pour que ce soit une contrainte pour moi.

              Note que ça n'est pas non plus une règle d'or ni même une forme de concours. J'utilise pas mal ipython par exemple.

              Parce que si oui, une partie de tes outils sont scriptables via, par exemple, expect.

              Et avec les terminaux virtuels tout est scriptable, mais ça demande un effort important.

              Ce que j'aime bien, c'est de pouvoir faire des actions manuellement puis une fois que je les ai répété 2 ou 3 fois finir par faire des trucs du type :

              !make && !rsync

              C'est très pratique parce que tu groupe les attentes et tu t'évite 2 points de synchro :)

              Et pour traiter de grosses quantités d'informations une fois, je préfère les UI au CLI.

              Pour traiter de grosses quantité d'information, je n'ai pas vraiment le choix ce sera forcément en CLI :

              • soit parce que ma connexion m'oblige à exécuter mes traitements localement aux données
              • soit parce que les UI qui sont capables de traiter de telle quantité sont un plus relou à utiliser que quelques grep/sed/awk/jq

              Néanmoins je trouve effectivement que je gagnerais à avoir quelque chose pour gérer de gros volume. Notamment je pourrais grapher ce serait cool.

              D'ailleurs, c'est bien pour ça que j'aime zsh: "cd d/p/t" -> "cd devel/projects/tools" est devenu vital pour moi. Une seule tab, pas d'addon. Simple (histoire de parler un peu du nal quand même).

              J'ai un peu du mal avec ça. J'utilise beaucoup plus autojump. En fait je connais généralement moins le chemin que le dossier final et donc je lancerais plutôt j tools.

              • [^] # Re: curses

                Posté par  . Évalué à 2 (+0/-0).

                Ce que j'aime bien, c'est de pouvoir faire des actions manuellement puis une fois que je les ai répété 2 ou 3 fois finir par faire des trucs du type :

                !make && !rsync

                Je comprend, je fais la même.

                soit parce que ma connexion m'oblige à exécuter mes traitements localement aux données

                Pas faux. Je pense que je n'avais pas en tête un niveau de volumétrie aussi élevé.

                soit parce que les UI qui sont capables de traiter de telle quantité sont un plus relou à utiliser que quelques grep/sed/awk/jq

                Plus un problème d'UI mal foutue qu'autre chose?

                Enfin, je pensais surtout à des trucs comme des listes de paquets. Genre, Debian semble me proposer 115000 paquets (oui, pour moi, 115K c'est beaucoup), dont 1470 sont installés. Je me vois très, très mal manipuler ça à la main, mais d'un autre côté, les GUI que j'ai trouvées quand je cherchais étaient à la ramasse.
                Du coup, c'est un TUI dont l'interface est plutôt bien foutue (bien que largement perfectible): aptitude qui me permets de faire le job.

                Des outils comme regedit ou son pendant libre (le truc qui gère les BDD gconf, la…) par contre c'est très pourri, manipuler directement le dump texte en CLI sera plus efficace.
                Pour la manipulation des fichiers, c'est à dire aperçu, déplacement, etc… je ne suis satisfait ni par les explorateurs graphiques que j'ai utilisés, ni par zsh, mais j'utilise ce dernier parce que le moins pire. Quant à mc, dosshell et consort, ce sont à mon avis les pires outils pour faire le job, le moins bon de la CLI et de la GUI réunis.

                J'ai un peu du mal avec ça. J'utilise beaucoup plus autojump. En fait je connais généralement moins le chemin que le dossier final et donc je lancerais plutôt j tools.

                question de façon de fonctionner j'imagine. J'essaie d'avoir une arbo thématique, du coup c'est assez simple de m'y retrouver, mais c'est spécifique aux personnes ce genre de choses.

                • [^] # Re: curses

                  Posté par  . Évalué à 2 (+0/-0).

                  Désolé je suis passé à coté de ta réponse.

                  Plus un problème d'UI mal foutue qu'autre chose?

                  Non, il existe GUI très bien faite. Des gens qui manipulent d'énormes quantité de données ça existe, mais ça demande à sortir des artilleries assez lourdes et j'ai du mal à bloquer du temps pour m'y mettre. Je pense en particulier à ELK (avec ou sans L en fait). Il faut que je vois comment importer mes données sans trop me prendre la tête, mais je sais que kibana peu remplir tous mes besoins de traitements (il peut même simplifier des choses qui sont un peu chiantes à faire en CLI comme grapher).

                  Enfin, je pensais surtout à des trucs comme des listes de paquets. Genre, Debian semble me proposer 115000 paquets (oui, pour moi, 115K c'est beaucoup), dont 1470 sont installés. Je me vois très, très mal manipuler ça à la main, mais d'un autre côté, les GUI que j'ai trouvées quand je cherchais étaient à la ramasse.
                  Du coup, c'est un TUI dont l'interface est plutôt bien foutue (bien que largement perfectible): aptitude qui me permets de faire le job.

                  Je comprends, j'ai des usages assez trivial personnellement.

                  Pour la manipulation des fichiers, c'est à dire aperçu, déplacement, etc… je ne suis satisfait ni par les explorateurs graphiques que j'ai utilisés, ni par zsh, mais j'utilise ce dernier parce que le moins pire.

                  Je ne peux pas parler pour le graphique, mais tu saurais dire ce qui coince avec zsh ?

                  J'ai un peu du mal avec ça. J'utilise beaucoup plus autojump. En fait je connais généralement moins le chemin que le dossier final et donc je lancerais plutôt j tools.

                  question de façon de fonctionner j'imagine. J'essaie d'avoir une arbo thématique, du coup c'est assez simple de m'y retrouver, mais c'est spécifique aux personnes ce genre de choses.

                  Ce qui me paraît évident un jour ne l'est plus le lendemain, je me retrouve à devoir lister à chaque étape du chemin pour m'y retrouver. J'aime bien les complétions complètes du coup au lieu d'avoir une complétion dossier par dossier j'ai une complétion qui propose immédiatement jusqu'aux feuilles de l'arbo

                  • [^] # Re: curses

                    Posté par  . Évalué à 2 (+0/-0).

                    Désolé je suis passé à coté de ta réponse.

                    Pas de problème, je me log de moins en moins souvent aussi :)

                    Plus un problème d'UI mal foutue qu'autre chose?

                    Non, il existe GUI très bien faite.

                    C'est justement ce que je voulais dire, certaines UIs sont bien foutues, j'utilise par exemple gparted, qu'il me semble difficile de dire plus difficile à utiliser que fdisk ou parted ou…
                    Toutes les UIs ne sont pas mal branlées, loin de la, mais j'ai l'impression que c'est le cas de beaucoup, que l'on ait à traiter de grosses quantités de données ou pas (typiquement, gparted ne manipule pas grand chose…).

                    Si «les UI qui sont capables de traiter de telle quantité sont un plus relou à utiliser que quelques grep/sed/awk/jq» je ne crois pas que ça soit à cause du fait que ce soient des UI, juste qu'elles sont soit pas assez souples (la CLI, étant un langage de programmation, sera toujours plus souple que les [TG]UI, à moins d'implémenter un langage de programmation visuel, mais ça risque d'être galère à utiliser) soit mal foutues (aptitude en ncurses est de loin supérieur à tout ce que j'ai pu utiliser en graphique, clairement)

                    Je ne peux pas parler pour le graphique, mais tu saurais dire ce qui coince avec zsh ?

                    Trier un dossier en ligne de commandes, c'est pénible à mes yeux. Construire la ligne de commande avec zsh est raisonnablement rapide, mais ça reste "laborieux" et je rêve parfois d'un frontal shell qui me permette d'avoir un «mode visuel» à la vim pour aller sélectionner des entrées. Je sais que zsh implémente énormément de choses au niveau auto-complétion, mais il faut tout configurer (d'ailleurs il faut que je refasse ma conf moi…) au travers d'un menu type printf/scanf, ce qui n'est pas le plus ergonomique au monde, il faut bien l'avouer.

                    Ce qui me paraît évident un jour ne l'est plus le lendemain,

                    bien ce que je dis:

                    question de façon de fonctionner j'imagine

                    Chez moi ça marche, mais ça ne veut pas dire que ça marcherais pour tout le monde.

        • [^] # Re: curses

          Posté par  . Évalué à 2 (+1/-0).

          Ed c'est bien, j'en bouffe régulièrement car ça me permet de rester « focus » !
          Je me rabat sur Ex quand mon épicier n'est pas disponible. Un peu comme Joy finalement…

          • [^] # Re: curses

            Posté par  (site Web personnel) . Évalué à 3 (+1/-0).

            quand mon épicier n'est pas disponible

            car il a des ^W^W épices partout ? :-) (blague inside)

            Un peu comme Joy finalement…

            tu peux élaborer ? (j'ai pas comprite, même si je connais Joy<)

            • [^] # Re: curses

              Posté par  . Évalué à 1 (+0/-0).

              Un peu comme Joy finalement…

              tu peux élaborer ? (j'ai pas comprite, même si je connais Joy<)

              Je faisais allusion à l'iconique Bill Joy qui affirmait dans un entrevue ne pratiquement pas utiliser Ex/Vi lui-même… Voici le passage :

              REVIEW: You had said, when you were giving a demonstration earlier today, that when you are on foreign systems you use ed.

              JOY: That's right. Absolutely.

              REVIEW: You don't even try to use vi?

              JOY: I'm used to having a 24-line terminal with no ability to scroll back. The reason I use ed is that I don't want to lose what's on the screen. I used to have a Concept terminal which had eight pages of memory, like a mini-version of a window system. I just don't like to lose what's in the window. I'm looking forward to the editor that's going to be embedded in the window system Warren Teitelman is working on. Having editing functionality everywhere would be great in the same sense that it would be nice to have history everywhere.

              • [^] # Re: curses

                Posté par  (site Web personnel) . Évalué à 2 (+0/-0).

                ok, c'est le même Joy auquel je pensais :p
                Nous sommes perdus pour le commun des mortels :/ Bienvenu dans mon monde _o/

                • [^] # Re: curses

                  Posté par  . Évalué à 1 (+0/-0).

                  Nous sommes immortels ;-) mais ne tranchons pas de tête…

  • # Fish ?

    Posté par  . Évalué à 5 (+3/-0).

    Alors, j'ai peut-être mal saisi le cas d'utilisation mais… fish fait ça pas mal.

    Par défaut, il affiche la première complétion « qui marche » en gris, et en appuyant sur CTRL+F ça complète l'intégralité de la ligne (ALT+F pour le mot par mot).
    « Qui marche » ça veut dire avec des arguments qui, s'ils sont des fichiers, existent encore. Il ne rappelle pas (par défaut) une commande rm dist/ -r si le répertoire n'existe plus.
    Et si on en veut une autre, par ordre chronologique, c'est un appui sur la flèche du haut.

    C'est moins puissant que fzf, c'est évident.

    • [^] # Re: Fish ?

      Posté par  . Évalué à 4 (+2/-0).

      J'ai très peu essayé fish parce qu'il s'écarte trop d'une syntaxe de bourn shell. La seule chose (du peu que j'en ai vu) que je lui trouvais cool c'était la coloration de la ligne que l'on est entrain d'écrire, mais maintenant c'est utilisable dans zsh.

      Je viens de l'installer pour tester, je voyais pas très bien ce que c'était. Si j'ai bien compris c'est un "j'ai de la chance". J'ai pas compris comment il choisi ça (moi il me propose des trucs pas cohérent), mais j'imagine que c'est pilotable, mais je ne sais pas si c'est très pratique à configurer.

      Là c'est un peu différent, l'idée général c'est dans certains cas, si j'omets un paramètre, avoir la possibilité de le sélectionner via fzf, puis donner la commande sur la cli pour qu'elle soit effectivement dans l'historique est réutilisable comme n'importe quel autre. Je trouve que c'est un bon mélange de fzf avec un workflow classique.

      • [^] # Re: Fish ?

        Posté par  (site Web personnel) . Évalué à 1 (+0/-0). Dernière modification le 12/05/21 à 21:45.

        Le principe de fish c’est que tu n’as pas besoin de le configurer (ou seulement un minimum), et il « juste marche » comme ils disent. Dans le cas de la complétion, plus tu utilises fish et plus elle devient pertinente. Donc je te conseilles d’essayer de l’utiliser à plein temps quelques jours, et tu devrais déjà le trouver plus utile qu’après ton premier essai.

        Concernant la syntaxe, tu peux tout à fait utiliser fish comme shell par défaut pour l’utilisation interactive et continuer d’écrire et d’exécuter des scripts bash/zsh/sh. Beaucoup de gens font ça, moi aussi, et je crois bien que rien ne me fera revenir à bash ni tester zsh comme shell, par contre je n’ai pas non plus besoin de désapprendre la syntaxe de bash et d’apprendre celle de fish pour les scripts.

        • [^] # Re: Fish ?

          Posté par  . Évalué à 2 (+0/-0).

          Concernant la syntaxe, tu peux tout à fait utiliser fish comme shell par défaut pour l’utilisation interactive et continuer d’écrire et d’exécuter des scripts bash/zsh/sh.

          Je sais, je fais du bourn shell, du perl et du python alors que mon login shell est zsh, mais je ne distingue pas mon utilisation interactive et mon utilisation scriptés. Un tas de mes scripts sont des séries de commandes que j'ai tapées suffisamment de fois pour incrémentalement en faire des scripts de plus en plus sophistiqués.

          Dans le cas de la complétion, plus tu utilises fish et plus elle devient pertinente.

          C'est ce que je me suis dis quand j'ai vu à quel point il était à la rue sur un premier usage. Mais j'ai 15 ans de configuration de zsh et ça me plaît. Si (ce qui n'est pas du tout garanti), si fish peut me produire le même niveau de raffinement, je me retrouve à perdre du temps pour éviter d'avoir à configurer quelque chose que j'apprécie personnaliser.

  • # Pas compris...

    Posté par  . Évalué à 1 (+0/-0).

    J'ai relu deux fois et je n'ai pas compris….
    En quoi un ctrl-r ne serait pas suffisant ? (Pour ceux qui ne connnaisse pas, cela permet de rechercher dans l'historique via du "fuzzy matching")
    Evidemment. la premiere fois, il faut taper la commande complète, mais après, la sélection se fait super facilement

    • [^] # Re: Pas compris...

      Posté par  . Évalué à 3 (+1/-0).

      Pour ceux qui ne connnaisse pas, cela permet de rechercher dans l'historique via du "fuzzy matching"

      Sauf cas particulier ça n'est pas du fuzzy matching. Ça cherche des sous chaines là où le fuzzy cherche va être plus permissif, les caractères ne sont pas nécessairement consécutifs (on "aer" peut matcher "azerty" par exemple). fzf a des syntaxes jouer dessus si besoin.

      Evidemment. la premiere fois, il faut taper la commande complète, mais après, la sélection se fait super facilement

      Comme dis dans le journal dans le journal tu peux même aller plus vite avec des rappels (!make). Mais oui l'objectif c'est de rendre ce premier appel bien moins rébarbatif (j'ai 80 feuilles dans l’arborescence) tout en gardant la capacité d'exploiter l'historique comme d'habitude pour la suite. Le parcours de l'arborescence bien que très rapide est bien moins efficace qu'utiliser l'historique, mais il l'est bien plus que la recherche manuelle.

      C'est probablement mal expliqué, mais c'est ça qui me paraît intéressant, on a généralement d'un coté

  • # fzf le fait

    Posté par  . Évalué à 2 (+0/-0).

    En place ce fichier et ce fichier dans ${XDG_CONFIG_HOME:-$HOME/.config}/bash_completion.d/}, ça se met en place tout seul.

    Tu obtiens un fuzzy search dans l'historique (CTRL+R), dans le répertoire courant (CTRL+T), cmd /path/**<tab> et encore mille autre intégrations.

Envoyer un commentaire

Suivre le flux des commentaires

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