Introduction to tmux (alternative to GNU screen) | Hacker News Reader

Introduction to tmux (alternative to GNU screen)

blog.hawkhost.com

75 pointsrryyan23 comments

If the only reason you use screen or tmux is detaching/attaching, there is an ultra-light alternative called 'dtach', http://dtach.sourceforge.net/

"dtach is a tiny program that emulates the detach feature of screen, allowing you to run a program in an environment that is protected from the controlling terminal and attach to it later. dtach does not keep track of the contents of the screen, and thus works best with programs that know how to redraw themselves."

"dtach does not, however, have the other features of screen, such as its support of multiple terminals or its terminal emulation support. This makes dtach extremely tiny compared to screen, making it more easily audited for bugs and security holes, and also allows it to fit in environments where space is limited, such as on rescue disks. "

No conversation about GNU screen alternatives is complete without mention of Dustin Kirkland's Byobu. https://launchpad.net/byobu

It's a user-friendly screen wrapper with intelligent defaults (key shortcuts and tab indicators with the title of the screen session inside them) and a myriad of status indicators for the bottom of your screen

I recently switched to tmux after years of having used screen, and it's great. It didn't take me that long to configure, which I did mostly by working my way through the man page.

For me, the two killer features that made me switch were the vertical splits (vanilla screen only does horizontal splits), and the distinction between windows and panes.

If it helps anyone else, here's my ~/.tmux.conf file[1], with keybindings that match closely to the screen setup I've grown so accustomed to.

[1] http://github.com/ludwig/dotfiles/blob/master/.tmux.conf

Veritcal split has been integrated into GNU screen for a while now: CTRL-A |

I've been using screen every day for probably > 2 years now and had no idea you could do this. Thanks!

Neat. I was wondering when that patch would work itself into the main line. I had been running a locally compiled version for so long that I forgot to check back on it.

So I tried it out and it fixes my 2 pet peeves of screen.

1. The defaults are sane (altscreen is on by default, emacs keys in copy mode by default, no stupid "wuff wuff" covering up my prompt, history is 2000 lines instead screen's almost useless 100).

2. Screen sometimes interacts badly with Terminal.app on my mac. I can't run aptitude from within screen on my mac without it randomly switching to graphic charset mode. Also running emacs inside screen sometime results in the arrow keys not working.

I like it so far. I think I'll switch for a while and see how it goes...

1] This is easily fixed in .screenrc:

startup_message off

defscrollback 10000

Also vbell off. Incidentally, byobu is an excellent wrapper around screen without all the problems he mentioned. One caveat: it was made mainly for ubuntu, so the ports for the rest may not be of the best quality.

There is also a part 2. Very well written sir!

http://blog.hawkhost.com/2010/07/02/tmux-%E2%80%93-the-termi...

I made the switch to tmux only after very briefly using screen. It helped me in switching away from Textmate to vim, because I could use it like a tiling window manager and have vim going on the right, and man pages/documentation/irssi on the left.

As someone who already has a screen session setup, with bindings and a status bar, and auto-creating screens, is there anything tmux brings to the table?

I've been using screen for years. All my terminal sessions are within one or two screen sessions. So I'm probably in a similar situation to you: I'm used to it, I have it customised to how I like it, and it "just works".

I recently switched to tmux and after several weeks of testig it out I think I'm going to make the change permanent.

It is actively being developed (screen is currently stagnant), it has a much greater scripting capability, it is rock solid, its region-splitting capabilities is hugely better than screen's (that is the single reason I switched to tmux initially).

On the con side: it seems you have to use the metakey to enable the scrollback buffer. I really hate that, but now I've used it for a while I'm used to it and it is not as annoying as it was at first. (I'm always using 'ls' in a terminal and I invariably want to scroll up to see the first few entries. With screen I could just shift-PgUp, with tmux I do ctrl-A, PgUp. It's ok.)

Other than those things, tmux seems to do everything screen can do in terms of resuming sessions and so on.

The enhanced region splitting makes it superior for my use, so I will stick with tmux.

I used screen for a while and then switched to tmux for the same reason (region splitting). These days, I am not even using tmux anymore and just using emacs with new buffers running eshell. Serves me well.

Hey, if anybody here is using tmux or dvtm (or similar) and wants reflowing text, I've been working a program to do that: http://github.com/aplusbi/reflow (you'll probably want the 0.1 branch). It's written in OCaml and requires OCamlbuild.

If you don't know what reflowing text means, run tmux, get some output on the terminal (say from `ls` or something), and then split the window. You'll notice that your output gets cut off. reflow is a terminal wrapper that reformats the text when the terminal is resized.

At the moment it's still really early in its development, but it's working on all the systems I've tested it on. I'm considering adding better scroll-back support, more customization and possibly using the Knuth reflowing algorithm.

Great blog post.

Has anybody benefited from using tmux with emacs? Or, when in emacs, is running tmux too overkill?

I find it helpful to be able to pop up a pane alongside emacs to do shell stuff. I realize you can do it in emacs but this way I can be certain my existing emacs buffers aren't going to be shuffled in any way. It's always nice to have options, even if there are multiple ways to do the same thing.

In case you've gotten used to just using screen on your local machine as I have, as a handy way to manage multiple "ascii desktops":

A useful trick is to ssh to a remote machine and start a screen session on the remote machine. Then you can start long-running jobs on the remote machine, detach, turn your local machine off, come back later, and ssh and re-attach to check on progress.

I assume tmux and similar screen-like programs can all do this.

tmux a(ttach) is the same as screen -r

screen advantages: ships with Mac OS X, and most Linux distros. Can run against a serial port, so you don't need to install a "terminal emulator" program, all of which tend to suck more than screen.

tmux advantages: much better default setup than screen. Ships by default with OpenBSD. Ctrl-B key doesn't conflict with as many default keystrokes as screen's Ctrl-A.

Last time I played with tmux (v 1.1-1) I found the following behavior a bit of a show stopper:

* start tmux from ~/project1: windows created all start in path ~/project1

* start tmux from ~/project2: first window has path ~/project2 but subsequent windows have path ~/project1

haven't had time though to check if this is a (known) bug

looks quite similar to dtvm which I have been using lately. only complaint over both dtvm and this from my side would be no tabs like in dvm. I like the philosophy of both dtvm and dvm, a simple self documenting header file for config and documentation.

I was frustrated with a project I was working on a couple weeks back and wanted to just hack on something totally different. As a result, I wrote code to display the clock in tmux as a binary clock[1]. As someone who does not do a lot of C coding, I found the code base to be very clean and easy to figure out.

[1]: http://bitbucket.org/mdg/tmux/

Reply on news.ycombinator.com