как разморозить после случайного нажатия ctrl-s в терминале?

<p>это ситуация, которая случалась со мной довольно часто: после нажатия (с другим намерением) <kbd>ctrl-s</kbd> в терминале взаимодействие (вход или выход) с ним заморожено. это, вероятно, своего рода "замок прокрутки" или что-то в этом роде.</p><p>как после этого разморозить терминал?</p><p>(на этот раз я работал с <code>apt-shell</code> внутри <code>bash</code> внутри <code>urxvt</code>-- не знаю, кто из них отвечает за специальную обработку <kbd>ctrl-s</kbd>: я искал историю команд назад с <kbd>c-r</kbd>как обычно для readline, но потом я хотел вернуться назад по истории с обычным - по крайней мере, в emacs -<kbd>c-s</kbd> ( <a href="https://unix.stackexchange.com/questions/541/best-way-to-search-my-shells-history/2120#2120">1</a> , <a href="https://unix.stackexchange.com/questions/4079/put-history-command-onto-command-line-without-executing-it/4086#4086">2</a> , ), но это привело к зависанию терминала. ну, прокрутка/просмотр страниц для просмотра прошлых вещей все еще работает в терминале, но никакого взаимодействия с процессами, выполняемыми там.)</p>

<p><kbd>ctrl</kbd>-<kbd>q</kbd></p><p>чтобы вообще отключить это, вставьте <code>stty -ixon</code> в сценарии запуска. чтобы любой ключ снова начал работать, используйте <code>stty ixany</code>.</p><p>ps: это не терминал или shell, которые делают это, но драйвер терминала ос.</p>

<p><kbd>ctrl</kbd>-<kbd>q</kbd> это действительно ответ. я думал, что добавлю небольшую историю этого, которая слишком длинна, чтобы вписываться в поля <a href="https://unix.stackexchange.com/questions/12107/how-to-unfreeze-after-accidentally-pressing-ctrl-s-in-a-terminal/12108#12108">правильный ответ ak2</a> .</p><p>еще в темные времена терминал был большой частью оборудования, которое подключалось к удаленному устройству (первоначально к другому терминалу, потому что телетайпам было намного легче научиться управлять, чем к телеграфному ключу) по длинному проводу или по телефонным линиям с модемами. ко времени разработки unix код ascii уже был хорошо известен (хотя конкурирующий код ebcdic от ibm все еще был силой, с которой нужно считаться).</p><p>самые ранние терминалы хранили распечатанную запись каждого полученного символа. пока символы поступают не быстрее, чем печатающая головка может их набрать, по крайней мере. но как только терминалы на основе элт стали возможными, возникла проблема, что на элт помещается всего около 25 строк, и достаточно 25 строк из 80 символов ram, что никто всерьез не думал о предоставлении большего = ram для символов, которые прокручивались в верхней части экрана.</p><p>таким образом, требовалось некоторое соглашение, чтобы сигнализировать, что отправляющая сторона должна сделать паузу, чтобы позволить читателю догнать.</p><p>7-битный ascii код имеет 33 кодовых пункта, предназначенных для управляющих символов (от 0 до 31 и 127). некоторые из них имели действительно хорошо поставленные цели, например <code>nul</code> (пробел) лидер на бумажной ленте для многопоточности, разрывов и сращиваний), <code>del</code> ("зачеркнутые" символы на бумажной ленте, обозначенные пробиванием всех семи отверстий), <code>bel</code> (ding!), <code>cr</code>, <code>lf</code> и <code>tab</code>. но четыре были определены явно для управления самим терминальным устройством (<code>dc1</code> до <code>dc4</code> aka ctrl + q, ctrl + r, ctrl + s и ctrl + t).</p><p>мое лучшее предположение состоит в том, что какой-то инженер думал, что (как мнемоника), "s" для "стоп" и "q" для "продолжить" были не так уж плохи, и им присвоили <code>dc3</code> означает "пожалуйста, прекратите отправку" и <code>dc1</code> означает "хорошо, продолжайте отправлять сейчас".</p><p>даже это соглашение было уже хорошо разработано к тому времени, когда unix покинул гнездо в bell labs, чтобы выйти в мир.</p><p>соглашение известно как управление потоком программного обеспечения и чрезвычайно распространено в реальных последовательных устройствах. это нелегко реализовать правильно, так как это предотвращает использование любого из этих символов для любых других целей в канале связи, и сигнал стоп должен обрабатываться перед любыми ожидающими принятыми символами, чтобы избежать отправки больше, чем может получить принимающая сторона ручка.</p><p>если это целесообразно, использование дополнительных сигналов вне полосы из последовательного потока данных для управления потоком является чрезвычайно предпочтительным. на подключениях с прямым проводом, которые могут предоставить дополнительные сигнальные провода, вы найдете аппаратное рукопожатие в использовании, которое освобождает эти символы для других целей.</p><p>конечно, сегодняшнее окно терминала не использует реальный физический последовательный порт, имеет полосы прокрутки и вообще не нуждается в программном подтверждении связи. но конвенция сохраняется.</p><p>я вспоминаю утверждение о том, что ричард столлман получал жалобы на его сопоставление ctrl + s с инкрементным поиском в первых выпусках emacs, и что он был довольно не симпатичен любому пользователю, который должен был зависеть от 7-битного, управляемого потоком программного соединения.</p>