在 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，序列被发送到主端（到屏幕）。onlcrscreen\r\n
screen实现一个终端模拟器，\r旨在将光标移至行首并向\n下移动光标。为此，像 xterm 这样的终端模拟器会执行 X API 调用以将光标移动到行的开头，screen必须将转义码发送到它所连接的主机终端，以告诉它/它们将光标移动到行首。屏幕窗口的左侧。
如果您垂直分割窗口，这意味着将光标定位转义序列发送到屏幕窗口左侧的任何位置。如果不是，或者如果在主机终端的左侧，则screen只需传递这些\r和\n字符，以便光标移动到行的开头，并在主机终端上向下移动一行（因为所有终端都将\r和\n在那种情况下也是一样）。
现在，echo运行并输出一个\n字符。因为onlcr再次在screentty窗口中，再次screen接收。告诉它移到行首，但光标已经位于行首，因此无需执行任何操作，这就是主机终端不接收第二个字符的原因。然后将光标向下移动，因为它接收到，发送到主机终端。\r\n\r\r\nscreen\n
您可以通过在屏幕中运行来验证：
printf '\r\r\r\r'
你会注意到screen只发送一 \r字符到其主机终端。