终端仿真器概述

我们翻译局的一句话：通常每个人都想翻译最新的材料和出版物，我们也不例外。 但是终端不是每周更新一次的东西。 因此，我们为您翻译了Antoine Bopre于2018年春季发表的一篇文章：尽管按照现代标准，“年龄”固然可靠，但我们认为该材料并未完全失去其意义。 此外，原文是一系列的两篇文章，但我们决定将它们合并为一个大文章。



终端在计算机历史上占有特殊的位置，但是在最近的几十年中，它们被迫被迫与命令行一起在无处不在的图形界面的背景下生存下来。 终端仿真器代替了硬件 仿真器 ，后者又是对打孔卡和拨动开关上的系统的修改。 现代发行版附带各种形状和颜色的终端仿真器。 尽管许多人对他们的工作环境所提供的标准终端感到非常满意，但有些人为使用坦率的异国情调的软件启动自己喜欢的shell或文本编辑器而感到自豪。 但是，正如我们从本文中看到的那样，并非所有终端都是以一个图像和相似的形式创建的：它们的功能，大小和性能差异很大。


一些终端具有惊人的安全漏洞，另外，大多数终端具有完全不同的功能集，从选项卡式界面支持到脚本编写。 尽管我们在遥远的过去研究过终端仿真器 ，但本文是对先前材料的更新，可帮助读者确定2018年使用哪种终端。 本文的前半部分比较功能，后半部分评估性能。

这是我查看过的终端：



也许这些不是最新版本，因为在撰写本文时我将自己限于稳定的版本，因此能够在Debian 9或Fedora 27上推出。唯一的例外是Alacritty。 他是具有GPU加速功能的终端的后代，并且用一种不寻常且新颖的语言编写该任务-Rust。 我将Web终端排除在我的评论之外（包括在Electron上 ），因为初步测试显示它们的性能非常差。

Unicode支持

我从Unicode支持开始测试。 第一个终端测试是显示Wikipedia文章中的Unicode字符串：“é，Δ、、、ק，م，๗，あ，叶，叶和말”。 这个简单的测试显示了终端是否可以在全球范围内正常工作。 在默认配置中，xterm终端不显示阿拉伯语Mem符号：



默认情况下，xterm使用经典的“固定”字体，据Wiki称 ，“自1997年以来，Unicode覆盖率很高。” 此字体中发生了一些事情，导致该字符显示为空框架，并且只有当文本字体增加到20+点时，字符最终才开始正确显示。 但是，这样的“修复”会破坏其他Unicode字符的显示：



这些屏幕截图是在Fedora 27中拍摄的，因为它提供了比Debian 9更好的结果，在Debian 9中，某些较旧的终端版本（特别是mlterm）无法正确使用字体。 幸运的是，此问题已在更高版本中修复。

现在注意xterm中的字符串映射。 事实证明，Mem符号和随后的Semitic Qoph属于RTL（ 从右到左 ）脚本，因此从技术上讲，它们应该从右到左显示。 Web浏览器（例如Firefox 57）可以正确处理上述行。 RTL文本的一个简单版本是希伯来语（ שרה ）中的“ Sarah ” 一词 。 双向Wiki页面显示以下内容：

“许多计算机程序无法正确显示双向文本。 例如，希伯来语名称“ Sarah”由符号sin（ש）（出现在右侧），然后resh（ר）和最后是heh（ה）（应出现在左侧）组成。

许多终端均未通过该测试：Alacritty，VTE衍生的终端Gnome和XFCE，urxvt，st和xterm以相反的顺序显示“ Sarah”，就像我们将其拼写为“ Aras”一样。



双向文本的另一个问题是，它们需要以某种方式对齐，尤其是在混合RTL和LTR文本时。 RTL脚本应该在终端窗口的右侧运行，但是默认情况下使用LTR English的终端应该怎么办？ 它们中的大多数没有任何特殊的机制，并且将整个文本向左对齐（包括Konsole）。 pterm和mlterm是例外，它们遵循标准并将这些行向右对齐。

插入保护

我为自己确定的下一个关键功能是防止插入。 尽管众所周知，其拼写如下：

$ curl http://example.com/ | sh 

是推送代码执行命令；很少有人知道，即使经过彻底检查，从Web浏览器进行复制和粘贴时，隐藏的命令也可以穿透控制台。 吉安娜·霍恩（Gianna Horne）的测试现场出色地展示了团队的无害外观：

 git clone git: //git.kernel.org/pub/scm/utils/kup/kup.git 

从Horn网站粘贴到终端时，它变得如此麻烦：

 git clone /dev/null; clear; echo -n "Hello "; whoami|tr -d '\n'; echo -e '!\nThat was a bad idea. Don'"'"'t copy code from websites you don'"'"'t trust! \ Here'"'"'s the first line of your /etc/passwd: '; head -n1 /etc/passwd git clone git://git.kernel.org/pub/scm/utils/kup/kup.git 

