If you don't use a development environment such as Eclipse but mostly rely on the command line in a terminal, you will certainly be familiar with screen. Among other things, this legacy terminal utility ensures that, after network problems, the initiator of an aborted SSH session can continue without problems exactly where they stopped typing. The screen utility sits between users and applications running in the terminal and tricks the application into believing that an attentive user is still at the keyboard, even if they have long since left the office for a weekend break.

As you know, the Unix world has not stood still over the past 20 years, and a relatively young project named Tmux [2] has been set up to improve and replace Screen. Like Screen, Tmux offers the user several sessions, which in turn comprise windows; in Screen lingo, this does not mean desktop windows, but switchable text interfaces in the same terminal window. Using keyboard shortcuts, Tmux can subdivide each window again by creating vertically or horizontally arranged panes, all of which are visible at the same time (Figure 1).

Figure 1: Two tmux commands divide the window into two horizontal panes, and then the right pane into two vertical panes.

Tmux runs on all major platforms. If you work on a Linux desktop but use a MacBook on the road, you will find the same windows and panes in both environments.

Servers and Clients

An automatically launched Tmux server keeps track of active sessions, and the user can remotely control them at the command line. The tmux command creates new sessions or closes them later, adds more windows or deletes them, integrates or removes panes, and scales panes up or down. For developer environments with multiple windows and panes, it makes sense to save the time-consuming configuration in a source code repository and display it again, when needed, with a single command.

Tmux can also launch applications in panes, for example, your favorite editor, which in turn loads a project file. Another pane could start the test suite, and a third could use tail to display the end of a log file.

Changes Desirable

A newly installed Tmux has some weird keyboard shortcuts. To make sure keystrokes are interpreted by the intermediate terminal multiplexer – and not by the applications running in a Tmux session, like the editor – you need to type what is known as a prefix. A vanilla Tmux installation uses Ctrl+B by default, a keyboard shortcut that not only causes repetitive strain injury with frequent use but also is a common Vi command, and thus a no-go.

Fortunately, Tmux lets you change everything, so experienced users will quickly put together their own .tmux.conf file after the install; my file is documented in my GitHub repository [3]. It is ultimately only based on general recommendations, such as setting a screen-compatible prefix with Ctrl+A and using vim-style combinations for the rest: H=left, J= down, K=up, L=right. This removes the need to enter Emacs-style text commands to toggle between panes; instead, you can use <Prefix> H to go to the left-hand panel.

Of course, customized shortcuts have a couple of drawbacks; for example, everyone speaks a different Tmux dialect and flaps around like a bug on its back in anyone else's environment. However, Tmux understands written commands, introduced with the <Prefix>: keyboard shortcut (prefix followed by a colon), which you type in the opening status line.

Tmux also understands the same commands at the shell prompt, meaning your own scripts for creating a window group can be used globally. For example, the Perl script in Listing 1 issues the

tmux kill-session

command with the session name log4perl in line 27, if the user runs the script with the -k option. The command opens a connection to the Tmux server (if it is running), finds the session, and then winds it up.

Once Only

The -v (verbose) option tells Listing 1 to set the Log4perl configuration to the $DEBUG logging level; $INFO would mean far less talk. To avoid the need for the script to write out every single Tmux command, the tmux() function in lines 68-74 calls tmux via the shell. The tap() function from the CPAN Sysadm::Install module triggers this. Because I wanted to avoid having to use parentheses when calling tmux(), line 12 declares it as a function in the current namespace.

Line 32 calls source to parse the configuration file .tmux.conf from the user's home directory. Tmux should actually do this automatically, but the version I used didn't comply – this looks like a bug. Additionally, in line 36, it uses the tmux has-session command to discover whether the Tmux session to be established is already running and drops down to attach in line 64 if the session is running and the script only needs to join it.

If the session is unknown, the new-session command in line 44 creates a new session named log4perl. The session name refers to the Log4perl project in whose Git repository it acts as a developer environment. The -d (detach) parameter at the end of the Tmux command stipulates that the script should not immediately enter the session and display the GUI but wait patiently for the attach command in line 64 before showing the user anything.