2011-01-06 15:20:23 +0000 2011-01-06 15:20:23 +0000
284
284

tmux与屏幕

我正准备重新使用 GNU Screen ,但我偶尔听到人们提到 tmux 作为一个更好的选择。它是否真的提供了 Screen 所提供的所有功能的替代方案,比如在不同窗口中的活动监控等等?各自的优点和缺点是什么?

答案 (9)

177
177
177
2011-01-17 20:36:07 +0000

我喜欢tmux而不是screen的一些(主要)原因。

  • 状态栏更容易使用。你可以很容易的为当前窗口、有活动的窗口等设置不同的文字/样式,你可以在状态栏的左边和右边放一些东西,包括可以在指定的时间间隔(默认15s)运行的shell命令。 –几乎所有在tmux内可以运行的命令都可以从带有tmux command [args]的shell中运行。这使得它非常容易被脚本化,同时也使得它很容易做复杂的命令。
  • 更准确的自动窗口重命名。screen会根据命令的第一个词来设置标题,甚至在shell窗口中也需要shell配置才能完成,而tmux会跟踪每个窗口中实际运行的进程,并相应地更新标题。这样你就可以用任何shell和零配置获得动态重命名。比如说 假设你正在运行Z Shell 窗口的名字是 “zsh” 现在假设你想编辑一些配置文件,所以你输入sudo emacs /etc/somefile。当sudo在询问你的密码时,窗口的名字将是 “sudo",但是一旦你完成了这些,sudo启动了emacs,标题将是 "emacs"。当你全部完成并退出emacs时,标题会变回 "zsh"。这对跟踪窗口相当有用,而且在特定情况下也特别有用,比如你在另一个窗口中有一些长期运行的进程,偶尔会用dialog提示你输入;当这种情况发生时,窗口名称会改为 "dialog",这样你就会知道你必须切换到那个窗口并做一些事情。
  • 更好的会话处理(IMHO)。你可以在tmux本身的会话中做更多的事情。你可以很容易地切换、重命名等等,你可以在会话之间移动和共享窗口。它还有一个不同的模式,每个用户都有一个服务器,控制他/她的会话,客户端连接到这个服务器。这样做的缺点是,如果服务器崩溃,你就会失去所有的东西;不过我从来没有遇到过服务器对我崩溃的情况。 -tmux似乎被更积极的开发。有相当频繁的更新,你可以根据这个FAQ提交错误报告或功能请求并在几天内得到答复。

这些只是马上想到的主要事情。还有其他的小事,我相信我一定会忘记一些事情。不过,tmux绝对值得一试。

100
100
100
2011-05-04 18:28:02 +0000

(Sessions是窗口的集合,它可以被分离出来并在以后重新连接。窗口可以包含一个或多个panes.例如configs,请查看 here here 。例如配置,请查看 [ 这里 ]0x3& 和 [ 这里 ]0x3&)。