如何运作？ 恶意代码放置在<span>块中，该块使用CSS从用户的视野中移出。

括号内粘贴模式显然旨在消除这种攻击。 在这种模式下，终端将插入的文本括在一对特殊的转义序列中，以通知外壳该文本的起源。 因此，shell收到一个信号，它可以忽略插入的文本可能包含的特殊字符。 所有终端，直到古老的xterm都支持此功能，但是以括号模式插入需要支持在终端上运行的Shell或应用程序。 例如，使用GNU Readline （相同的Bash）的软件需要一个〜/ .inputrc文件 ：

 set enable-bracketed-paste on 

不幸的是，Horn测试站点还显示了如何通过格式化文本本身并过早结束对其应用“包围式”模式来避免这种保护。 之所以可行，是因为某些终端在添加自己的终端之前未正确过滤转义序列。 例如，在我的系统中，即使考虑到.inputrc文件的正确配置，我也无法成功完成Konsole测试。 这意味着，由于不支持的应用程序或外壳配置不当，很容易导致系统配置损坏。 当进入远程服务器时，这特别危险，在这种情况下，很少仔细研究配置，特别是如果您有许多这样的远程计算机。

一个很好的解决方案是urxvt终端的粘贴确认插件，该插件仅要求获得粘贴任何包含新行的文本的权限。 对于Horn所描述的文字攻击，我没有找到更安全的选择。

标签和个人资料

现在流行的功能是支持选项卡式界面，我们将其定义为一个包含多个终端的终端窗口。 对于不同的终端，此功能是不同的，尽管像xterm这样的传统终端根本不支持制表符，但以Xfce终端，GNOME终端和Konsole表示的更现代的终端版本具有此功能。 Urxvt也具有标签支持，但仅在使用插件的情况下。 但是就支持这样的选项卡而言，终结者是无可争议的领导者：它不仅支持选项卡，而且还可以按任何顺序排列终端（请参见下图）。



终结者的另一个功能是能够将这些选项卡“分组”在一起，并同时将相同的击键发送到多个终端，这为在多个服务器上同时执行批量操作提供了一个粗糙的工具。 Konsole中也实现了类似的功能。 要在其他终端上使用此功能，必须使用第三方软件，例如Cluster SSH ， xlax或tmux 。

标签与个人资料配合使用特别好：例如，您可以为电子邮件使用一个标签，为聊天使用另一个标签，依此类推。 Konsole和GNOME Terminal对此提供了很好的支持。 两者都允许每个选项卡自动启动其配置文件。 终结者还支持配置文件，但是当我打开某个选项卡时，我找不到自动启动某些程序的方法。 其他终端根本没有概要文件的概念。

柳切奇

我将在本文的第一部分中考虑的最后一件事是终端的外观。 例如，GNOME，Xfce和urxvt支持透明性，但是最近已经逐步淘汰了对背景图像的支持，从而迫使某些用户切换到Tilix终端。 就个人而言，我对Xresources感到满意，它为urxvt设置了基本的背景颜色。 但是，自定义颜色主题可能会引起问题。 例如， Solarized 不适用于htop和IPTraf应用程序 ，因为它们已经使用了自己的颜色。

原始的VT100终端不支持颜色，而新的VT100终端通常限于256色调色板。 对于为其终端设计样式的高级用户，外壳请求或状态栏以某些复杂的方式可能是一个不愉快的限制。 Gist跟踪哪些终端支持True Color。 我的测试证实，基于st，Alacritty和VTE的终端完全支持True Color。 在这方面，其他终端感觉不太好，实际上甚至不显示256色。 在下面，您可以看到GNOME，st和xterm终端中的True Color支持和urxvt之间的区别，后者可以很好地处理其256色调色板，而urxvt不仅使测试失败，而且甚至显示一些闪烁的字符，他们。



一些终端还分析URL模式的文本，以使链接可单击。 这适用于所有VTE衍生的终端，而urxvt需要一个特殊的插件，该插件可通过单击或键盘快捷键来转换URL。 我测试过的其他终端以其他方式显示URL。

最后，终端的新趋势是滚动缓冲区选项。 例如，在st中没有滚动缓冲区。 假设用户将使用tmux和GNU Screen之类的终端多路复用器。

Alacritty也缺少反向滚动缓冲区，但是由于用户对此主题的“广泛反馈”，因此很快将添加支持。 除了这些暴发户之外，我测试过的所有终端都支持向后滚动。

小计

