Terminal multiplexer applications are a great boon to Unix and Linux sysadmins all over the world. They allow sysadmins to start long-running tasks on remote machines, terminate the SSH session to that machine, then connect to the machine again and resume watching the task or check its results very easily. They also allow sysadmins to run several shell sessions within a single virtual terminal, which is of great use for remote administration as well. The uses to which a terminal multiplexer can be put are numerous and, at times, indispensable.

By far, the best known terminal multiplexer is GNU Screen. In fact, many people who use it in their day to day work are not familiar with the term "terminal multiplexer", in much the same way that many people who use Microsoft Windows every day are not familiar with the term "operating system". GNU Screen has been around for a long time, and to many it is synonymous with the very concept of a terminal multiplexer application.

This is changing somewhat, however. A relatively new terminal multiplexer, known simply as tmux, is beginning to gain some traction in the world of open source Unix-like operating systems. Those who try it out often find that it is actually the superior terminal multiplexer for their use.

Some major problems with GNU Screen

GNU is Not Unix mentioned GNU Screen as an example of one of the problems people sometimes encounter with GNU Project software:

The source code of some of its applications, such as GNU Screen, is generally regarded as buggy and unmaintainable.

GNU Screen is widely acknowledged as being a largely dead project, full of bugs, with spaghetti code in the source that many consider unworthy of the effort of sorting out. This state of affairs discourages improvements, advancements, or simple bug fixing. A similar problem afflicts end users, in that the configuration file syntax for GNU Screen is notoriously obtuse. Where a regular user of some applications might learn their configuration file syntaxes well enough to be able to make arbitrary changes as needed, most GNU Screen configuration is achieved by cutting and pasting something someone else has posted to the Web without understanding why or how it works.

Consider this example of GNU Screen configuration, borrowed from debian-administration.org's Using GNU Screen:

hardstatus on
hardstatus alwayslastline

hardstatus string "%.bW%-w%.rW%n %t%-%+w %=%..G %H %..Y %m/%d %C%a "

A feature that GNU Screen users have wanted for a long time is vertical splitting. By default, GNU Screen only allows splitting the display between two shell sessions horizontally. A patch has been developed that allows vertical splitting in GNU Screen, but it has not been added to the official codebase; more evidence that the project is effectively dead, even if not officially dead. There was talk of a version 4.1, which would include this functionality, being released "soon" — but that talk was as far back as February 2007, and GNU Screen 4.1 still has not materialized. In fact, the most recent version is 4.0.3, released in 2005.

It is distributed under the terms of the GPL, which makes it free and open source software. These terms are relatively restrictive, however, because the GPL is a copyleft license. Among other things, this means that the OpenBSD project was not willing to consider it for inclusion in the base system. Of course, there are other reasons the OpenBSD project would not have included it too, such as the disaster area that is GNU Screen's codebase.

tmux vs. GNU Screen

The tmux FAQ tells us that "tmux offers several advantages over screen:"

• a clearly-defined client-server model: windows are independent entities which
  

  may be attached simultaneously to multiple sessions and viewed from multiple

  
  

  clients (terminals), as well as moved freely between sessions within the same

  
  tmux server;


• a consistent, well-documented command interface, with the same syntax
  whether used interactively, as a key binding, or from the shell;


• easily scriptable from the shell;


• multiple paste buffers;


• choice of vi or emacs key layouts;


• an option to limit the window size;


• a more usable status line syntax, with the ability to display the first line
  of output of a specific command;


• a cleaner, modern, easily extended, BSD-licensed codebase.

It also provides a short list of features GNU Screen offers that are lacking in tmux:

• built-in serial and telnet support; this is bloat and is unlikely to be added
  to tmux;


• wider platform support, for example IRIX and HP-UX, and for odd terminals.

The tmux program offers other advantages over GNU Screen as well. For instance:

• The status bar is on by default. Do you remember that configuration example for creating a status bar in GNU Screen? That is completely unnecessary in tmux. If you do not want the status bar, it is easily deactivated.


• Vertical window splitting is part of the core functionality of tmux, and is less buggy and much more robust than the vertical split patch for GNU Screen. In fact, a number of preset split-screen layouts can be used, and the user can cycle through them with a simple keyboard shortcut.


• The OpenBSD project has incorporated tmux into its base system, complete with intensive code audits.

Theo de Raadt, the founder and project leader for OpenBSD, was impressed with the security of the tmux design:

The most impressive thing about tmux, in my view, is how frustrating the code audit was. In 2 hours, I found only one or two nits that had very minor security consequences.

It was not accepted into the tree based on license alone. It is high quality code.

In the discussion where Theo offered his thoughts, the tmux project leader offered more thoughts on the benefits of tmux:

• Session and window management is more flexible, it is possible to link windows into multiple sessions arbitrarily.


• Splitting and layouts are more powerful than the released version of screen and will improve further.


• The UTF-8 support is a little better.


• The code is better. I'm not going to pretend my code is perfect but screen's code is virtually unreadable. This means that if someone does have an idea for a killer feature it will be easier to implement, as well as allowing for (as Theo has kindly mentioned) easier auditing. Code that was not write-only was a big goal and will mean tmux can hopefully improve faster than screen.


• The command set is easier to use and more consistent. Although of course it can get complicated in places and documentation improvements are ever welcome.

Alex Alexander, at the Linux~ized site, has this to say in its entry switching from gnu screen to tmux:

Clean config file, thorough documentation and a few nice touches here and there (i.e. better, persistent window splitting) make it a nice alternative to screen, but the biggest difference lies in memory usage. Screen can easily eat up to 40-50mb with just a few windows open, but tmux has yet to reach the 10mb mark!

Alex was apparently so impressed with tmux that he started submitting code to the tmux project within days of first trying it out.

More lightweight options

Of course, if all you need is the ability to detach from a running process, there are much more lightweight options than either tmux or GNU Screen. You may want to look into options such as dtach or nohup, if that is truly all you want.

More information about tmux

At Hawk Host:

• TMUX – The Terminal Multiplexer (Part 1)


• TMUX – The Terminal Multiplexer (Part 2)

At OpenBSD FAQ:

• 7.9 - What is tmux?

At SourceForge:

• tmux

At WikiVS:

• Screen vs. tmux