Byobu vs. GNU Screen vs. tmux——技能的实用性和可转移性

Question

到目前为止，我已经使用Konsole来管理多个 shell 会话，但我还没有尝试过Byobu、GNU Screen和tmux，它们为多个 shell 提供了更好的支持。它们都共享一个主要功能，即允许分离当前会话并稍后重新附加到该旧会话。

为了帮助我选择学习工具，我想知道：它们在以下方面有何不同？

1. 特点（显然）
2. 项目成熟度。我不想学习变化太大的工具。欢迎增强功能，但我不喜欢功能消失等惊喜。
3. 学习曲线
4. 在不同平台上的可用性。如果我学习了一个工具，我希望能够在 FreeBSD 服务器、SuSE 桌面或 Ubuntu 上使用它。
5. 与其他交互式 shell 程序的兼容性。我还能像以前一样使用vim和emacs -nw（非窗口模式或文本模式）吗？键盘快捷键会与其他工具的快捷键冲突吗？

我刚刚尝试了所有这些，Byobu 看起来像是 GNU Screen 和 tmux 的一种前端。那么为什么有人创建了 Byobu 而不是为 GNU screen 项目做出贡献并添加新功能？为什么 GNU Screen 中的 Byobu 不是某种高级界面模式？如果我使用 Byobu 作为我的日常工具，以 GNU screen 作为后端，如果某台机器只有 GNU Screen，我是否可以将这些知识转移到没有 Byobu 的情况下使用 GNU Screen？

Answer 1

好问题！ 无论如何，我是Byobu的作者和维护者。

Byobu是一个配置层，最初写在GNU Screen之上，但现在也可以在Tmux 之上工作。

我在2008 年 12 月开始编写 Byobu ，因为我在Googleplex遇到了一群 Screen 和 Ubuntu Server 用户，发现我们所有人都在我们的~/.screenrc配置中维护了自己的一堆整洁/有趣/有用的技巧。我们不得不在我们使用的数十或数百台服务器之间手动移动它们。我们开始交易技巧和窍门，我开始将它们收集到名为“screen-profiles”的原始GPLv3项目中。大约 6 个月后，整个社区围绕“屏幕配置文件”发展起来，项目变得不仅仅是屏幕黑客——我们有配置实用程序、实时状态插件和键绑定。所以我们重命名了项目 “Byobu”是日语中那些优雅的折叠“屏幕”的词，它的另一个好处是能够比“屏幕 $FOO”更成功地在 Google 上搜索“Byobu $FOO”。

Byobu 现在在大多数 Linux 发行版（Ubuntu、Debian、Fedora、Arch）中，并且在大多数 Mac/BSD 和其他 UNIX 上都可以运行，它在任何终端上提供相同的外观、方便的键绑定和动态系统状态信息需要访问。

为什么不回馈 GNU Screen 项目呢？有几个原因...... Byobu 的所有工作以及配置选项都一样。它不需要包含在 Screen 源库中才能起作用。如果 Screen 在默认情况下包含它们，有些事情可能会更好或表现得更好，但许多更改都非常“固执己见”，通常很难或不可能为25 年历史的上游项目做出贡献。此外，GNU Screen 项目进展非常缓慢，如果有的话。它已有 25 年以上的历史，自2008年8 月以来一直没有正式发布。每个发行版都带有大量补丁，只是为了让您的 /usr/bin/screen 工作和安全。例如，Ubuntu 和 Debian 目前携带 19K 行代码，大约 48补丁。

大约 2 年前我了解了 Tmux，真正爱上了它的源代码、设计、界面和活跃的社区！我更轻松地为上游 Tmux提供修复程序并讨论邮件列表中的主题。作为一个在任何地方都使用它的 Byobu 用户，我希望我的 Tmux 会话的外观和感觉与我在 Byobu 4 年多的时间里所享受的一样。因此，我移植了所有 Byobu 代码，以便与作为后端的 Tmux 和 Screen 一样良好地工作。从Byobu 5.0 版本开始，Tmux 现在是默认后端，旧模式仍支持 Screen。Byobu 现在利用了 Tmux over Screen 的许多现代功能，包括大幅改进的 256 色支持、UTF8 字符和水平/垂直窗口拆分。

如果您对 Screen 或 Tmux 中的默认设置感到满意，或者想从头开始编写自己的配置文件，那么无论如何，Screen 和 Tmux 作为出色的实用程序为我们的生活增加了多年的效率。如果您对一组真正扩展和扩展 Screen 和 Tmux 开箱即用的配置感兴趣，请查看 Byobu！

干杯，达斯汀

Answer 2

对于 Tmux 与 GNU Screen，请阅读

• tmux 与屏幕 [SU]
• tmux 与 GNU Screen [Unix.SX]

以及可以在博客等上找到的其他几个比较化身。

一些经常重复的通用术语：

• Tmux 较新。这意味着它有点高级（简单的垂直分割，漂亮的绿线）并且在兼容性方面的测试不太好（根据其支持者的说法可以忽略不计）。
• Tmux 在资源上更精简。
• GNU Screen 随处可见，而且很可能仍然被更多地使用。

除此之外，人们可以查看一种或另一种选择的特定功能，个人偏好将主导讨论。我个人曾经大量使用 GNU Screen？—？现在我使用 Tmux。

我没有发现 Byobu 对我有任何“杀手级功能”。它提供了一个抽象，我认为我的用例不需要。

另一种看待它的方式是注意 Byobu 可以使用 GNU Screen 或 Tmux 作为后端，这表明与用户 POV 的差异主要是表面的。

Answer 3

从实际使用的情况下，最大的区别screen，并tmux为他们如何处理分割窗口。

一个窗口screen是一个单一的伪终端。当附加到screen会话时，您可以将终端拆分为多个区域，每个区域可以显示一个screen窗口。多个区域可以显示同一个窗口。拆分不是会话的一部分；如果你分离，你的分裂就消失了。

一个窗口tmux由一个或多个伪终端组成，每个窗格一个。这意味着，如果您稍后分离并重新附加，窗格将继续存在。这也意味着您一次只能在 中显示一个窗口tmux，并且不能在多个窗口之间共享窗格。tmux但是，确实允许在多个会话之间共享一个窗口。

我更喜欢 使用的模型tmux，但我无法争辩说它比 使用的模型更好screen。

Answer 4

对我来说，tmux 的关键在于会话共享的实现。

在 GNU Screen 中，如果您让另一个用户连接到一个会话，或者只是将您的会话连接到多个终端，他们可以独立运行（从终端 B 切换会话 A 中的屏幕不会使终端 A 也切换屏幕会话 A)。

以上不是 tmux 的情况（还没有？），或者我还没有找到改变行为的方法。

如果有人知道在 tmux 中更改此行为的方法，或者 tmux 更新以更改此行为或提供现在更改此行为的选项，请发表评论。