Вы заметите, что когда вы запускаете catприглашение командной строки на терминале, catкоторый должен записать в stdout то, что он читает из stdin, и нажимаете a, вы видите aответное сообщение от драйвера терминала, но catне записывает это a(вы видите только один a, который повторяется драйвером терминала).
Однако, если вы печатаете a Backspace b Enter, вы не видите catвывод a\010b\015, но b\012( bи перевод строки).
Это потому, что драйвер терминала (мы говорим о программном обеспечении в ядре, а не в эмуляторе терминала xterm) реализует очень простой редактор строк в каноническом режиме. Драйвер терминала можно настроить с помощью ioctl()системных вызовов, например, при использовании sttyкоманды. Например, чтобы выйти из канонического режима, вы можете сделать stty -icanon. Если вы делаете:
stty -icanon; cat
Затем вы увидите одновременно и то, echoчто вы могли бы отключить, stty -echoи catвывод.
Этот редактор является линейным редактором. То есть пользователь должен редактировать одну строку текста до тех пор, пока она не будет отправлена приложению, читающему оконечное устройство, после нажатия Enter.
Возможности редактирования этого редактора очень ограничены. В большинстве реализаций есть только 4 ключа редактирования (фактически символы), которые также можно настроить с помощью stty:
- стереть (
^Hили ^?обычно): стереть предыдущий символ
- kill (
^Uобычно): пусто (kill) введенная строка
- werase (
^W): стереть предыдущее слово
- lnext (
^V): буквально введите следующий символ (отмените специальное значение всего вышеперечисленного)
В прежние времена считалось, что этот редактор строки драйвера терминала будет расширен с более изощренными возможностями. Вот почему ни одна из ранних оболочек не имеет никаких возможностей редактирования командной строки (вы получите те же возможности редактирования строк в командной строке, что и при запуске, catкак мы делали выше).
Однако этого на самом деле никогда не происходило, возможно, одна из причин - беспорядок с разными терминалами, которые не посылали одинаковые символы при некоторых нажатиях клавиш, что давало понять, что это не должно быть реализовано в пространстве ядра.
Поэтому некоторые оболочки начали отбрасывать канонический режим драйвера терминала и реализовывать собственный редактор строк. В то время emacsи viбыли наиболее популярны визуальные текстовые редакторы с совершенно другой привязкой клавиш и режимом работы. В vi, у вас есть один режим для ввода текста и один для редактирования. В emacs, вы всегда находитесь в режиме ввода текста , но редактирование осуществляется нажатием комбинации клавиш (например, ^bчтобы переместить символ назад).
В то время оболочкам не было смысла придумывать свою собственную привязку ключей. Это вызвало бы разочарование у людей, которым пришлось бы учиться другому. Однако выбор одного ( emacsили vi) стиля поверх другого был бы верным способом оттолкнуть пользователей другого редактора.
Согласно https://www.usenix.org/legacy/publications/library/proceedings/vhll/full_papers/korn.ksh.a :
Популярные встроенные функции редактирования (режим vi и emacs) ksh были созданы разработчиками программного обеспечения в Bell Laboratories; режим редактирования строки vi от Pat Sullivan и режим редактирования строки emacs от Mike Veach. Каждый из них независимо модифицировал оболочку Bourne, чтобы добавить эти функции, и оба были в организациях, которые хотели использовать ksh, только если у ksh был свой соответствующий встроенный редактор. Первоначально идея добавления редактирования командной строки в ksh была отвергнута в надежде, что редактирование строки переместится в драйвер терминала. Однако, когда стало ясно, что это вряд ли произойдет в ближайшее время, оба режима редактирования строки были интегрированы в ksh и стали необязательными, чтобы их можно было отключить в системах, обеспечивающих редактирование как часть интерфейса терминала.
Таким образом, вместо этого они реализовали оба и интерфейс для пользователей, чтобы выбрать между ними. kshСкорее всего, он был первым в начале 80-х годов (повторное использование кода, который был написан отдельно для добавления режима vi и режима emacs в оболочку Bourne, как показано выше), за которым следовали tcsh( tcshпервоначально имелась только emacsпривязка клавиш, viрежим был добавлен позже) и позже bashи zshв начале 90-х годов.
Вы переключаетесь между двумя режимами в bash, zshили kshс помощью set -o viили set -o emacs, и с помощью bindkey -eили bindkey -vв tcshили zsh.
На самом деле POSIX указывает viрежим, а не emacsрежим sh(история гласит, что Ричард Столлман возражал против того, чтобы POSIX указывал emacsрежимsh ).
Режим по умолчанию bash, общественное достояние варианты ksh(pdksh, МКШ, oksh), tcshи zshявляется режим Emacs (хотя и с zsh, это , viесли ваш $EDITORесть vi), в то время как в AT & T ksh, это немой режим , если $EDITORили $VISUALнет упоминаний viили emacs.
kshТакже позже добавили gmacsрежим для размещения пользователей Гослинга, emacsкоторый обрабатывается по- Ctrl+Tразному.
Теперь обработка ^Win emacsили в tcshemacs режиме, вероятно, предшествует weraseсимволу в редакторе строки терминала, поэтому мы не можем винить их за это, и мое утверждение об «уходе ...» может быть воспринято как вводящее в заблуждение. Просто я нахожу это раздражающим, когда вещи нравятся emacs, tcshили infoведут себя иначе, чем все остальное, когда ты печатаешь Ctrl-W. Вы можете себе представить, что я нахожу гораздо более раздражающим, когда некоторые приложения начинают закрывать свое окно, когда вы печатаете Ctrl-W.