Strong opinions, weakly held

Getting serious about terminal multiplexers

The biggest change in my work habits of 2012 has been the move from doing most of my work on my laptop to doing most of my work logged into a Linux virtual machine via SSH. I’ve used many editors over the years — Vim, Emacs, TextMate, UltraEdit, BBEdit, but the switch to working on the VM has led to using Vim for pretty much everything. For the past few months, I’ve been working hard to improve my Vim chops, with very pleasing results. I’ll probably write about Vim later.

The next thing I’m going to add to the toolchain is a terminal multiplexer. The two most popular are GNU Screen and tmux.

Terminal multiplexers have two main functions. The first is to enable you to run multiple virtual terminal sessions over a single SSH connection which you can arrange however you like and switch between using keyboard shortcuts. This is not incredibly useful to me because I use a terminal application with tabs and I’m very familiar with OS keyboard shortcuts, but using a multiplexer is more portable, and in some cases the ability to split a window and show multiple sessions adjacent to one another is really useful.

The second is that terminal sessions that are running from the multiplexer are maintained even if the network connection drops, accidentally or on purpose. I’ve used screen for awhile when I need to make sure that a long-running processes doesn’t die because I have to go to lunch or something. Using a multiplexer offers the ability to pick up your work exactly where you left off, all the way down to the scroll back buffer, even if your terminal session is disconnected or you work on more than one computer. My main motivation for picking up a multiplexer now is that my terminal sessions have started spontaneously dropping several times a day, and I’m eager to minimize the disruption.

The thing is, terminal multiplexers are beloved used by hardcore Unix users, so they probably have a large number of benefits I’m not even aware of yet, since I’m just really getting started. To this point all I really know is that you start screen by typing “screen” and that you reconnect to a disconnected session using “screen -r”. That feature alone, though, is compelling.

In the past I’ve only used screen, but I’m giving tmux a try. This blog post makes a convincing argument that tmux is more usable than screen. The place to start out, though, is the tmux man page.

I’m not sure what it says that development seems to be moving more and more back into terminal sessions, the way we did it twenty years ago. For all of the powerful desktop tools we used, these days I’m spending most of my day logged into a remote machine using a Unix shell and Vim. If you’re interested in digging into this more deeply, I highly recommend the Unix as IDE series from the Arabesque blog.


  1. The first thing I have to do when using screen on a new machine is to switch the trigger keystroke. C-a gets used waaay too much at the command line as well as in Emacs to give it over to the terminal. I generally end up preferring to avoid screen when I can just because it breaks the scrollback buffer for the mouse.

    I’ve not used tmux, but it’s keystrokes certainly seem friendlier than screen. Another thing I’ve found useful for editing files that live on a server, but staying in my cozy local environment is to use tramp on emacs which lets you treat files on remote servers as locally editable. I’d be surprised if there’s not something similar available for vim, though if you’re doing more than just editing files on the server, it’s not really worth the effort.

  2. I just found out today that pragprog has a book out about tmux

  3. As an easy way to get yourself started with screen, check out byobu and then add additional screen-fu from http://aperiodic.net/screen/quick_reference as needed.

Leave a Reply

Your email address will not be published.


© 2016 rc3.org

Theme by Anders NorenUp ↑