TL;DR

This is what tmux does and how it helps me Get.Stuff.Done.

Background

I’m one of the lucky people who gets to test out how services perform under terrible Internet connections: random drops, latency above a second, and dismal bandwidth. Because of this I tend to say, “I should really learn how to use screen or tmux” whenever my work gets interrupted. This past week I finally took that plunge! In preparation for a long flight without Internet access, I preloaded a bunch of tutorials and started reading.

I already had screen installed on my development server, so I was inclined to get it working (I had also tried some time ago in the distant past and gave up). To make a long story short, screen just wasn’t doing it for me, and it’s not the mature product that tmux is today. Taking a step on the wild-side, I installed tmux and boy am I glad I did! In fact, I’m so happy I could blog about it!

What is tmux and why should I care?

tmux is a tool to abstract the terminal, giving it persistence and flexibility. Originally I just wanted something to smooth out dropped connections, but I discovered a tool that significantly reduced my administrative overhead using the terminal both on my server and even locally.

First things first, whenever my connection drops, I get right back where I left off with nothing more than tmux a. Don’t want to accidentally kill a long-running process? ✔︎ Want to keep a persistent log-monitor window open? ✔︎ Want to see the output of multiple commands or processes at the same time without cluttering your desktop? ✔︎

I thought it was only for remote terminal sessions…

Because it’s an awesome virtual terminal management server, tmux has lot’s of use locally too. My usual workflow involves about seven or eight open tabs in iTerm. That’s a lot of setup and a lot of tabs that I have to open all the time.

With tmux I’ve cut down my load to just about two tabs. Also, it’s a breeze to get that setup going because I can just have tmux do all the setup for me.

tmux basics

tmux deals with sessions, windows, and panes. Sessions can be thought of as working environments. My dev session, for example, is where I do my PHP testing. Sessions remember the settings of all the windows and panes and groups them together into one configuration.

Windows are the full-terminal-screen parents of panes. Panes are then optionally subdivided sections of a window that contain a virtual terminal. In the picture above my dev session has two windows (one is hidden) while the visible window has three panes. The hidden window is where I do my normal shell work and I simply switch over to it with a C-a n when I want to access it. Moving around the window panes is as simple as navigation in Emacs or vi depending on your preference, for me it’s C-a l to go to the right and C-a h to the left and so on.

• New window: C-a c
• Kill window: C-a &
• Navigate to next/prev window: C-a n / C-a p
• Split horizontal/vertical: C-a % / C-a "
• Arrange panes in preset layouts (rotate through list): C-a [Space]

How is this easier than having multiple iTerm tabs?

As long as you don’t kill the tmux session and your server doesn’t shutdown, the entire session will be preserved. Not only does this mean that I can get back in after a disconnect, but I can close out for a while and come back later to pick up where I left off, maybe the next day or even after a weekend. A simple tmux a opens up four terminals including one where /tmp/php-errors is already being watched because tail -f never quit when I logged off. This is super handy when you want to reboot your laptop or shut it down for the night without derailing what you’re working on.

Locally speaking, there’s lots that I need 5% of the time but ignore for the rest, like when I don’t care to see all the output from a build script, but every once in a while need to check on an error message or restart it all. Here is my environment for working with WordPress notifications: a session with one window and two panes. The top pane shows the build script with its debug info and I mess around with git in the lower pane.

In this configuration, I can be careless about closing iTerm (which I occasionally do by accident). When I want it back I can recall it because tmux is still running. In this case, I named the session so I can call it back specifically – tmux a -t notifications.

No longer does killing iTerm mean killing my development server or my development environment. There’s way more that tmux can do, including attaching read-only copies of a terminal or sharing your terminal session with someone else or logging the entire terminal output to a file or pipe.

Conclusion

If you are interested in checking out tmux, go ahead and do it – I’m sure you will appreciate it if you regularly work in the terminal.

brew install tmux

By the way, tmux is easily and highly configurable. I’m posting my config file using the awesome copy-mode which allows easy copying the screen contents without interfering with the normal terminal input.