我们翻译局的几句话：通常每个人都努力翻译最新的材料和出版物，我们也不例外。 但终端并不是每周更新一次的东西。 因此，我们为您翻译了 Antoine Beaupré 于 2018 年春季发表的一篇文章：尽管以现代标准来看其“年龄”相当大，但在我们看来，该材料并没有失去其相关性。 此外，这原本是一个由两篇文章组成的系列，但我们决定将它们合并为一篇大型文章。
终端在计算机历史上占有特殊的地位，但近几十年来，随着图形界面变得无处不在，它们被迫与命令行一起生存。 更换了自己的 ，这又是基于打孔卡和拨动开关的系统的修改。 现代发行版带有各种形状和颜色的终端模拟器。 尽管许多人对工作环境提供的标准终端感到满意，但也有一些人自豪地使用完全异国情调的软件来运行他们最喜欢的 shell 或文本编辑器。 但是，正如我们将从本文中看到的那样，并非所有终端都是按照同一图像创建的：它们在功能、尺寸和性能方面存在很大差异。
一些终端具有令人惊讶的安全漏洞，而且大多数终端具有一组完全不同的功能，从支持选项卡式界面到脚本编写。 虽然我们 ，本文是之前材料的更新，将帮助读者确定 2018 年使用哪个终端。 文章前半部分比较功能，后半部分评估性能。
以下是我审查过的终端：
这些可能不是最新版本，因为在撰写本文时我仅限于稳定版本，我能够在 Debian 9 或 Fedora 27 上推出这些版本。唯一的例外是 Alacritty。 它是 GPU 加速终端的后代，并使用一种不寻常的新语言（Rust）来完成此任务。 我从我的评论中排除了网络终端（包括那些 ），因为初步测试表明它们的性能极差。
统一码支持
我开始使用 Unicode 支持进行测试。 终端的第一个测试是显示 Unicode 字符串 ：“é、Δ、И、ק、м、๗、あ、叶、叶和말。” 这个简单的测试可以显示终端是否可以在全球范围内正常运行。 xterm 终端不显示阿拉伯字符 在默认配置下：
默认情况下，xterm 使用经典的“固定”字体，根据 ，“自 1997 年以来已大量覆盖 Unicode”。 这种字体中发生了一些事情，导致字符显示为空白框，只有当文本字体增加到 20+ 点时，字符才最终开始正确显示。 然而，这个“修复”破坏了其他 Unicode 字符的显示：
这些屏幕截图是在 Fedora 27 中拍摄的，因为它比 Debian 9 提供了更好的结果，在 Debian XNUMX 中，一些旧版本的终端（特别是 mlterm）无法正确处理字体。 幸运的是，这个问题在后来的版本中得到了修复。
现在请注意该行在 xterm 中的显示方式。 原来符号Mem和后面的闪米特 参考 RTL 风格脚本（），所以从技术上讲它们应该从右到左显示。 Firefox 57 等 Web 浏览器可以正确处理上述行。 RTL 文本的一个简单版本是““希伯来语（). 说如下：
“许多计算机程序无法正确显示双向文本。 例如，希伯来语名字“Sarah”由字符 sin (ש)（出现在右侧）、resh (ר) 和 he (ה)（应出现在左侧）组成。”
许多终端未通过此测试：Alacritty、VTE 派生的 Gnome 和 XFCE 终端、urxvt、st 和 xterm 以相反的顺序显示“Sara”，就好像我们将名称写为“Aras”一样。
双向文本的另一个问题是它们需要以某种方式对齐，尤其是在混合 RTL 和 LTR 文本时。 RTL 脚本应从终端窗口的右侧运行，但对于默认为 LTR 英语的终端会发生什么情况？ 它们中的大多数没有任何特殊机制，并将所有文本向左对齐（包括在 Konsole 中）。 pterm 和 mlterm 是例外，它们遵守标准并右对齐这些行。
插入保护
我发现的下一个关键功能是防插入保护。 尽管众所周知，拼写如下：
$ curl http://example.com/ | sh是代码执行推送命令，很少有人知道，即使经过仔细检查，隐藏命令也可以在从网络浏览器复制和粘贴时潜入控制台。 出色地展示了该命令看起来是多么无害：
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怎么运行的？ 恶意代码包含在块中 ，使用 CSS 将其移出用户的视图。
显然是为了抵消此类攻击而设计的。 在此模式下，终端将粘贴的文本包含在一对特殊的转义序列中，以告诉 shell 文本的来源。 这告诉 shell 它可以忽略粘贴文本可能包含的特殊字符。 所有回到古老的 xterm 的终端都支持此功能，但以括号模式粘贴需要终端上运行的 shell 或应用程序的支持。 例如，软件使用 （相同的 Bash），需要一个文件 〜/.inputrc:
set enable-bracketed-paste on不幸的是，Horn 的测试站点还展示了如何通过文本格式本身绕过这种保护，并过早地结束对其应用括号模式。 这是有效的，因为某些终端在添加自己的转义序列之前没有正确过滤转义序列。 例如，在我的项目中，即使配置正确，我也永远无法成功完成 Konsole 测试 .inputrc 文件。 这意味着您很容易因不受支持的应用程序或错误配置的 shell 而损坏系统配置。 当登录远程服务器时，这尤其危险，因为在远程服务器上，仔细的配置工作不太常见，尤其是当您有许多这样的远程计算机时。
解决这个问题的一个好方法是终端的粘贴确认插件 虚拟机，它只是请求允许插入任何包含换行符的文本。 对于 Horn 描述的文本攻击，我还没有找到更安全的选项。
选项卡和配置文件
目前流行的一项功能是支持选项卡式界面，我们将其定义为包含多个其他终端的一个终端窗口。 对于不同的终端，此功能有所不同，尽管传统的 xterm 终端根本不支持选项卡，但更现代的终端版本（例如 Xfce Terminal、GNOME Terminal 和 Konsole）确实具有此功能。 Urxvt 还支持选项卡，但前提是您使用插件。 但就选项卡支持本身而言，Terminator 是无可争议的领先者：它不仅支持选项卡，还可以按任意顺序排列终端（见下图）。
Terminator 的另一个功能是能够将这些选项卡“分组”在一起，并同时将相同的击键发送到多个终端，从而提供了一种在多个服务器上同时执行批量操作的原始工具。 Konsole 中也实现了类似的功能。 如需在其他终端使用该功能，必须使用第三方软件，例如 , или .
选项卡与个人资料配对时效果特别好：例如，您可以使用一个选项卡用于电子邮件，另一个选项卡用于聊天，等等。 Konsole 终端和 GNOME 终端对此提供了良好的支持。 两者都允许每个选项卡自动启动自己的配置文件。 终结者也支持配置文件，但我找不到在您打开特定选项卡时自动启动某些程序的方法。 其他终端根本没有“个人资料”的概念。
荷叶边
我在本文第一部分中要介绍的最后一件事是终端的外观。 例如，GNOME、Xfce 和 urxvt 支持透明度，但最近放弃了对背景图像的支持，迫使一些用户切换到终端 。 就我个人而言，我对此很满意，而且很简单 外部资源，它设置 urxvt 的背景颜色的基本集。 然而，非标准的颜色主题也会产生问题。 例如， 与应用程序 и ，因为他们已经使用了自己的颜色。
不支持颜色，而且新的颜色通常仅限于 256 色调色板。 对于以复杂方式设置终端样式的高级用户来说，shell 提示或状态栏可能是一个恼人的限制。 跟踪哪些终端支持“真彩色”。 我的测试证实基于 st、Alacritty 和 VTE 的终端完美支持真彩色。 其他终端在这方面表现不佳，事实上，甚至不能显示 256 色。 下面您可以看到 GNOME 终端中的真彩色支持之间的差异，st 和 xterm（它们的 256 调色板在这方面做得很好）和 urxvt（它不仅未通过测试，甚至还显示一些闪烁的字符）。
某些终端还会分析文本中的 URL 模式以使链接可单击。 这适用于所有 VTE 派生的终端，而 urxvt 需要一个特殊的插件，可以通过单击或使用键盘快捷键来转换 URL。 其他终端我已经测试过以其他方式显示 URL。
最后，终端的一个新趋势是滚动缓冲区的可选性。 例如，st没有滚动缓冲区； 假设用户将使用终端多路复用器，例如 tmux 和 .
Alacritty 也缺乏向后滚动缓冲区，但是 它的支持归功于用户对此主题的“广泛反馈”。 除了这些新贵之外，我测试过的每个终端都支持反向滚动。
分类汇总
在材料的第二部分（在原文中，这是两篇不同的文章 - 大约。 车道）我们将比较性能、内存使用和延迟。 但我们已经可以看到一些有问题的终端存在严重缺陷。 例如，经常使用 RTL 脚本的用户可能需要考虑 mlterm 和 pterm，因为它们比其他人更擅长处理类似的任务。 Konsole 也表现出色。 不使用 RTL 脚本的用户可以选择其他内容。
在防止恶意代码插入方面，urxvt 脱颖而出，因为它针对此类攻击的特殊实现，这对我来说绝对很方便。 对于那些寻找一些附加功能的人来说，Konsole 值得一看。 最后，值得注意的是，VTE 是终端的绝佳基础，它保证了颜色支持、URL 识别等。 乍一看，您最喜欢的环境附带的默认终端可能满足所有要求，但让我们先保留这个问题，直到我们了解性能为止。
我们继续谈话
一般来说，终端本身的性能似乎是一个牵强的问题，但事实证明，其中一些终端对于这种基本类型的软件表现出惊人的高延迟。 接下来我们还将了解传统上所谓的“速度”（实际上，这是滚动速度）和终端的内存消耗（需要注意的是，这在今天并不像几十年前那么重要）。
延迟
经过对终端性能的深入研究，我得出的结论是，这方面最重要的参数是延迟（ping）。 在他的文章中 Pavel Fatin 研究了各种文本编辑器的延迟，并暗示终端在这方面可能比最快的文本编辑器慢。 正是这个提示最终促使我运行自己的测试并撰写本文。
但什么是延迟，为什么它如此重要？ Fatin 在他的文章中将其定义为“按下按键和相应屏幕更新之间的延迟”并引用 ，其中指出：“计算机显示器上视觉反馈的延迟对打字员的行为和满意度有重要影响。”
Fatin 解释说，这种 ping 带来的后果不仅仅是满足感：“打字速度变慢，出现更多错误，眼睛和肌肉紧张也会增加。” 换句话说，较大的延迟可能会导致打字错误，并降低代码质量，因为它会给大脑带来额外的认知负担。 但更糟糕的是，ping“增加了眼睛和肌肉的劳损”，这似乎意味着 在未来 （显然，作者指的是眼睛、背部、手臂的肌肉问题，当然还有视力问题——大约。 车道）由于重复性压力。
其中一些效应早已为人所知，其结果 早在 1976 年就发表在《人体工程学》杂志上，称 100 毫秒的延迟“会严重影响打字速度”。 最近，GNOME 用户指南介绍了 10 毫秒内，如果再进一步，那么 表明 1 毫秒是理想的。
Fatin 对文本编辑器进行了测试； 他创造了一种便携式仪器，名为 ，我用它在终端模拟器中测试 ping。 请记住，测试是在模拟模式下进行的：实际上，我们需要考虑输入（键盘、USB 控制器等）和输出（显卡缓冲区、显示器）延迟。 Fatin 表示，在典型配置中，该时间约为 20 毫秒。 如果你有游戏设备，只需3毫秒就可以达到这个数字。 由于我们已经拥有如此快速的硬件，因此应用程序不必增加自己的延迟。 Fatin的目标是让应用延迟达到1毫秒，甚至实现无拨号 ，如何 .
以下是我的测量结果，以及 Fatin 的一些结果，以表明我的实验与他的测试一致：
首先让我印象深刻的是 xterm 和 mlterm 等旧程序的响应时间更好。 由于寄存器延迟最差（2,4 毫秒），它们的性能优于最快的现代终端（st 为 10,6 毫秒）。 现代终端都没有低于 10 毫秒的阈值。 特别是，Alacritty 未能满足“可用的最快终端仿真器”的要求，尽管其得分自 2017 年首次审查以来有所提高。 事实上，该项目的作者 并正在努力改进显示。 还应该指出的是，使用 GTK3 的 Vim 比使用 GTK2 的 Vim 慢一个数量级。 由此我们可以得出结论，GTK3 产生了额外的延迟，这反映在使用它的所有其他终端（Terminator、Xfce4 终端和 GNOME 终端）中。
然而，肉眼可能无法注意到这些差异。 正如法廷解释的那样，“你不必意识到它对你产生影响的延迟。” Fatin 还对标准偏差发出警告：“任何延迟（抖动）干扰都会因其不可预测性而产生额外的压力。”
上图是在纯 Debian 9（延伸）上拍摄的 。 此环境在延迟测试中产生最佳结果。 事实证明，GNOME 为所有测量创建了额外的 20 毫秒 ping。 对此的一个可能的解释是存在同步处理输入事件的程序。 Fatin 举了一个这样的例子 ，它通过同步处理所有输入事件来增加延迟。 默认情况下，GNOME 还带有一个窗口管理器 ，这会创建额外的缓冲层，从而影响 ping 并增加至少 8 毫秒的延迟。
滚动速度
下一个测试是传统的“速度”或“带宽”测试，它测量终端在屏幕上显示大量文本时滚动页面的速度。 测试的机制各不相同； 最初的测试是使用 seq 命令简单地生成相同的文本字符串。 其他测试包括 Thomas E. Dickey 的（xterm 维护者）测试，该测试反复进行 。 在另一篇关于终端性能的评论中 使用随机字节的base32编码字符串，使用cat将其输出到终端。 Luu 认为这样的测试“是一个毫无用处的基准测试”，并建议使用终端响应作为主要指标。 迪基还称他的测试具有误导性。 然而，两位作者都承认终端窗口带宽可能是一个问题。 Luu 发现 Emacs Eshell 在显示大文件时冻结，Dickey 优化了终端以摆脱 xtrerm 的视觉迟缓现象。 所以这个测试还是有一定的可取之处的，但是由于各个终端的渲染过程有很大的不同，所以它也可以作为一个测试组件来测试其他参数。
在这里，我们看到 rxvt 和 st 在竞争对手中领先，其次是更新的 Alacritty，其设计重点是性能。 接下来是 Xfce（VTE 系列）和 Konsole，它们的速度几乎是其两倍。 最后是 xterm，它比 rxvt 慢五倍。 在测试过程中，xterm 也出现了很大的波动，导致即使是同一行，传递的文本也很难看到。 Konsole 速度很快，但有时很棘手：显示屏有时会冻结，显示部分文本或根本不显示。 其他终端可以清晰地显示字符串，包括 st、Alacritty 和 rxvt。
Dickey 解释说，性能差异是由于不同终端中滚动缓冲区的设计造成的。 他特别指责rxvt和其他终端“不遵守一般规则”：
“与 xterm 不同，rxvt 并不尝试显示所有更新。 如果落后，它将拒绝一些更新来赶上。 这对表观滚动速度的影响比对内部存储器组织的影响更大。 一个缺点是 ASCII 动画有些不精确。”
为了解决这种 xterm 缓慢的问题，Dickey 建议使用该资源 ，允许 xterm 放弃一些屏幕更新以跟上流程。 我的测试证实 fastScroll 提高了性能并使 xterm 与 rxvt 相当。 然而，正如迪基本人所解释的那样，这是一个相当粗糙的拐杖：“有时 xterm - 就像 konsole - 在删除一些屏幕更新后等待一组新的屏幕更新时似乎会停止。” 在这方面，其他终端似乎已经找到了速度和显示完整性之间的最佳折衷方案。
资源消耗
无论将滚动速度视为性能指标是否有意义，此测试都允许我们模拟终端上的负载，这反过来又允许我们测量其他参数，例如内存或磁盘使用情况。 通过运行指定的测试获得指标 以次 Python进程监控下。 他收集了仪表数据 为 ru_maxrss， 数量 ru_oublock и ru_inblock 和一个简单的计时器。
在本次测试中，ST 以最低的平均内存消耗 8 MB 名列第一，考虑到设计的主要思想是简单，这并不奇怪。 mlterm、xterm 和 rxvt 消耗更多一些 - 大约 12 MB。 另一个值得注意的结果是 Alacritty，它需要 30 MB 才能运行。 然后还有VTE系列的终端，容量从40MB到60MB不等，数量相当多。 这种消耗可以通过以下事实来解释：这些终端使用更高级别的库，例如 GTK。 在测试中，Konsole 的内存消耗高达 65MB，位居最后，尽管其广泛的功能可以证明这一点。
与十年前获得的结果相比，所有程序都开始消耗明显更多的内存。 Xterm 过去需要 4 MB，但现在启动时需要 15 MB。 rxvt 的消耗也有类似的增加，现在需要 16 MB 开箱即用。 Xfce 终端占用 34 MB，是以前的三倍，但 GNOME 终端只需要 20 MB。 当然，之前的所有测试都是在32位架构上进行的。 在 LCA 2012 拉斯蒂·拉塞尔 (Rusty Russell) 上 ，还有许多更微妙的原因可以解释内存消耗的增加。 话虽如此，我们现在生活在一个拥有千兆字节内存的时代，所以我们会以某种方式进行管理。
然而，我不禁觉得为终端这样基本的东西分配更多的内存是一种资源浪费。 这些程序应该是最小中的最小的，应该能够在任何“盒子”上运行，甚至是鞋盒，如果我们到了需要配备 Linux 系统的地步（你知道，那会是这样） ）。 但考虑到这些数字，未来在运行多个终端（除了一些最轻且功能最有限的终端之外）的任何环境中，内存使用都将成为一个问题。 为了弥补这一点，GNOME Terminal、Konsole、urxvt、Terminator 和 Xfce Terminal 具有守护程序模式，允许您通过单个进程控制多个终端，从而限制它们的内存消耗。
在测试过程中，我在磁盘读写方面遇到了另一个意想不到的结果：我原以为这里什么也看不到，但事实证明，某些终端将大量数据写入磁盘。 因此，VTE 库实际上在磁盘上保留了一个滚动缓冲区（此功能 ，而且这种情况仍在发生）。 但与旧的实现不同的是，现在至少这些数据是使用 AES256 GCM 加密的（）。 但出现了一个合理的问题：VTE 库有何特别之处，以至于它需要如此非标准的实现方法......
结论
在文章的第一部分中，我们发现基于 VTE 的终端具有一系列良好的功能，但现在我们发现这会带来一些性能成本。 现在内存不再是问题，因为所有 VTE 终端都可以通过 Daemon 进程进行控制，这限制了它们的胃口。 然而，对 RAM 和内核缓冲区数量有物理限制的旧系统可能仍然需要早期版本的终端，因为它们消耗的资源要少得多。 尽管 VTE 终端在吞吐量（滚动）测试中表现良好，但其显示延迟高于 GNOME 用户指南中设置的阈值。 VTE 开发人员或许应该考虑到这一点。 如果我们考虑到即使对于新手 Linux 用户来说，遇到终端也是不可避免的，那么他们可以使其更加用户友好。 对于经验丰富的极客来说，从默认终端切换甚至可能意味着减少眼睛疲劳，并能够避免未来因长时间工作而导致的工伤和疾病。 不幸的是，只有旧的 xterm 和 mlterm 才能使我们达到 10 毫秒的神奇 ping 阈值，这对许多人来说是不可接受的。
基准测试还表明，由于Linux图形环境的发展，开发人员不得不做出一些妥协。 一些用户可能想要查看常规窗口管理器，因为它们可以显着降低 ping 值。 不幸的是，无法测量 Wayland 的延迟：我使用的 Typometer 程序是为 Wayland 的目的而创建的：监视其他窗口。 我希望 Wayland 合成的表现比 X.org 更好，也希望将来有人能找到一种方法来测量这种环境下的延迟。
来源： habr.com