Zauważysz, że kiedy uruchamiasz się cat
po znaku zachęty powłoki na terminalu, cat
będąc zmuszonym do pisania na standardowe wyjście tego, co czyta ze standardowego wejścia, i naciśnij a, widzisz a
echo ze strony sterownika terminala, ale cat
tego nie pisze a
(widzisz tylko jeden a
, ten powtórzony przez sterownik terminalu).
Jednak jeśli wpiszesz a Backspace b Enter, nie zobaczysz danych cat
wyjściowych a\010b\015
, ale b\012
( b
i nowa linia).
Wynika to z faktu, że sterownik terminala (mówimy o oprogramowaniu w jądrze, a nie w emulatorze terminala jak xterm
) implementuje bardzo prosty edytor linii w trybie kanonicznym . Sterownik terminala można skonfigurować przy użyciu ioctl()
wywołań systemowych, takich jak przy użyciu stty
polecenia. Na przykład, aby wyjść z trybu kanonicznego, możesz to zrobić stty -icanon
. Jeśli zrobisz:
stty -icanon; cat
Następnie zobaczysz zarówno echo
(za pomocą którego można było wyłączyć stty -echo
), jak i cat
wyjście w tym samym czasie.
Ten edytor jest edytorem liniowym. Oznacza to, że użytkownik powinien edytować jeden wiersz tekstu, dopóki nie zostanie przesłany do aplikacji czytającej urządzenie końcowe po naciśnięciu Enter.
Możliwości edytorskie tego edytora są bardzo ograniczone. W większości implementacji są tylko 4 klawisze edycji (w rzeczywistości znaki), które można również konfigurować za pomocą stty
:
- kasowanie (
^H
lub ^?
zwykle): kasowanie poprzedniego znaku
- kill (
^U
zwykle): pusty (kill) wprowadzony dotychczas wiersz
- werase (
^W
): usuwa poprzednie słowo
- lnext (
^V
): dosłownie wprowadź następny znak (anuluj specjalne znaczenie wszystkich powyższych)
W dawnych czasach sądzono, że ten edytor linii sterowników terminali zostanie rozszerzony o bardziej zaawansowane możliwości. Dlatego żadna z wczesnych powłok nie ma żadnych możliwości edycji wiersza poleceń (uzyskasz te same możliwości edycji wiersza w wierszu poleceń powłoki, gdy działasz cat
tak, jak to zrobiliśmy powyżej).
Jednak tak naprawdę to się nigdy nie zdarzyło, być może po części przyczyną jest bałagan z różnymi terminalami, które nie wysyłają tych samych znaków po niektórych naciśnięciach klawiszy, co pokazało, że nie powinno się tego implementować w przestrzeni jądra.
Dlatego niektóre powłoki zaczęły upuszczać tryb kanoniczny sterownika terminala i implementować własny edytor linii. W tym czasie emacs
i vi
były najbardziej popularnych edytorów wizualnych z trybu pracy klucza wiążące i zupełnie innego. W vi
masz jeden tryb do wprowadzania tekstu i jeden do edycji. W emacs
, zawsze wchodzisz w tryb tekstowy , ale edycja odbywa się przez naciśnięcie kombinacji klawiszy (na przykład, ^b
aby przesunąć znak do tyłu).
W tym czasie muszle nie miały sensu wymyślać różnych kluczy. Spowodowałoby to frustrację, ponieważ ludzie musieliby się uczyć innej. Jednak wybranie jednego ( emacs
lub vi
) stylu w stosunku do drugiego byłoby pewnym sposobem na wyobcowanie użytkowników drugiego edytora.
Według https://www.usenix.org/legacy/publications/library/proceedings/vhll/full_papers/korn.ksh.a :
Popularne funkcje edycji wbudowanej (tryb vi i emacs) ksh zostały stworzone przez programistów z Bell Laboratories; tryb edycji linii vi autorstwa Pat Sullivan oraz tryb edycji linii emacsa autorstwa Mike'a Veacha. Każdy z nich niezależnie zmodyfikował powłokę Bourne'a, aby dodać te funkcje, i obie działały w organizacjach, które chciały używać ksh tylko wtedy, gdy ksh miał odpowiedni wbudowany edytor. Pierwotnie pomysł dodania edycji wiersza poleceń do ksh został odrzucony w nadziei, że edycja wiersza zostanie przeniesiona do sterownika terminala. Jednak, gdy stało się jasne, że wkrótce się to nie stanie, oba tryby edycji linii zostały zintegrowane z ksh i stały się opcjonalne, aby można je było wyłączyć w systemach, które zapewniały edycję jako część interfejsu terminala.
Zamiast tego wdrożyli oba i interfejs umożliwiający użytkownikom wybór między nimi. ksh
był najprawdopodobniej pierwszy na początku lat 80. (ponowne użycie kodu, który został napisany osobno w celu dodania trybu vi i trybu emacs do powłoki Bourne'a, jak pokazano powyżej), a następnie tcsh
( tcsh
początkowo tylko emacs
wiązanie klawiszy, vi
tryb został dodany później) i później bash
i zsh
na początku lat 90.
Przełączać się między tymi dwoma trybami bash
, zsh
albo ksh
z set -o vi
albo set -o emacs
iz bindkey -e
lub bindkey -v
w tcsh
lub zsh
.
POSIX tak naprawdę określa vi
tryb, a nie emacs
tryb sh
(historia mówi, że Richard Stallman sprzeciwił się POSIX określając emacs
trybsh
).
Domyślny tryb dla bash
domena publiczna warianty ksh
(pdksh, mksh, oksh), tcsh
i zsh
to w trybie emacs (choć zsh
, to vi
jeśli $EDITOR
znaczy vi
), podczas gdy w AT & T ksh
, to jest głupi tryb chyba $EDITOR
ani $VISUAL
wzmianki vi
lub emacs
.
ksh
później dodano także gmacs
tryb dostosowany do użytkowników Goslinga, emacs
które działały Ctrl+Tinaczej.
Teraz obsługa ^W
w trybie emacsa emacs
lub w nim tcsh
prawdopodobnie poprzedza werase
znak w edytorze linii terminalu, więc nie możemy ich za to winić, a moje stwierdzenie o „odejściu ...” może być postrzegane jako wprowadzające w błąd. To dlatego, że uważam, że to irytujące, gdy coś podoba emacs
, tcsh
albo info
zachowują się odmiennie od wszystkiego innego po wpisaniu Ctrl-W. Możesz sobie wyobrazić, że było to o wiele bardziej irytujące, gdy niektóre aplikacje zaczęły zamykać swoje okno podczas pisania Ctrl-W.