arthur.bebou

Le site arthur.bebou.netlib.re - retour accueil
index.sh (10400B)
      1 #! page
      2 title: Évaluer ses scripts en temps réel
      3 author: Arthur Pons
      4 description: Il est parfois fatiguant de faire l\'aller retour entre l\'écriture d\'une commande et son exécution. Créons, avec vim et/ou tmux des environnements permettant de fondre les deux
      5 publication: 2024-05-09
      6 
      7 sectionmd: main
      8 
      9 > ATTENTION : Ce script est vraiment dangereux, ne l'utilisez pas si vous ne
     10 > savez pas ce que vous faîtes. N'écrivez jamais de script contenant `rm` avec.
     11 > Si vous écrivez une commande qui lit dans stdin il faudra le fermer en insérant
     12 > un caractère de fin de fichier, en sortant du mode inserstion, en réinsérant un
     13 > caractère de fin de fichier puis finalement en supprimant la commande qui pose
     14 > souci. Vous êtes prévenu·es, c'est expérimental est tout cassé.
     15 
     16 ## Objectif
     17 
     18 L'objectif est d'avoir, l'un à côté de l'autre, un script et ses sorties STDERR
     19 et STDOUT, en temps réel avec une mise à jour à chaque fois que l'on modifie le
     20 script. Une interface comme celle-ci devrait permettre de faciliter l'écriture
     21 de scripts dont la sortie nous intéresse, typiquement lorsqu'il faut traiter du
     22 texte et quand itérer souvent et rapidement est souhaitable[^1]. Elle pourrait
     23 également être un bon outil pour l'enseignement de `sed`, `awk`, `paste`, `cut`,
     24 `tr` et toute la bande que j'aime bien.
     25 
     26 Il n'est pas question ici d'analyser les actions du script et d'afficher en
     27 français les impacts qu'il a eu sur le système (création/suppression de fichier
     28 etc). Il est question de faciliter l'écriture d'une commande `sed` un peu
     29 dantesque sans avoir à systématiquement exécuter le script à la main.
     30 
     31 L'idée me vient de
     32 [fzrepl](https://github.com/DanielFGray/fzf-scripts/blob/master/fzrepl) de
     33 Daniel F Gray. Je voulais quelque chose de similaire mais qui fonctionne
     34 pour une quantité arbitraire de commandes et éditable dans vim.
     35 
     36 Au passage je découvre sans l'avoir prévu que ce système me permet de résoudre
     37 d'une manière bien plus puissante qu'auparavant un problème que j'avais documenté
     38 dans ce [vieil article](/benchmarkcatium/#et-alors-), section :
     39 "L’utilisation d’éditeurs de texte s’interfaçant bien avec le système permet de
     40 tester des bouts de markdown".  En effet, si j'ouvre l'un des fichiers sources
     41 de ce site avec la configuration vim qui va suivre j'obtiens automatiquement le
     42 résultat html dans la fenêtre droite.
     43 
     44 ## Implémentation
     45 
     46 J'ai pour le moment la flemme de gérer les arguments de façon à faire des
     47 choses différentes selon si on passe un argument un script déjà existant ou
     48 pas, selon si le chemin est absolu ou relatif etc. Les scripts tels que
     49 présentés en dessous vont donc systématiquement tout créer en tant que fichier
     50 temporaire. Si à la fin de votre expérimentation vous voulez sauvegarder le
     51 script vous pouvez toujours lancer `:w votre_script.sh`.
     52 
     53 ### Avec vim tout seul
     54 
     55 Commençons d'abord par créer les fichiers qui vont contenir le script et sa
     56 sortie et rendre le script exécutable :
     57 
     58     script=$(mktemp)
     59     data=$(mktemp)
     60     chmod +x "$script"
     61 
     62 Vient ensuite l'ouverture de vim et sa configuration :
     63 
     64     vim -c "set autowrite"\
     65         -c "autocmd TextChanged * silent! !$script > $data 2>&1"\
     66         -c "autocmd TextChangedI * silent! !$script > $data 2>&1"\
     67         -c "vnew $data"\
     68         -c "set updatetime=100 | set autoread | autocommand CursorHoldI * checktime | autocommand CursorHold * checktime"\
     69         -c "wincmd h | doautocmd TextChanged"\
     70         "$script"
     71 
     72 Vim est appelé avec tout un tas de commandes suivant l'option `-c` qui
     73 s'exécuteront automatiquement au lancement.  Le denier argument est le chemin
     74 vers le script.
     75 
     76 Expliquons chacune des commandes vim :
     77 
     78   * `set aw` : le fichier sera automatiquement écrit à chaque fois qu'une
     79     commande externe sera lancée
     80   * `autocmd TextChanged * silent! !$script > $data 2>&1` : A chaque fois que
     81     le texte change en mode normal on exécute, en ignorant sa sortie et ses
     82     erreurs éventuelles (`silent!`), le script dont on redirige tout vers le
     83     fichier de sortie
     84   * Idem mais en mode insertion
     85   * `vnew $data` : on ouvre une fenêtre verticale avec le fichier de sortie
     86   * `set updatetime=100 | set autoread | autocommand CursorHoldI * checktime |
     87     autocommand CursorHold * checktime` : On modifie l'intervalle de mise à jour
     88     à 100ms, on met le buffer avec e fichier de sortie en lecture automatique
     89     (il se rafraichit à chaque changement), on force l'exécution de `checktime`
     90     à chaque première fois que le curseur ne bouge plus pendant 100ms après
     91     qu'il a bougé
     92   * `wincmd h | doautocmd TextChanged` : on revient sur la fenêtre avec le
     93     script et on déclenche une première fois l'un des évènements pour peupler
     94     le fichier de sortie (utile si l'on ouvre un script déjà existant)
     95 
     96 Finalement on affiche les chemins des deux fichiers temporaire quand on ferme
     97 vim au cas-où l'on en est besoin :
     98 
     99     echo "script : $script"
    100     echo "données : $data"
    101 
    102 Les avantages de cette version sont de ne pas dépendre de watch ni de tmux et
    103 de pouvoir parcourir la sortie dans un buffer vim avec tout ce que cela
    104 implique comme possibilité.
    105 
    106 ### Avec vim + tmux + watch
    107 
    108 Les dépendances sont :
    109 
    110   * Une version relativement à jour de vim (qui a les évènements `TextChanged*`)
    111   * tmux
    112   * watch
    113 
    114 On commence de la même manière :
    115 
    116     script=$(mktemp)
    117     data=$(mktemp)
    118     chmod +x "$script"
    119 
    120 Puis on crée la session tmux :
    121 
    122     tmux new \
    123     vim -c "set aw"\
    124         -c "autocmd TextChanged * silent! !$script > $data 2>&1"\
    125         -c "autocmd TextChangedI * silent! !$script > $data 2>&1"\
    126         -c "doautocmd TextChanged"\
    127         "$script"\
    128     \; split-window -h "watch -c -d -t -n 0.1 cat $data" \; select-pane -L
    129 
    130 Finalement on affiche les chemins en sortie de session :
    131 
    132     echo "script : $script"
    133     echo "données : $data"
    134 
    135 Les avantages sont de ne pas avoir à utiliser le hack vim un peu étrange à base
    136 de CursorHold pour que tout soit à jour, de voir ce qui a été modifié en sortie
    137 à l'aide de `-d` de watch et être directement déposé dans tmux ce qui peut se
    138 révéler utile pour retrouver votre travail plus tard. Évidemment ce dernier
    139 point n'est pas essentiel si vous avez de toute façon l'habitude d'être dans
    140 une session tmux quoi qu'il arrive.
    141 
    142 ## L'espace entre les CLI des années 80 et les GUI
    143 
    144 Au delà des raisons évoquées [en intro](/liverepl/#objectif) j'ai une autre
    145 motivation à écrire ce genre d'outils.
    146 
    147 De nombreuses critiques sont formulées envers les interfaces en ligne de
    148 commande. Même si je pense qu'elles sont parfois injustes et le fruit d'apriori
    149 culturels et techniques plus que de réelles limitations qui seraient par
    150 ailleurs inexistantes dans les autres formes d'interfaces, il convient
    151 d'admettre que l'expérience initiale dans un terminal linux est aride.
    152 [Aurélien Tabard](https://tabard.fr/) en résume bien les principales raisons :
    153 
    154 > Si la découvrabilité est en effet un point important, la gestion des erreurs
    155 > l'est tout autant. Le undo n'est pas tellement développé dans les cli, pourtant
    156 > la capacité d'essai-erreur-correction est facteur d'apprentissage important
    157 > (oui il y a des façons de se tromper élégamment dans un terminal, mais le jour
    158 > ou tu te trompes pour une raison ou une autre, le undo n'est pas là). D'autre
    159 > notions permettent comme celles de gouffre d'évaluation et d'exécution peuvent
    160 > expliquer le succès des gui. Enfin la capacité des systèmes à communiquer sur
    161 > ce qu'ils permettent de faire (voir [par exemple ce
    162 > papier](http://jovermeulen.com/Research/FeedforwardCHI2013) sur les
    163 > affordances percues et le feedforward) est peu présente dans les cli.
    164 
    165 De fait beaucoup de personnes sont introduites aux cli via des cours, des
    166 tutos, des outils ne cherchant pas à faciliter l'apprentissage et l'usage des
    167 cli et tombant la tête la première dans chacun des points soulevés par
    168 Aurélien. Personnellement j'ai fait mes premières années de shell en école
    169 d'ingénieur sans jamais savoir que l'on pouvait chercher dans l'historique des
    170 commandes avec `ctrl+r`, que beaucoup de commandes avaient des options pour
    171 lister ce qu'elles allaient faire avant de les faire, que l'on pouvait mettre
    172 beaucoup de couleurs dans les terminaux modernes, que l'existence des TUI
    173 implique que l'on puisse faire des choses comme fzy, qu'il existait des shells
    174 moins complexes que bash et avec une super auto-complétion pour un large
    175 ensemble de commande ou une simple liste, même un peu indigeste, des commandes
    176 généralement disponibles sur un Unix. J'ai le sentiment que la conséquence de
    177 cela est que de nombreuses personnes, même dans le métier, n'ont qu'une vision
    178 très limitée de ce que peuvent les cli et a fortiori des TUI qui fonctionnent
    179 dans un terminal. Il est donc naturel que la plupart des personnes perçoivent
    180 ces interfaces comme bloquées dans les années 70/80 et ne s'y tournent que pour
    181 les usages à raison catalogués comme les plus appropriés. Et pourtant on peut
    182 y mener la majorité de sa vie numérique.
    183 
    184 Attention, contrairement à l'impression que j'ai trop souvent donné lorsque je
    185 parle de ce sujet, l'idée n'est pas de tout faire dans un terminal simplement
    186 parce que je kiffe le terminal. C'est parce que l'usage de GUI modernes me
    187 pousse à changer mon matériel, à mettre de la distance entre les personnes qui
    188 produisent les logiciels que j'utilise et moi et à cloisonner mes logiciels
    189 plutôt que de les faire causer entre eux que je m'intéresse à autre chose. Ne
    190 sachant pas où me tourner pour trouver une communauté et une culture
    191 ingénieurale axées sur le développement de GUI sobres, interopérables et
    192 techniquement simples, je me tourne vers une communauté et une culture qui, la
    193 plupart du temps, regroupe toutes ces qualités, j'ai nommé celle des personnes
    194 qui vivent dans un terminal Unix.
    195 
    196 Je cherche donc, avec des outils comme celui décrit dans cet article, à montrer
    197 qu'il existe un espace entre les GUI d'aujourd'hui et les CLI des années 80
    198 dans lequel on peut aborder les points soulevés par Aurélien tout en profitant
    199 des propriétés techniques plus avantageuses pour la sobriété de nos usages du
    200 numérique.
    201 
    202 [^1]: typiquement l'écriture d'une regex un peu complexe d'où le succès d'interfaces type [regex101](https://regex101.com/)