tmux

  • 优点
  • 可以发送键到其他面板,有点像IDE
  • 简单的键绑定–有了正确的配置,你会觉得在Vim或Screen中就像在家一样
  • 内置Vim-ish和Emacs-ish绑定
  • 良好的布局管理。很像一个平铺窗口管理器
  • Unicode 似乎只适用于现代终端
  • 一些终端问题通过 TERM=tmux
  • 缺点
  • 慢–不知道为什么,但按键似乎滞后~ 再也没有慢的问题了
  • 多路复用将整个会话的宽度和高度强制到最小的附加终端
  • 在 Mac OS X 上多次崩溃。失去整个会话
  • 在Linux上升级后失败。
  • 偶尔会错过命令按键 - ^A ^[ 复制模式需要几次尝试
  • 不能将一个窗格从一个窗口移动到另一个窗口join-pane命令修正
  • 终端宽度改变(窗口大小调整)后没有行解包(或 “回流 "或 "重包")

GNU Screen

  • 优点
  • 极其稳定(v1.
  • 一些终端问题在0x6和
  • 内置Emacs式绑定
  • 易于移动和控制水平面板
  • 当多路复用时,任何连接的终端都可以调整一个面板的大小
  • 缺点
  • 在没有补丁的情况下,没有垂直分割(Ubuntu除外)
  • 当分离时,面板分割会丢失
  • 让Unicode工作需要一点技巧和决心
  • 疯狂的状态行配置。
15
15
15
2015-04-10 18:05:27 +0000

屏幕的一个优点:它在Linux和Solaris上几乎是开箱即用。当你必须在平台之间来回切换时,没有心理上的上下文切换是件好事。

我相信你可以在任何平台上得到tmux的编译,但有时你的权限刚好够利用screen,但实际系统管理员并不想添加任何不是绝对必要的软件。

13
13
13
2012-04-19 17:30:12 +0000

我使用tmux已经有2天左右了,所以我对它的无比热情还没有因为碰到恼人的用例而有所收敛。

在经历从一个程序过渡到另一个程序的通常的成长痛苦时,我被几个积极的功能所打动,但让我相信我永远不会回到屏幕的功能是复制-n-粘贴模式的实用性。

screen中,你不能进入复制模式,在缓冲区中回滚,然后进入另一个窗口。

tmux中,可以让多个窗口同时进入复制模式,缓冲区回滚到不同位置。另外,还有多个复制缓冲区。而且你不需要对源码进行修补,就可以得到fFtT光标的移动。

8
8
8
2011-01-06 15:38:55 +0000

我从tmux中得到的东西,在屏幕中不容易得到的是。

  1. 纵向分割
  2. 多路复用,我们用它来进行远程和本地配对。
8
8
8
2016-01-17 16:10:36 +0000

我已经用 tmux 替换了 GNU Screen ,在每个用例中都是如此,除了当我需要一个 HyperTerminal 等价物来连接到串行端口时。正如Aaron Toponce在他的文章“用GNU Screen连接到串行空调制解调器”中所指出的,tmux FAQ规定。

screen有内置的串行和telnet支持;这是臃肿的,不太可能被添加到tmux中。

我典型的 tmux 使用案例是结合 tmuxinator 创建多窗格和多窗口开发会话。如果你想学习 tmux ,我推荐你去买 Brian P. Hogan 的书, tmux: Productive Mouse-Free Development

4
4
4
2017-12-15 22:15:08 +0000

tmux的维护者之一,Thomas Adam,也是screen项目的维护者列出,虽然他只接触tmux代码。这是tmux比屏幕的一大优点。

3
3
3
2019-01-16 06:25:48 +0000

我一直是Screen的忠实用户,但我使用的是2002年修改的版本。主要是因为我想让窗口的 “下一个/前一个 "导航顺序与新窗口的创建顺序相匹配,类似于一个平铺窗口管理器,如 i3 Ion 。标准的Screen行为是让 "next "和 "prev "按窗口号来排序,所以通常 "新 "窗口(抓取最小的可用数字)会比 "next "窗口位于其他地方–如果你不记得数字,就会感到困惑。我喜欢的行为已经在Tmux中实现了2010年的new-window命令的一个标志,以及2012年的renumber-window选项。我的Screen补丁,我试图让它尽可能的被接受,包括文档的添加等等,在2002年7月的Screen列表中没有引起任何讨论(当时是 ”screen@informatik.uni-erlangen.de“,找不到存档)。事实上,即使我在一年后再次发送,也没有得到任何确认。

从2002年开始,我 "重新 "了几次补丁,以适用于较新版本的Screen。然而,当我到了4.3版本(2015年)时,我注意到一个未记录的变化,它破坏了我对Screen的一个用途–即 ‘stuff'现在会插值环境变量 。我不需要这个功能,而且我也不知道如何轻松地转义'stuff'的参数(这样我就可以发送包含美元符号的文本),所以我就一直使用4.0版本(2004年的)。

我在Emacs函数中使用Screen的'stuff'(Tmux中的'send-keys'),它将当前Emacs区域的内容发送到一个特定的窗口号。这样当我用脚本语言写代码的时候,我打开一个解释器,给解释器窗口一个特殊的编号,然后我就可以用这个Emacs绑定直接从我的编辑器窗口发送代码行到解释器窗口。这是一个黑客,但我喜欢它比纯Emacs解决方案更好,因为我也可以在它的屏幕窗口中使用标准的按键与解释器交互。它有点像一个GUI IDE,但我不必使用鼠标或盯着一个闪烁的光标。

我在补丁中实现的另一个功能是可以 "标记 "一个窗口,然后将标记的窗口重新定位到当前窗口之后。对我来说,这是一种比重新编号更自然的窗口排序方式;它就像复制/粘贴模式,或者说 "拖放"。(我 最近发现在i3 中也可以这样做。)

在Tmux中应该可以做同样的事情,例如 自2015年起 有一个 "标记 "窗格的设施。或者,也许可以用有状态的shell脚本找出一个更基本的解决方案。我实现了一个简短的脚本和keybindings来尝试 "标记窗格 "的方法,它工作了几次,但后来Tmux以”[丢失服务器]“崩溃。然后我发现Tmux即使没有我尝试做任何复杂的事情也会崩溃。很明显对某些用户来说,它已经崩溃了至少有几年了。有时服务器崩溃,有时它开始使用100%的CPU,变得毫无反应。我从来没有见过Screen做这两种情况。

理论上,Tmux在几个方面都比Screen优越。它有更好的脚本性,这意味着你可以做一些事情,比如从命令行查询当前会话中的窗口列表,这在Screen中是不可能的。比如在2015年Screen 增加了一个 "按标题对窗口进行排序 "的命令 。我不知道这样一个专门的命令在什么时候会有用,但这个和更多实用的变化(例如按CPU使用率排序窗口)可以相对容易地从Tmux的shell脚本中完成。对我来说,至少在不修改C代码的情况下,在Screen中很难做到如此有创意的事情。

正如其他发帖人提到的,Tmux有一个单服务器模式,我认为这是主要的缺点,特别是当服务器崩溃的时候。可以通过为每个 "会话 "指定一个单独的套接字来解决这个问题。不过我还是更喜欢Screen的单服务器–每个会话的默认模式,它看起来更优雅一些。

在2002年的时候,使用Screen的代码对我来说是一种教育和享受。奇怪的是,尽管Tmux有很多额外的功能,但它的代码行数比Screen少了25%(3万对4万)。我注意到Tmux使用了许多树形和列表数据结构,这对我来说有点难以理解。Screen似乎更喜欢使用数组。

据我了解,由于Unix终端界面非常稳定,Screen或Tmux代码几乎不需要适应底层操作系统的变化。这些程序并不像网络浏览器或网络服务器甚至shell那样真正具有安全更新。我没有注意到运行我的自定义版本的Screen,最后一次更新是在2004年(除了需要添加【一些配置文件以防止Systemd删除socket ](https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html)。这些文件通常都是发行包的一部分)。) 也许我可以通过运行Tmux开始崩溃之前的Tmux版本来解决我在Tmux中遇到的问题。当然,如果有足够多的用户这样做,那么对新用户来说并不是很好,因为这意味着在这些程序的最新官方版本中寻找bug的专家会减少。然而,我很难激励自己去换一个对我来说不稳定的产品(最新的Tmux)或者缺乏某些我想要的功能(标准屏幕)。

我知道这并不能为上位者的问题提供一个简单的答案,但我希望我的观点是有用的。

2
2
2
2012-06-21 15:27:36 +0000

我想说屏幕的可用性是它的强项,但它的窗口系统并不像 tmux 那样容易处理。我必须说,我现在大部分时间都在使用 gnu-screen ,因此有很多终端标签而不是屏幕窗口。

@Jed Schneider。你可以用Ctrl+A和|(竖条)来实现垂直窗格的分割。