Ali*_* R. 330 gnu-screen tmux
我即将重新开始使用GNU Screen，但我听到人们偶尔会提到tmux作为更好的选择。它是否真的提供了Screen提供的所有功能的替代方案，例如不同窗口中的活动监控等？各自的优缺点是什么？
qme*_*ega 204
一些（主要）的原因，我喜欢tmux过screen：
tmux从带有tmux command [args]. 这使得它非常容易编写脚本，并且可以轻松执行复杂的命令。screen根据命令的第一个单词设置标题，并且需要 shell 配置甚至在 shell 窗口中执行此操作，但tmux跟踪每个窗口中实际运行的进程，并相应地更新标题。通过这种方式，您可以使用任何 shell 和零配置进行动态重命名。例如： 假设您正在运行 Z Shell；窗口的名称将是“zsh”。现在假设你想编辑一些配置文件，所以你输入sudo emacs /etc/somefile. 当 sudo 询问您的密码时，窗口的名称将是“sudo”，但是一旦您完成并sudo启动emacs，标题将是“emacs”。当你全部完成并退出时emacs，标题将变回“zsh”。这对于跟踪窗口非常有用，并且在特定情况下也特别有用，例如如果您在另一个窗口中有一些长时间运行的进程偶尔会使用dialog;提示您输入；发生这种情况时，窗口名称将更改为“对话框”，因此您会知道必须切换到该窗口并执行某些操作。tmux本身做更多的事情。您可以轻松切换、重命名等，还可以在会话之间移动和共享窗口。它还具有不同的模型，其中每个用户都有一个服务器来控制他/她的会话并且客户端连接到该服务器。这样做的缺点是，如果服务器崩溃，您将失去一切；不过，我从来没有遇到过服务器崩溃。tmux似乎得到了更积极的发展。更新非常频繁，您可以根据此常见问题提交错误报告或功能请求，并在几天内得到答复。但是，正如评论中指出的那样，screen缺乏发展主要是因为它很稳定。基本完成了，没有放弃。也就是说，如果它现在不能做某事，它可能永远也做不到，而且长期存在的问题不太可能得到解决。（不过，公平地说，垂直分割是screen我第一次回答这个问题时没有的一个功能，现在有了。）这些是我个人从 screen 切换到 tmux 的一些原因。这并不是说屏幕没有优势，但 FWIW 我想不出自从切换以来我错过了什么。付费书呆子的另一个答案有一个更客观的优点/缺点列表，尽管我会说我从来没有遇到过那里提到的崩溃或错过击键的问题。（那些可能依赖于操作系统。我只在 Linux 和 FreeBSD 上使用过它。）
a p*_*erd 109
（会话是可以在以后分离和重新附加的窗口集合。Windows 可能包含一个或多个窗格。例如配置，请查看此处和此处。）
TERM=tmuxjoin-pane命令修复TERM=screenJus*_*tin 23
屏幕的专业人士：它在 Linux 和 Solaris 上几乎是开箱即用的。当您必须在平台之间来回切换时，最好不要进行心理上下文切换。
我相信你可以在任何平台上编译 tmux，但有时你有足够的访问权限来使用 screen，但实际的系统管理员并不真的想添加任何不是绝对必要的软件。
Wil*_*ell 15
我已经使用tmux了大约 2 天了，所以我对它肆无忌惮的热情还没有因为遇到烦人的用例而受到影响。
在经历从一个程序过渡到另一个程序的常见成长痛苦时，我被几个积极的功能所震惊，但让我相信我永远不会回到屏幕的功能是复制粘贴模式的实用程序。
在 中screen，您不能进入复制模式，在缓冲区中向后滚动，然后转到另一个窗口。
在 中tmux，您可以在复制模式下同时拥有多个窗口，并将缓冲区滚动回不同的位置。此外，还有多个复制缓冲区。而且您无需修补源即可获得 fFtT 光标移动。
Mat*_*kin 11
我在每个用例中都用tmux替换了GNU Screen，除了一个——当我需要一个等效的超级终端来连接到串行端口时。正如 Aaron Toponce 在他的文章“使用 GNU Screen 连接到串行空调制解调器”中指出的那样，tmux 常见问题解答指出：
screen 具有内置的串行和 telnet 支持；这是膨胀的，不太可能被添加到 tmux。
我的典型tmux用例是结合tmuxinator创建多窗格和多窗口开发会话。如果您想学习tmux，我建议您阅读 Brian P. Hogan 的书tmux: Productive Mouse-Free Development。
我从 tmux 中得到的东西我在屏幕上不容易得到的是：
很长一段时间以来，我一直是 Screen 的重度用户，但我使用的是我在 2002 年修改过的版本。主要是因为我希望能够让窗口“下一个/上一个”导航顺序与新的顺序匹配创建了窗口，类似于像i3或Ion这样的平铺窗口管理器。标准的屏幕行为是让“下一个”和“上一个”按窗口编号进行，因此通常“新”窗口（获取最小的可用编号）将位于“下一个”窗口之外的其他位置-如果您不这样做会造成混淆不记得数字。我的首选行为已在 Tmux 中实现，作为2010 年 new-window 命令的标志，以及2012 年的renumber-windows 选项. 我的 Screen 补丁，我试图使其尽可能被接受，包括文档添加等，但在 2002 年 7 月的 Screen 列表中没有引起任何讨论（然后“screen@informatik.uni-erlangen.de”，不能找到档案）。事实上，它甚至没有被承认，即使我一年后再次发送它。
自 2002 年以来，我多次“重新调整”我的补丁以应用于较新版本的 Screen。然而，当我到达 4.3 (2015) 版本时，我注意到一个未记录的更改破坏了我对 screen 的一个使用 - 即“东西”现在插入环境变量。我不需要那个功能，我不知道如何轻松地将参数转义为“东西”（以便我可以发送包含美元符号的文本），所以我一直使用 4.0 版（从 2004 年开始）。
我在 Emacs 函数中使用 Screen 的“东西”（Tmux 中的“发送键”），该函数将当前 Emacs 区域的内容发送到特定窗口编号。这样，当我用脚本语言编写代码时，我打开一个解释器，我给解释器窗口一个特殊的编号，然后我可以使用这个 Emacs 绑定将代码行从我的编辑器窗口直接发送到解释器窗口。它很老套，但我比纯 Emacs 解决方案更喜欢它，因为我还可以使用标准击键在其屏幕窗口中与解释器进行交互。它有点像 GUI IDE，但我不必使用鼠标或盯着闪烁的光标。
我在补丁中实现的另一个功能是能够“标记”一个窗口，然后将标记的窗口重新定位为当前窗口之后的“下一个”。对我来说，这是一种比重新编号更自然的窗口重新排序方式；它就像复制/粘贴范例，或“拖放”。（我最近也想出了如何在 i3 中做到这一点。）
应该可以在 Tmux 中做同样的事情，例如从 2015 年开始，有一个用于“标记”窗格的工具。或者也许可以使用有状态的 shell 脚本来制定更基本的解决方案。我实现了一个简短的脚本和键绑定来尝试“标记窗格”方法，它工作了几次，但随后 Tmux 因“[丢失服务器]”而崩溃。然后我发现即使我没有尝试做任何复杂的事情，Tmux 也会崩溃。显然，它已经崩溃对于一些用户对在至少几年的时间。有时服务器崩溃，有时它开始使用 100% 的 CPU 并变得无响应。我从来没有见过 Screen 做这些。
理论上，Tmux 在几个方面优于 Screen。它具有更好的脚本能力，这意味着您可以执行诸如从命令行查询当前会话中的窗口列表之类的操作，而 Screen 则无法做到这一点。例如，在 2015 年 Screen添加了一个命令“按标题排序窗口”。我不确定这样的专用命令何时会有用，但是可以从 Tmux 中的 shell 脚本相对容易地完成这个和更实际的变化（例如，按 CPU 使用率对窗口进行排序）。对我来说，在 Screen 中做任何如此有创意的事情似乎很难，至少在不修改 C 代码的情况下是这样。
正如其他海报所提到的，Tmux 有一个单服务器模型，我认为这是主要缺点，特别是当服务器崩溃时。可以通过为每个“会话”指定一个单独的套接字来解决这个问题。我仍然更喜欢 Screen 的每会话一台服务器的默认设置，这看起来更优雅一些。
早在 2002 年，使用 Screen 代码对我来说是一种教育和乐趣。奇怪的是，对于所有附加功能，Tmux 的代码行数比 Screen（30k 对 40k）少约 25%。我注意到 Tmux 使用了许多树和列表数据结构，这对我来说有点难以理解。Screen 似乎更喜欢数组。
据我了解，因为Unix终端接口非常稳定，所以几乎不需要Screen或Tmux代码去适应底层操作系统的变化。这些程序实际上并没有像 Web 浏览器或 Web 服务器甚至 shell 那样的安全更新。我没有注意到运行我的自定义版本的 Screen 有任何问题，最后一次更新是在 2004 年（除了需要添加一些配置文件以防止 Systemd 删除套接字; 无论如何，这些文件通常是分发包的一部分）。也许我可以通过在 Tmux 开始崩溃之前运行一个 Tmux 版本来解决我在 Tmux 中遇到的问题。当然，如果有足够多的用户这样做，那么这对新用户来说不是很好，因为这意味着更少的专家会在这些程序的最新官方版本中寻找错误。但是，很难激励自己切换到对我来说不稳定的产品（最新的 Tmux）或缺少我想要的某些功能（标准屏幕）。
我知道这并不能为 OP 的问题提供一个简单的答案，但我希望我的观点是有用的。
| 归档时间： |
|
| 查看次数： |
230079 次 |
| 最近记录： |