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 cat
n'é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 cat
sortie a\010b\015
, mais b\012
( b
et 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 stty
commande. 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 cat
sortie 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 (
^H
ou ^?
généralement): effacer le caractère précédent
- kill (
^U
habituellement): 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 cat
comme 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, emacs
et 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 ^b
pour 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 ( emacs
ou 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
( tcsh
initialement, il n'y avait qu'une emacs
liaison de clé, le vi
mode a été ajouté plus tard) et plus tard bash
et zsh
au début des années 90.
Vous basculez entre les deux modes dans bash
, zsh
ou ksh
avec set -o vi
ou set -o emacs
, et avec bindkey -e
ou bindkey -v
dans tcsh
ou zsh
.
POSIX spécifie en fait le vi
mode et non le emacs
mode pour sh
(l'histoire raconte que Richard Stallman s'est opposé à ce que POSIX spécifie le emacs
mode poursh
).
Le mode par défaut bash
, le domaine public variantes de ksh
(pdksh, mksh, oksh), tcsh
et zsh
est le mode emacs (mais avec zsh
, il est vi
si votre $EDITOR
est - vi
), tandis que dans le AT & T ksh
, il est le muet mode à moins $EDITOR
ou les $VISUAL
mentions vi
ou emacs
.
ksh
a également ajouté plus tard un gmacs
mode pour accueillir les utilisateurs de Gosling emacs
qui géraient Ctrl+Tdifféremment.
Maintenant, la gestion de ^W
in emacs
ou en tcsh
mode emacs est probablement antérieure au werase
caractè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
, tcsh
ou info
se 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.