在终端中意外按下 Ctrl-S 后如何解冻?

在终端中意外按下 Ctrl-S 后如何解冻?

这种情况在我身上经常发生:当我Ctrl-S在终端中按下(以不同的意图)后,与其交互(输入或输出)被冻结。这可能是一种“滚动锁”或其他什么。

此后如何解冻终端?

(这一次,我一直apt-shell在 inside a bashinside中工作urxvt——不确定其中哪一个负责特殊处理Ctrl-S:我像往常一样使用 readline 向后搜索命令的历史记录C-r,但后来我想“返回” “ 以通常的方式向前推进历史——至少在 Emacs 中C-s——(1,2,3),但这导致终端冻结。好吧,在终端中滚动/分页查看过去的事情仍然有效,但与那里运行的进程没有交互。)

答案1

Ctrl-Q解冻。

该停止/启动方案是软件流量控制,它是由操作系统的终端设备驱动程序而不是 shell 或终端仿真器实现的。可以通过stty命令进行配置。

要完全禁用它,请放入stty -ixonshell 启动脚本,例如~/.bashrc~/.zshrc。要改为只允许任何键让事情再次流动,请使用stty ixany

答案2

Ctrl——Q确实是答案。我想我应该介绍一下这方面的历史,它太长了,无法容纳在页边距中。ak2的正确答案

回到黑暗时代,终端是一种大型设备,通过长电线或带有调制解调器的电话线连接到远程设备(最初是另一个终端,因为电传打字机比电报键更容易学习操作)。到 Unix 开发时,ASCII 代码已经很完善(尽管来自 IBM 的竞争 EBCDIC 代码仍然是一股不可忽视的力量)。

最早的终端保留了接收到的每个字符的打印记录。至少,只要字符到达的速度不超过打印头打字的速度。但是,一旦基于 CRT 的终端成为可能,问题就出现了,CRT 上只能容纳大约 25 行,而 25 行 80 个字符代表了足够的 RAM,以至于没有人认真考虑为滚动到屏幕顶部的字符提供更多 RAM。屏幕。

因此需要一些约定来表明发送端应该暂停以便让读者跟上。

7 位 ASCII 代码有 33 个代码点专用于控制字符(0 到 31 和 127)。其中一些确实有明确的用途,例如NUL(用于穿线、间隙和拼接的空白纸带引线)、DEL(通过打所有七个孔来指示纸带上的“划掉”字符)、BEL(叮!)CR、、、LFTAB。但明确定义了四个用于控制终端设备本身(DC1又名DC4Ctrl+Q、Ctrl+R、Ctrl+S 和 Ctrl+T)。

我最好的猜测是,一些工程师认为(正如助记符一样),“S”代表“停止”,“Q”代表“继续”并不太糟糕,并被指定DC3表示“请停止发送”和DC1“确定” ,现在继续发送”。

当 Unix 离开贝尔实验室走向世界时,这个约定就已经很完善了。

该约定称为软件流控制,在实际串行设备中极为常见。正确实现并不容易,因为它阻止在通信通道中将这些字符中的任何一个用于任何其他目的,并且必须在任何待接收的字符之前处理停止信号,以避免发送超过接收端可以发送的字符处理。

如果可行,最好使用串行数据流的带外附加信号进行流量控制。在可以承受额外信号线的直接有线连接上,您会发现正在使用硬件握手,这可以释放这些字符以供其他用途。

当然,今天的终端窗口并不使用实际的物理串行端口,有滚动条,并且根本不需要软件握手。但惯例仍然存在。

我记得 Richard Stallman 曾收到关于他在 emacs 的第一个版本中将 Ctrl+S 映射为增量搜索的投诉,并且他对任何必须依赖 7 位软件流控制连接的用户相当不同情。

答案3

控制键:在 Shell 上执行特殊功能

  • Ctrl- S: 暂停显示
  • Ctrl- Q: 重新启动显示
  • Ctrl- C: 取消操作
  • Ctrl- U: 取消线路
  • Ctrl- D: 信号文件结束

相关内容