La complexité de la saisie de texte dans le terminal

Pourquoi la saisie de texte est compliquée dans le terminal

• En demandant sur Mastodon ce qui déroutait les gens dans le travail en terminal, un point est ressorti : « modifier une commande déjà saisie »
• Je voudrais partager pourquoi la saisie de texte dans le terminal est difficile, ainsi que quelques conseils utiles

Manque de cohérence entre les programmes

• Les différentes façons dont les programmes gèrent la saisie de texte ne sont pas cohérentes
  • Certains programmes (cat, nc, git commit --interactive, etc.) ne prennent pas du tout en charge les touches fléchées
  • Beaucoup de programmes (irb, python3, etc.) utilisent la bibliothèque readline pour fournir des fonctions de base
  • Certains programmes ne prennent en charge que des fonctions élémentaires
  • Certains programmes ont un système de saisie entièrement personnalisé

Mode 1 : état de base

• État de base dans lequel le programme se contente de recevoir la saisie de texte
  • Fournit des fonctions de base comme la saisie de texte, retour arrière, Ctrl+W, Ctrl+U, etc.
  • La commande stty -a permet de voir tous les codes Ctrl pris en charge

Mode 2 : outils utilisant readline

• readline est une bibliothèque GNU qui rend la saisie de texte plus pratique
  • Elle fournit des raccourcis utiles comme Ctrl+E, Ctrl+A, Ctrl+left/right arrow, Ctrl+R, etc.
  • De nombreux programmes comme bash, psql, irb, python3 utilisent readline

Astuce : utiliser readline avec rlwrap

• Avec rlwrap, même les programmes qui ne prennent pas en charge readline peuvent bénéficier de ses fonctionnalités

Pourquoi certains outils n'utilisent pas readline

• Parce que le programme est très simple, pour des raisons de licence, ou parce qu'il y a peu d'interaction, entre autres

Comment vérifier si readline est utilisé

• Si vous appuyez sur Ctrl+R et que reverse-i-search s'affiche, il est probable que le programme utilise readline

Origine des raccourcis clavier de readline

• Les raccourcis clavier de readline viennent d'Emacs

Mode 3 : autres bibliothèques de saisie (libedit, etc.)

• Le /usr/bin/python3 du Mac utilise libedit et ne prend donc en charge qu'une partie des fonctionnalités de readline

Mode 4 : système de saisie personnalisé

• Les éditeurs de texte comme nano, micro, vim, emacs, ainsi que des shells comme fish, ont un système de saisie personnalisé
• Les systèmes personnalisés s'inspirent souvent de readline

Beaucoup de shells prennent en charge les raccourcis vi

• bash, zsh, fish, etc. prennent en charge un « mode vi » pour la saisie de texte

Comprendre le contexte est utile

• Quand on saisit du texte à l'invite de commande, comprendre le contexte rend le comportement plus prévisible et moins déroutant

Ce que cet article n'aborde pas

• Les problèmes liés à ssh et tmux, la variable d'environnement TERM, la prise en charge du copier-coller selon les terminaux, Unicode, etc.

Résumé de GN⁺

• Explique pourquoi la saisie de texte dans le terminal est complexe et pourquoi il existe un manque de cohérence entre les différents programmes
• Présente comment des bibliothèques comme readline peuvent rendre la saisie de texte plus pratique
• Donne une astuce pour ajouter les fonctionnalités de readline avec rlwrap
• Souligne l'importance de comprendre le contexte lors de l'utilisation du terminal

[GN⁺]

Avis Hacker News

• Les articles de Julia sont toujours excellents

  • dans les scripts shell, on peut utiliser stty pour modifier la façon dont le terminal traite les entrées
  • partage une expérimentation capable de capturer et d’interpréter des combinaisons de touches et des gestes de souris sur des terminaux compatibles VT100
  • démo exécutable avec la commande bash -c "$(curl -L https://git.io/fjToH)"
  • on peut voir les séquences d’échappement VT100 des programmes interactifs avec vi | cat -v

• Éléments absents de l’article

  • caractères larges
  • différentes séquences d’échappement ANSI selon le mode clavier
  • divers états du TTY
  • appels système différents selon l’OS pour modifier l’état du TTY
  • écarts dans la prise en charge de l’émulation de terminal
  • manque de consensus sur la manière de détecter les capacités d’un terminal

• Dans bash, si $EDITOR est défini, ctrl-x ctrl-e permet d’envoyer la ligne courante à $EDITOR

• Il y a 20 ans, création d’un éditeur multiligne avec readline

  • incluait le déplacement du curseur et le redessinage lors du redimensionnement du terminal
  • envie de le réécrire en Rust et de le publier comme petite bibliothèque

• Question sur le fonctionnement de la fonction fgets()

  • fgets() se bloque par défaut jusqu’à ce que l’utilisateur saisisse une nouvelle ligne
  • on peut modifier le tampon de ligne avec les raccourcis Retour arrière, Ctrl+W, Ctrl+U

• Avis selon lequel le terminal est l’une des raisons qui limitent la part de marché de Linux

  • l’expérience d’usage du terminal est complexe

• Réponse à l’affirmation selon laquelle le shell dash ne prend pas en charge les touches fléchées

  • s’il est compilé avec libedit, il prend en charge le mode édition
  • la norme POSIX impose la prise en charge de set -o vi

• Trois raccourcis readline de base utiles à connaître

  • Ctrl+W : supprimer le dernier mot
  • Ctrl+O : exécuter la ligne suivante dans l’historique
  • Ctrl+R : recherche inversée dans l’historique

• Plaintes sur le comportement de Ctrl-C et Ctrl-V dans Windows Terminal

  • les applications de terminal Linux ne se comportent pas comme Windows Terminal

• Avis disant que cela rappelle le texte classique de Linus

  • lien