aka tmux
A replacement for GnuScreen that does the same job, but does it in a different way.
from the tmux FAQ at http://sourceforge.net/p/tmux/tmux-code/ci/master/tree/FAQ :
- How is tmux different from GNU screen?
tmux and GNU screen have many similarities. Some of the main differences I am aware of are (bearing in mind I haven't used screen for a few years now):
- tmux uses a client-server model. Each server has single Unix domain socket in /tmp and within one server there are multiple sessions which may be attached to multiple clients (terminals).
This has advantages, notably: windows may be linked simultaneously to multiple sessions; windows may be moved freely between sessions; and a client may be switched between sessions easily (C-b D). There is one major disadvantage: if the server crashes, game over, all sessions die. In practice, however, tmux is quite stable and gets more so as people report any bugs they hit :-).
This model is different from screen, where typically each new screen instance is independent. tmux supports the same behaviour by using multiple servers with the -L option but it is not typically recommended.
-
Different command interfaces. One of the goals of tmux is that the shell should be easily usable as a scripting language - almost all tmux commands can be used from the shell and behave identically whether used from the shell, from a key binding or from the command prompt. Personally I also find tmux's command interface much more consistent and clearer, but this is subjective.
-
tmux calls window names (what you see in the status line) "names", screen calls them "titles".
-
tmux has a multiple paste buffers. Not a major one but comes in handy quite a lot.
-
tmux supports automatically renaming windows to the running application without gross hacks using escape sequences. Its even on by default.
-
tmux has a choice of vi or emacs key layouts. Again, not major, but I use emacs so if tmux did support only one key set it would be emacs and then all the vi users would get humpy. Key bindings may be completely reconfigured in any case.
-
tmux has an option to limit the window size.
-
tmux has search in windows (C-b f).
-
The window split (pane) model is different. tmux has two objects, windows and panes; screen has just windows. This difference has several implications:
-
In screen you can have a window appear in several layouts, in tmux a pane can only be in one window (fixing this is a big todo item but quite invasive).
-
tmux layouts are immutable and do not get changed unless you modify them.
-
In tmux, all panes are closed when you kill a window.
-
tmux panes do not have individual names, titles and so on.
-
I think tmux's model is much easier to manage and navigate within a window, but breaking panes off from and joining them to windows is more clumsy.
tmux also has support for preset pane layouts.
-
tmux's status line syntax is more readable and easier to use. I think it'd be hard for anyone to argue with this. tmux doesn't support running a command constantly and always using the last line of its output, commands must be run again each time.
-
tmux has modern, easily extended code. Again hard to argue screen is better if you have looked at the code.
-
tmux depends on libevent. I don't see this as a disadvantage: libevent is small and portable, and on modern systems with current package management systems dependencies are not an issue. libevent brings advantages in code simplicity and performance.
-
screen allows the window to be bigger than the terminal and can pan around it. tmux limits the size to the largest attached client. This is a big todo item for tmux but it is not trivial.
-
screen has builtin serial and telnet support; this is bloat and is unlikely to be added to tmux.
-
Environment handling is different.
-
tmux tends to be more demanding on the terminal so tends to show up terminal and application bugs which screen does not.
-
screen has wider platform support, for example IRIX, and for odd terminals.