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 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.



![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=66974685-5d93-4761-8bbd-015561d1b1cd)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=bfa5f551-b0b0-4379-9e1e-9393458c1c0a)
Waf: a pleasant build system
A good software project must have a good build system. Unless you have a small code base consisting entirely of dynamic, scripted languages, you probably need to “build” your code before you can use it. Until around an year ago, the only build tool that I used and was familiar with was GNU Make. Make and the autotools family of tools have served the developer community well the past few decades.
But the Make model is rife with problems. Here are a few of them:
I recently began work on a new pet project. As is usually the case, I spent a lot more time figuring out what tools and libraries I would use for my project, than in actually writing any code for the project :) Part of the investigation was to survey the state of the art in build systems. At work, we started using SCons for most of our build, which was already a huge improvement over Make. But SCons has its own set of issues.
One of the nicest features in SCons is that build files are regular Python files. This provides enormous flexibility and immediate familiarity. Unfortunately, the SCons documentation leaves much to be desired. I still don’t quite understand the execution model of SCons very well. For instance, I know how to extend SCons to support cross-compilation for multiple platforms. However, I don’t really understand why those modifications work — there’s quite a bit of black magic that goes on behind the scenes. As a concrete example, there are several magic variables such _LIBDIRFLAGS that have strange powers.
Waf
After some more looking around, I discovered Waf. And now that I’ve played around with it a little bit, I’m happy to say that it is the most pleasant build system I’ve ever used. Things I really like about Waf:
Of course, Waf is not perfect. Coming from a Make/SCons world, I sorely miss the ability to build specific targets. Yes there are ways to achieve this in Waf, but they are all clumsy. The API documentation (and the source itself) are a bit hard to parse.