![使用 GNU Screen 时的行结尾](https://linux22.com/image/31980/%E4%BD%BF%E7%94%A8%20GNU%20Screen%20%E6%97%B6%E7%9A%84%E8%A1%8C%E7%BB%93%E5%B0%BE.png)
在 Red Hat Enterprise Linux 6.4 系统上使用 GNU Screen 4.00.03 时,我发现一些稍微奇怪的行为。
如果我在没有 Screen 的情况下连接,查看日志,我可以看到每行都以 CRLF ( ) 终止0x0D 0x0A
,与预期完全一致。
如果我连接并运行 Screen,则包含两个或更多字符的行将按预期以 CRLF 终止。没有打印字符的行(例如,运行裸露的echo
)仅以 LF ( ) 终止0x0A
,最奇怪的是,具有单个打印字符的行(例如echo x
)以 BSLF ( ) 终止0x08 0x0A
。
我用 PuTTY 看到了这一点,上面的日志来自 PuTTY 日志。我也在使用 Pexpect 的自动化 Python 框架中看到了这一点,所以我不会为此责怪 PuTTY。
这是怎么回事?我该如何阻止它?
答案1
这是由 完成的优化screen
。
当您echo<Cr>
输入screen
.由于本地回声以及窗口中伪终端设备的设置icrnl
,序列被发送到主端(到屏幕)。onlcr
screen
\r\n
screen
实现一个终端模拟器,\r
旨在将光标移至行首并向\n
下移动光标。为此,像 xterm 这样的终端模拟器会执行 X API 调用以将光标移动到行的开头,screen
必须将转义码发送到它所连接的主机终端,以告诉它/它们将光标移动到行首。屏幕窗口的左侧。
如果您垂直分割窗口,这意味着将光标定位转义序列发送到屏幕窗口左侧的任何位置。如果不是,或者如果在主机终端的左侧,则screen
只需传递这些\r
和\n
字符,以便光标移动到行的开头,并在主机终端上向下移动一行(因为所有终端都将\r
和\n
在那种情况下也是一样)。
现在,echo
运行并输出一个\n
字符。因为onlcr
再次在screen
tty窗口中,再次screen
接收。告诉它移到行首,但光标已经位于行首,因此无需执行任何操作,这就是主机终端不接收第二个字符的原因。然后将光标向下移动,因为它接收到,发送到主机终端。\r\n
\r
\r
\n
screen
\n
您可以通过在屏幕中运行来验证:
printf '\r\r\r\r'
你会注意到screen
只发送一 \r
字符到其主机终端。