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/barEt 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 Anonyme . Évalué à  4.
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 barmic 🦦 . É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 freem . É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 barmic 🦦 . É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 freem . Évalué à  3.
Je vois.
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 barmic 🦦 . Évalué à  2.
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.
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 :
C'est très pratique parce que tu groupe les attentes et tu t'évite 2 points de synchro :)
Pour traiter de grosses quantité d'information, je n'ai pas vraiment le choix ce sera forcément en CLI :
Néanmoins je trouve effectivement que je gagnerais à avoir quelque chose pour gérer de gros volume. Notamment je pourrais grapher ce serait cool.
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 freem . Évalué à  2.
Je comprend, je fais la mĂŞme.
Pas faux. Je pense que je n'avais pas en tête un niveau de volumétrie aussi élevé.
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,dosshellet consort, ce sont à mon avis les pires outils pour faire le job, le moins bon de la CLI et de la GUI réunis.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 barmic 🦦 . Évalué à  2.
Désolé je suis passé à coté de ta réponse.
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).
Je comprends, j'ai des usages assez trivial personnellement.
Je ne peux pas parler pour le graphique, mais tu saurais dire ce qui coince avec zsh ?
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 freem . Évalué à  2.
Pas de problème, je me log de moins en moins souvent aussi :)
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)
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.
bien ce que je dis:
Chez moi ça marche, mais ça ne veut pas dire que ça marcherais pour tout le monde.
[^] # Re: curses
Posté par Gil Cot ✔ (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 BAud (site web personnel) . Évalué à  3.
car il a des
^W^Wépices partout ? :-) (blague inside)tu peux élaborer ? (j'ai pas comprite, même si je connais Joy<)
[^] # Re: curses
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à  1.
Je faisais allusion à l'iconique Bill Joy qui affirmait dans un entrevue ne pratiquement pas utiliser Ex/Vi lui-même… Voici le passage :
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: curses
Posté par BAud (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/
[^] # Re: curses
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à  1.
Nous sommes immortels
;-)mais ne tranchons pas de tête…“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Fish ?
Posté par Glandos . É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/ -rsi 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 barmic 🦦 . É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 Guillawme (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 barmic 🦦 . Évalué à  2.
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.
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 Ronan BARZIC . É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 barmic 🦦 . Évalué à  3.
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.
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 steph1978 . É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.