Tagged: screen

Tools I use: tmux

Readers of this blog will know that I’m a big fan of GNU screen. While screen is a great tool, it hasn’t seen any major development or feature addition in quite some time. The code base is pretty old, there are some ancient bugs that still linger, and support for modern terminals (such as 256 colors by default) is not quite up to speed. I recently discovered byobu and was extremely happy with it — it completely overhauled my screen user experience. You can read all about byobu here.

I thought I had attained screen nirvana… until I found tmux (hat tip xed). So what exactly is tmux?

tmux is intended to be a modern, BSD-licensed alternative to programs such as GNU screen. Major features include:

  • A powerful, consistent, well-documented and easily scriptable command interface.
  • A window may be split horizontally and vertically into panes.
  • Panes can be freely moved and resized, or arranged into one of four preset layouts.
  • Support for UTF-8 and 256-colour terminals.
  • Copy and paste with multiple buffers.
  • Interactive menus to select windows, sessions or clients.
  • Change the current window by searching for text in the target.
  • Terminal locking, manually or after a timeout.
  • A clean, easily extended, BSD-licensed codebase, under active development.

And how is tmux better than screen? Thats question #1 in the FAQ:

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.
There are still a few features screen includes that tmux omits:
- builtin 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.
I’ve been using tmux exclusively for the last couple of weeks and I really like it so far. For once, I can actually understand the configuration file :) But there are a few things that I miss from screen:
  • I found the screen way of scrolling in a buffer and copying text much easier to use than tmux’s. Unless I’m missing something, the only way to scroll a buffer in tmux and copy some text is by using vi-like keyboard commands. While this is doable, it is not always quick or convenient.
  • byobu made it really easy to add various status indicators. Wish I had something similar for tmux.

Tools I use: screen


The [[http://www.gnu.org/software/screen/|screen website]] introduces screen thus:

//Screen is a full-screen window manager that multiplexes a physical terminal between several processes, typically interactive shells.//

But I don’t think it does justice to the utility of screen. Let me try to simply the introduction a little bit and motivate the usefulness of screen with some examples.

Lets say you started some long running simulation in your lab (for instance, a shell script that calls your main routine with different parameters; then collects/collates the data and also plots it). Now you leave it running and come back home with the hope that when you come in next morning, everything would be done.

But if something goes wrong in between, how do you find out? One cheap way to do this is to use ”nohup” and redirect the output of the process to some log file, and inspect the log file from home. But this is not neat. Ideally, you want to be able to interact with the process as if it was running locally (keystrokes and everything).

More importantly, how do you recover from failures? Say your script gets hung somewhere, and it needs some input to proceed. How do you do it from home? You can of course use remote desktop solutions such as VNC, but they typically have high bandwidth requirements, and are almost unusable over slow networks (as are to be found at most homes. Yes, that includes DSL and cable).

Basically, screen lets you run multiple shells, and “detach” them. Later on, you can simply SSH to your machine, and “reattach” your screen session and have your console workspace restored just as it was. You can monitor and interact with your jobs as if they were running locally. In some sense then, screen is a poor man’s version of full fledged remote desktop protocols, since it basically does the same thing for consoles.

But screen can be used for a lot of other things as well. As the introduction says, screen is a window manager. What that means is that you can have multiple “windows” within a single screen (think of them as buffers in an editor, or just multiple shells that you can switch between). You can split up the screen to display multiple windows at once. This is very convinient if you are editing your script in one window and executing it in another while tailing a log file in a third window, for instance.

Another popular use for screen is for doing collaborative editing. Screen’s can be shared across mutliple users, and so multiple parties can communicate using a single screen. You can edit a report together with your project partners, or just keep an eye on what your friends are typing ;-).

Finally, screen is infinitely configurable. Do ”man screenrc” for details. Here is a basic configuration file to get you started, save it as ”~/.screenrc”:


# no annoying audible bell, please
vbell on

# detach on hangup
autodetach on

# don't display the copyright page
startup_message off

# caption
caption always "%w"

# hardstatus
hardstatus alwayslastline "%H %C%a %M %d, %Y Load: %l "