在本文的第二部分（ 原始文章是两篇不同的文章，大约是Per）。我们将比较性能，内存使用和延迟。 但是我们已经看到某些相关的终端存在严重的缺陷。 例如，经常使用RTL脚本的用户可以注意mlterm和pterm，因为他们比其他人更好地处理此类任务。 Konsole的表现也不错。 不使用RTL脚本的用户可以选择其他选项。

从防止恶意代码插入的安全性的角度来看，urxvt脱颖而出，是因为它特别实现了针对这种攻击的保护措施，在我看来，这绝对方便。 那些正在寻找风铃的人应该看看Konsole。 最后，值得注意的是，VTE是终端的重要基础，它可以保证颜色支持，URL识别等。 乍一看，您所喜欢的环境随附的默认终端可以满足所有要求，但让我们先不提这个问题，直到我们确定性能为止。

继续对话

通常，终端性能本身似乎是一个牵强附会的问题，但是事实证明，其中一些对这种基本类型的软件显示出惊人的大延迟。 我们还将进一步研究传统上所谓的“速度”（实际上是滚动速度）和终端的内存消耗（考虑到今天它并不像几十年前那样重要）。

延误

经过对终端性能的透彻研究，我得出的结论是，这方面最重要的参数是延迟大小（ping）。 Pavel Fatin在他的文章“我们愉快地打印”中检查了各种文本编辑器的延迟，并暗示这方面的终端比最快的文本编辑器更慢地工作。 正是这个提示使我最终开始了自己的测试并撰写了这篇文章。

但是，延迟是什么，为什么如此重要？ Fatin在他的文章中将其定义为“按键和相应的屏幕更新之间的延迟”，并引用“人机交互手册”的说法：“计算机显示器上视觉反馈的延迟对打字员的行为及其满意度有重要影响。 ”。

Fatin解释说，这样的ping不仅会带来满足感，还会带来更深的后果：“键入变得更慢，发生更多的错误，眼睛和肌肉的张力增加。” 换句话说，较大的延迟会导致错别字以及代码质量的下降，因为这会导致大脑的额外认知负担。 但更糟糕的是，ping“增加了眼睛和肌肉的紧张程度”，这显然暗示着未来的职业伤害的发展（ 显然，作者指的是眼睛，背部，手臂，当然还有视力的肌肉问题， -约Per。 ）由于重复应力。

其中一些影响早已为人所知，1976年发表在《人体工程学》杂志上的一项研究结果表明，延迟100毫秒“会大大降低拨号速度”。 最近，GNOME用户指南中引入了可接受的10毫秒响应时间 ，如果进一步研究 ， Microsoft Research显示1毫秒是理想的。

Fatin对文本编辑器进行了测试； 他创建了一个称为Typometer的便携式工具，该工具用于测试终端仿真器中的ping。 请记住，测试是在模拟模式下进行的：实际上，我们还需要考虑输入延迟（键盘，USB控制器等）和输出（视频卡缓冲区，显示器）。 根据Fatin的说法，在典型配置中约为20毫秒。 如果您有游戏设备，则只能达到3毫秒的指示器。 由于我们已经拥有如此快速的设备，因此应用程序也不应引入延迟。 Fatin的目标是将应用程序延迟最多1毫秒，或者像IntelliJ IDEA 15一样实现无延迟的拨号。

以下是我的测量结果以及Fatin的一些结果，以表明我的实验与他的测试一致：



让我震惊的第一件事是对xterm和mlterm等较旧程序的最佳响应时间。 在最差的寄存器延迟（2.4毫秒）下，它们显示出比最快的现代终端（st的10.6毫秒）更好的结果。 没有一个现代终端会低于10毫秒的阈值。 特别是，Alacritty不能满足“现有最快的终端仿真器”的要求，尽管自2017年首次检查以来其结果已有所改善。 实际上，该项目的作者已经意识到了这种情况，并正在努力改善显示效果。 还应注意，使用GTK3的Vim比其GTK2慢了一个数量级。 由此我们可以得出结论，GTK3会产生一个额外的延迟，这在使用该延迟的所有其他终端（Terminator，Xfce4终端和GNOME终端）中得到反映。

但是，差异可能看不到。 正如Fatin解释的那样：“没有必要意识到延迟才能对您产生影响。” Fatin还警告说存在标准偏差：“延迟（抖动）长度中的任何不规则都会由于不可预测性而产生额外的负担。”



上图是使用i3窗口管理器在纯Debian 9（拉伸）上拍摄的。 这种环境在延迟测试中提供了最佳结果。 事实证明，GNOME为所有尺寸额外创建了20 ms的ping。 对此的可能解释是存在具有同步处理输入事件的程序。 Fatin引用了此案例的Workrave示例，该示例通过同步处理所有输入事件来增加延迟。 默认情况下，GNOME还具有一个Mutter窗口管理器，该管理器会创建一个额外的缓冲级别，这会影响ping并至少增加8毫秒的延迟。

