Comment dégeler après avoir appuyé accidentellement sur Ctrl-S dans un terminal?
C'est une situation qui m'est arrivée assez souvent: après avoir appuyé (avec une intention différente) Ctrl-S dans un terminal, l'interaction (entrée ou sortie) avec lui est figée. C'est probablement une sorte de "verrouillage de défilement" ou autre.
Comment puis-je dégeler le terminal après cela?
(Cette fois, je travaille avec apt-Shell à l'intérieur d'un bash à l'intérieur urxvt-- je ne sais pas lequel d'entre eux est responsable de la gestion spéciale de Ctrl-S: Je cherchais l'historique des commandes à l'envers avec C-r, comme d'habitude pour readline, mais ensuite je voulais revenir en arrière dans l'histoire avec l'habituel - au moins dans Emacs--C-s ( 1 , 2 , ), mais cela a provoqué le gel du terminal. Eh bien, faire défiler/paginer pour voir les choses passées fonctionne toujours dans le terminal, mais aucune interaction avec les processus qui s'y déroulent.)
Ctrl-Q
Pour désactiver complètement cela, collez stty -ixon dans un script de démarrage. Pour permettre à n'importe quelle touche de relancer les choses, utilisez stty ixany.
ps: ce n'est ni le terminal ni le shell qui le fait, mais le pilote de terminal du système d'exploitation.
Ctrl-Q est en effet la réponse. Je pensais que je jetterais un petit historique de cela qui est trop long pour tenir dans les marges de réponse correcte de ak2 .
À l'époque sombre, un terminal était un gros équipement connecté à un appareil distant (à l'origine un autre terminal parce que les télétypes étaient tellement plus faciles à apprendre à utiliser qu'une clé télégraphique) sur un long fil ou via des lignes téléphoniques avec des modems. Au moment où Unix se développait, le code ASCII était déjà bien établi (bien que le code EBCDIC concurrent d'IBM soit toujours une force avec laquelle il fallait compter)).
Les premiers terminaux gardaient une trace imprimée de chaque caractère reçu. Tant que les caractères n'arrivent pas plus vite que la tête d'impression ne peut les taper, au moins. Mais dès que les terminaux basés sur CRT étaient possibles, le problème est survenu que seulement environ 25 lignes tiennent sur le CRT, et 25 lignes de 80 caractères représentaient suffisamment RAM que personne ne pensait sérieusement à fournir plus = RAM pour les caractères qui avaient défilé en haut de l'écran.
Donc, une certaine convention était nécessaire pour signaler que la fin d'envoi devrait s'arrêter pour laisser le lecteur rattraper son retard.
Le code 7 bits ASCII a 33 points de code consacrés aux caractères de contrôle (0 à 31 et 127). Certains d'entre eux avaient des objectifs vraiment bien établis, tels que NUL (vide bande de papier pour le filetage, les espaces et les épissures), DEL (caractères "barrés" sur la bande de papier indiquée par le poinçonnage des sept trous), BEL (Ding!), CR, LF et TAB. Mais quatre ont été définis explicitement pour contrôler le terminal lui-même (DC1 à DC4 alias Ctrl + Q, Ctrl + R, Ctrl + S et Ctrl + T).
Ma meilleure supposition est qu'un ingénieur pensait que (selon les mnémoniques), "S" pour "Stop" et "Q" pour "Continue" n'étaient pas trop mauvais, et ont attribué DC3 pour signifier "veuillez cesser d'envoyer" et DC1 pour signifier "ok, continuez d'envoyer maintenant".
Même cette convention était déjà bien établie au moment où Unix quittait le nid des Bell Labs pour aller dans le monde.
La convention est connue sous le nom de contrôle de flux logiciel et est extrêmement courante dans les périphériques série réels. Il n'est pas facile à mettre en œuvre correctement, car il empêche l'utilisation de l'un ou l'autre de ces caractères à toute autre fin dans le canal de communication, et le signal d'arrêt doit être traité avant tout caractère reçu en attente pour éviter d'envoyer plus que l'extrémité de réception ne peut manipuler.
Si possible, l'utilisation de signaux supplémentaires hors bande du flux de données série pour le contrôle de flux est largement préférée. Sur les connexions directement câblées qui peuvent se permettre les fils de signal supplémentaires, vous trouverez une poignée de main matérielle en cours d'utilisation, ce qui libère ces caractères pour d'autres utilisations.
Bien sûr, la fenêtre de terminal actuelle n'utilise pas un véritable port série physique, possède des barres de défilement et n'a pas vraiment besoin de prise de contact logicielle. Mais la convention persiste.
Je me souviens de l'affirmation selon laquelle Richard Stallman a reçu des plaintes concernant son mappage Ctrl + S à la recherche incrémentielle dans les premières versions d'emacs, et qu'il était plutôt antipathique pour tout utilisateur qui devait dépendre d'une connexion 7 bits à contrôle de flux logiciel.