Journal fzf et mon terminal

PostĂ© par . Licence CC By‐SA.
Étiquettes :
3
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 . ÉvaluĂ© Ă  4.

    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.

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

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

      • [^] # Re: curses

        PostĂ© par . ÉvaluĂ© Ă  2. DerniĂšre modification le 10 mai 2021 Ă  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.

          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.

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: curses

            PostĂ© par . ÉvaluĂ© Ă  3.

            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.

              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.

              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

              • [^] # Re: curses

                PostĂ© par . ÉvaluĂ© Ă  2.

                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.

                  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

                  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                  • [^] # Re: curses

                    PostĂ© par . ÉvaluĂ© Ă  2.

                    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 (site web personnel, Mastodon) . ÉvaluĂ© Ă  2.

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

          "It is seldom that liberty of any kind is lost all at once." ― David Hume

          • [^] # Re: curses

            PostĂ© par (site web personnel) . ÉvaluĂ© Ă  3.

            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 (site web personnel, Mastodon) . ÉvaluĂ© Ă  1.

              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.

              "It is seldom that liberty of any kind is lost all at once." ― David Hume

              • [^] # Re: curses

                PostĂ© par (site web personnel) . ÉvaluĂ© Ă  2.

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

  • # Fish ?

    PostĂ© par . ÉvaluĂ© Ă  5.

    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.

      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.

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

      • [^] # Re: Fish ?

        PostĂ© par (site web personnel, Mastodon) . ÉvaluĂ© Ă  1. DerniĂšre modification le 12 mai 2021 Ă  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.

          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.

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • # Pas compris...

    PostĂ© par . ÉvaluĂ© Ă  1.

    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.

      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é

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • # fzf le fait

    PostĂ© par . ÉvaluĂ© Ă  2.

    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.

Suivre le flux des commentaires

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