滚动速度

下一个测试是传统的“速度”或“带宽”测试，该测试可测量终端滚动页面的速度，从而在屏幕上显示大量文本。 测试的机制各不相同； 最初的测试是仅使用seq命令生成相同的文本字符串。 其他测试包括Thomas E. Dickey（xterm维护者）的测试，该测试重复下载terminfo.src文件 。 在另一个终端性能评估中， Den Luu使用base32编码的随机字节串，该字符串使用cat输出到终端。 Luu认为这样的测试“像可以想象的那样没有用”，并建议使用终端的响应作为主要指标。 迪基还称他的测试具有误导性。 但是，两位作者都承认终端窗口带宽可能是一个问题。 Luu在显示大文件时发现Emacs Eshell冻结，Dickie优化了终端以摆脱xtrerm的视觉缓慢。 因此，仍然需要进行此测试，但是由于终端之间的渲染过程非常不同，因此它也可以用作检查其他参数的测试组件。



在这里，我们看到rxvt和st在竞争中领先，紧随其后的是更新的Alacritty，它的开发重点是速度。 接下来是Xfce（VTE系列）和Konsole，它们的工作速度几乎快一倍。 最后一个是xterm，其索引比rxvt慢五倍。 在测试期间，xterm也起伏不定，即使是同一行，也很难看到通过的文本。 事实证明Konsole速度很快，但有时却“棘手”：显示器不时挂起，部分显示文本或根本不显示文本。 其他终端清晰显示了字符串，包括st，Alacritty和rxvt。

Dickie解释说，性能差异与不同终端中滚动缓冲区的设计有关。 他特别指责rxvt和其他终端“不遵守一般规则”：

“与xterm不同，rxvt并未尝试显示所有更新。 如果他落后，他将丢弃一些更新以赶上。 这对虚拟滚动速度的影响要大于对内部存储器的组织的影响。 一个缺点是ASCII动画有点不准确。”

为了纠正xterm的这种慢速状态 ，Dickey建议使用fastScroll资源，该资源允许xterm放弃一些屏幕更新以跟上流的速度。 我的测试证实，fastScroll可以提高性能，并使xterm与rxvt处于同一水平。 但是，这是一个相当粗糙的拐杖，正如Dickey自己解释的那样：“有时xterm-像konsole-似乎停止了，因为它期望在删除其中的一些屏幕后进行新的更新。” 因此，似乎其他终端已经在速度和显示完整性之间找到了最佳折衷方案。

资源消耗

无论考虑将滚动速度作为性能指标的适当性，此测试都可以让您模拟终端上的负载，从而使我们能够测量其他参数，例如内存或磁盘使用率。 指标是通过在Python进程的监视下运行指定的seq测试获得的。 他收集了ru_maxrss的 getrusage（）计数器数据， ru_oublock和ru_inblock的总和以及一个简单的计时器。



在此测试中，ST以8 MB的最小平均内存消耗获得第一，当您认为该项目的主要思想是简单性时，这并不奇怪。 Mlterm，xterm和rxvt消耗更多-大约12 MB。 Alacritty的另一个显着结果是需要30 MB的工作量。 然后是VTE系列终端，其指示灯的显示范围为40到60 MB，这是很多的。 这些消耗可以通过以下事实来解释：这些终端使用更高级别的库，例如GTK。 在测试过程中，Konsole最终消耗65 MB的内存，尽管其广泛的功能可以证明这一点。

与十年前的结果相比，所有程序开始消耗大量内存。 以前，Xterm需要4 MB，但是现在-仅需要15 MB即可运行。 Rxvt的消耗量有类似的增加，现在需要16 MB的可用空间。 Xfce终端占用34 MB，是以前的三倍，但是GNOME终端仅需要20 MB。 当然，所有以前的测试都是在32位架构上进行的。 在2012年LCA大会上，Rusty Russell 表示 ，还有许多细微的原因可以解释内存消耗的增加。 有了这些，我们现在正处在拥有整个千兆字节内存的时代，因此我们可以通过某种方式来处理它。

但是，我不禁感到为终端这样的基本软件分配更多的内存是对资源的浪费。 , «», , - , Linux- ( , ). , . , GNOME Terminal, Konsole, urxvt, Terminator Xfce Terminal Daemon-, , .



-: , , . , VTE ( 2010 , ). , , , AES256 GCM ( 0.39.2 ). , VTE, …

结论

, VTE , , . , VTE- Daemon-, . , , , - , . VTE (), GNOME. , VTE . , Linux , . - . , xterm mlterm 10 , .

, - Linux . , . , Wayland : Typometer, , , Wayland — . , Wayland , X.org, , - .