我們翻譯局的幾句話：通常每個人都努力翻譯最新的材料和出版物，我們也不例外。 但終端並不是每週更新一次的東西。 因此，我們為您翻譯了 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 更好，也希望將來有人能找到方法測量這種環境下的延遲。
來源： www.habr.com