Vous remarquerez que lorsque vous exécutez catà l'invite du shell sur un terminal, catétant censé écrire sur stdout ce qu'il lit à partir de stdin, et appuyez sur a, vous voyez un aécho en retour par le pilote du terminal, mais catn'écrit pas cela a(vous voyez un seul a, celui repris par le pilote de terminal).
Cependant, si vous tapez a Backspace b Enter, vous ne voyez pas la catsortie a\010b\015, mais b\012( bet la nouvelle ligne).
C'est parce que le pilote de terminal (nous parlons de logiciel dans le noyau, pas dans l'émulateur de terminal comme xterm) implémente un éditeur de ligne très basique en mode canonique . Le pilote de terminal peut être configuré à l'aide d' ioctl()appels système comme lors de l'utilisation de la sttycommande. Par exemple, pour quitter le mode canonique, vous pouvez le faire stty -icanon. Si tu fais:
stty -icanon; cat
Ensuite, vous verrez à la fois le echo(que vous auriez pu désactiver stty -echo) et la catsortie en même temps.
Cet éditeur est un éditeur de ligne. C'est-à-dire qu'il appartient à l'utilisateur de modifier une ligne de texte jusqu'à ce qu'elle soit envoyée à l'application lisant le terminal en appuyant sur Enter.
Les capacités d'édition de cet éditeur sont très limitées. Dans la plupart des implémentations, il n'y a que 4 touches d'édition (en fait des caractères) également configurables avec stty:
- effacer (
^Hou ^?généralement): effacer le caractère précédent
- kill (
^Uhabituellement): vide (tue) la ligne entrée jusqu'ici
- werase (
^W): efface le mot précédent
- lnext (
^V): entrez littéralement le caractère suivant (annulez la signification spéciale de tout ce qui précède)
Dans le passé, on pensait que cet éditeur de ligne de pilote de terminal serait étendu avec des capacités plus sophistiquées. C'est pourquoi aucun des premiers shells n'a de capacités d'édition en ligne de commande (vous obtiendriez les mêmes capacités d'édition en ligne à l'invite du shell que lors de l'exécution catcomme nous l'avons fait ci-dessus).
Cependant, cela ne s'est vraiment jamais produit, peut-être en partie à cause du désordre avec différents terminaux qui n'envoient pas les mêmes caractères lors de certaines pressions sur les touches, ce qui rendait évident que cela ne devrait pas être implémenté dans l'espace du noyau.
Certains shells ont donc commencé à abandonner le mode canonique du pilote de terminal et à implémenter leur propre éditeur de ligne. À l'époque, emacset viétaient les éditeurs de texte visuel les plus populaires avec un mode de liaison et de fonctionnement des touches complètement différent. Dans vi, vous disposez d'un mode de saisie de texte et d'un mode d'édition. Dans emacs, vous êtes toujours en mode texte , mais l'édition se fait en appuyant sur des combinaisons de touches (comme ^bpour déplacer le caractère vers l'arrière).
Il n'y avait aucun intérêt pour les shells à l'époque à proposer leur propre liaison de clés différente. Cela aurait causé de la frustration pour les gens à devoir en apprendre un autre. Cependant, choisir un ( emacsou vi) style plutôt que l'autre aurait été un moyen sûr d'aliéner les utilisateurs de l' autre éditeur.
Selon https://www.usenix.org/legacy/publications/library/proceedings/vhll/full_papers/korn.ksh.a :
Les fonctions d'édition en ligne populaires (mode vi et emacs) de ksh ont été créées par les développeurs de logiciels des Laboratoires Bell; le mode d'édition de ligne vi par Pat Sullivan, et le mode d'édition de ligne emacs par Mike Veach. Chacun avait indépendamment modifié le shell Bourne pour ajouter ces fonctionnalités, et tous deux faisaient partie d'organisations qui ne voulaient utiliser ksh que si ksh avait leur éditeur en ligne respectif. À l'origine, l'idée d'ajouter l'édition de ligne de commande à ksh a été rejetée dans l'espoir que l'édition de ligne se déplacerait dans le pilote du terminal. Cependant, lorsqu'il est devenu clair que cela ne se produirait probablement pas bientôt, les deux modes d'édition de ligne ont été intégrés dans ksh et rendus facultatifs afin qu'ils puissent être désactivés sur les systèmes qui fournissaient l'édition dans le cadre de l'interface du terminal.
Au lieu de cela, ils ont implémenté les deux et une interface permettant aux utilisateurs de choisir entre les deux. kshétait très probablement le premier au début des années 80 (réutilisation de code qui avait été écrit séparément pour ajouter un mode vi et un mode emacs au shell Bourne comme vu ci-dessus) suivi par tcsh( tcshinitialement, il n'y avait qu'une emacsliaison de clé, le vimode a été ajouté plus tard) et plus tard bashet zshau début des années 90.
Vous basculez entre les deux modes dans bash, zshou kshavec set -o viou set -o emacs, et avec bindkey -eou bindkey -vdans tcshou zsh.
POSIX spécifie en fait le vimode et non le emacsmode pour sh(l'histoire raconte que Richard Stallman s'est opposé à ce que POSIX spécifie le emacsmode poursh ).
Le mode par défaut bash, le domaine public variantes de ksh(pdksh, mksh, oksh), tcshet zshest le mode emacs (mais avec zsh, il est visi votre $EDITORest - vi), tandis que dans le AT & T ksh, il est le muet mode à moins $EDITORou les $VISUALmentions viou emacs.
ksha également ajouté plus tard un gmacsmode pour accueillir les utilisateurs de Gosling emacsqui géraient Ctrl+Tdifféremment.
Maintenant, la gestion de ^Win emacsou en tcshmode emacs est probablement antérieure au werasecaractère dans l'éditeur de ligne de terminal, donc nous ne pouvons pas vraiment leur en vouloir et ma déclaration sur le "départ ..." peut être considérée comme trompeuse. C'est juste que je trouve ça irritant quand des choses comme emacs, tcshou infose comportent différemment de tout le reste lorsque vous tapez Ctrl-W. Vous pouvez imaginer que je l'ai trouvé beaucoup plus irritant lorsque certaines applications ont commencé à fermer leur fenêtre lorsque vous avez tapé Ctrl-W.