I just made that switch myself recently, and found getting things set up how I liked them with screen extremely frustrating. With tmux, I was all set within an hour. I tried screen for a couple of weeks, then tried tmux, and was hooked almost immediately.

I found scripting tmux to be much simpler, and setting up things like having the bottom bar notify me if there was new text in a window was so much easier in tmux.

Install on OS X was easy: brew install tmux

As a side benefit, having nested screen sessions (or nested tmux sessions) is kind of annoying. My solution is to use tmux on my laptop, and run screen on all of my servers. That way there's no nesting. I don't spend much time mucking around on the server, but so far I've found this quite satisfactory.

Fedora 15 comes with screen-4.1.0-0.3.20101110git066b098.fc15.x86_64. It's not an official release, but it doesn't mean that user can not benefit from new features like the vertical splitting mentioned by rbanffy.

For one, Screen is everywhere. I can go from system to system and it'll be there.

Also, I use a Mac and Tmux doesn't work with the Mac's clipboard; probably the biggest reason I can't use Tmux.

Screen has had vertical splitting for sometime now, just get a beta release or build from source (https://savannah.gnu.org/git/?group=screen). That's what I use and find very stable.

  > Screen has had vertical splitting for
  > sometime now, just get a beta release
  > or build from source

  > Screen is everywhere. I can go from
  > system to system and it'll be there.

Same story on Linux. Integrating the tmux or screen clipboards with the X clipboard is DIY.

I get that it's annoying if you're frequently moving data back and forth between these worlds, but I personally do this less and less as the years go by, and spend more and more time in the terminal. tmux has made this pretty pleasant. I have my editor (vim), mail (mutt), chat (irssi+bitlbee), and a browser for reading documentation (w3m), all at fixed window assignments. Copy and paste between these programs using the keyboard for text selection is nice. Reliable activity notifications for the mail and chat windows are something I can't live without anymore (and something screen lacks).

I'm legitimately curious as I've been experimenting with the same cli apps and found some worth it (vim, weechat) and others a regression.

Is it just for the ability to use these programs on a remote server? Or do they improve workflow even on a local machine?

Not sure what you're asking here. I use X but switch between a fullscreen terminal running tmux and fullscreen Chrome. With tmux, you can multiplex a bunch of terminal windows, monitoring some of them for activity. For instance, if new mail arrives, mutt will repaint and its window will be flagged as active in the status bar at bottom.

I also use this as an ad-hoc notifications system: for example, kick off a long build, redirecting output to a file, and monitor its tmux window. When the process exits your shell prompt is printed again (activity!) and voila, you get a "build is complete" notification.

Is it just for the ability to use these programs on a remote server? Or do they improve workflow even on a local machine?

YMMV of course, but...

I use both remote and local tmux sessions. Reattaching to remote sessions and picking up where you left off is obviously useful, but it also comes in handy locally if X crashes, or if you need to remote in from a different machine. I build up a fair amount of "working state" inside a tmux session: an editor with tens or hundreds of files open, sql prompts, chat logs, shells with important history, etc. With suspend / resume you can go for months without having to tear down and rebuild that state. If I entrusted all that state to a gui, it certainly wouldn't live as long.

As for workflow, the world of text and text manipulation really has advantages once you get comfortable in it. Random access to programs is O(1) fast: in my setup, "^A 0" for editor, "^A 4" for mail, etc and it's obvious what number to hit for other ones. Compare to Alt-Tab style switching which is more like O(n) as you cycle through the list. I find the fine-grain motor control of mouse-based copy and paste cognitively wasteful and annoying. Keyboard-based selection of text lets you use your favorite editor bindings to jump to word boundaries, end of sentence, end of line etc and is much more pleasant. Searching any terminal output via "/" or "?" is handy.

You get the drift. ;)

Thanks also for elaborating about workflow. I use a similar setup with chrome and xterm and a tiling WM. I like the idea of integrating tmux and suspend/resume to build up and return to state.

It's possible in tmux, but kind of annoying (the best solution I've found requires another key combo press to push your copy into the system clipboard).

What the parent refers to is the ability to press C-b to enter the buffer scroll, then select text there and unfortunately -- not -- having that available to OSX's paste buffer, but only internally inside tmux.

This means that if you want to copy that stuff to OSX's paste buffer you have to go through the intermediate step of pasting it inside a new buffer (say, Vim) inside tmux, then select it again with the standard terminal selection feature and only then it will be available to OSX's CMD+V.

hope that clears it up.

And that would be why I still use screen, for the most part. Tmux is nice, but it isn't prevalent (yet.)

I don't use OSX but in linux you press Shift then select with mouse...

tmux still has a long hill to climb.

FWIW, my .screenrc is 4 lines. My .tmuxrc is 26 lines, and all it tries to do is get a behavior comprable to screen. Ie, using the same ctrl-a, supporting ctrl-ac without needing to release ctrl before the second character, allowing titles to pass thru tmux to the title bar, etc.

  > my .screenrc is 4 lines. My .tmuxrc is 26 lines

  > all it tries to do is get a behavior comprable to screen

I've never used tmux and I find your post to be biased towards screen. tmux isn't being touted as a 'drop-in replacement' for screen, but that seems to be how you are evaluating it.

But yes, better article titles.

--- a GNU screen user who intends to switch over to tmux at some point.

tmux doesn't invent its own permissions system; it just communicates over a socket. Anyone with permissions to read the socket can join. Anyone with permissions to write to the socket can interact. It's stupid easy.

^A-| works just fine here. IIRC, it's been working for quite some time.

So vertical splitting, while not in the main tree yet, is pretty much available if you've installed GNU screen on any recent Linux distribution.

The only thing that beats it is iTerm2 on OS X in terms of ease of splitting, tabs, and ability to scroll each pane using mouse scroll wheel, etc.

They have the tab/split metaphor backwards. Real tiling WMs (such as ion3) put tabs on the individual split panes instead of having one global tab bar at the top - and for good reasons.

As it stands you can not, for example, drag an iTerm tile to its own window or group multiple sessions in one tile. This may seem minor to the casual user but is a showstopper for those of us who would benefit from the tiling the most.

I use it to copy/paste with the mouse. You can also set "UTF-8" in the options if you need.

Please send bug reports by email to nicm@users.sourceforge.net or tmux-users@lists.sourceforge.net. Please include as much of the following information as possible:

- the version of tmux you are running;

- the operating system you are using and its version;

- the terminal emulator you are using and the TERM setting when tmux was started;

- a description of the problem;

- if the problem is repeatable, the steps to repeat the problem;

- for screen corruption issues, a screenshot and the output of "infocmp $TERM" from outside tmux are often very useful.

http://tmux.svn.sourceforge.net/viewvc/tmux/trunk/FAQ

I still see little reason to part from screen after all these years, and despite various offers of "better" options troughout the years. On the other hand, I did ditch my iPhone for an Android-phone. Although it was an Android-phone not labeled as an "iPhone killer".

I doubt the people working on tmux have "killing screen" as one of their priorities (or even one of their cares). They wanted something that worked differently, and decided that going from scratch rather than using the screen codebase (either because they didn't like the code, or for licensing reasons, or they though they' be touching so much of the existing code that it would just be cleaner to start from scratch, or some combination of the above) was preferable.

It'll take a lot to replace screen, but given it offers features in its stable branch that screen doesn't have or only has in beta (the horizontal splitting talked about since ~2009 has been in beta since then) and is available standard in OpenBSD and probably optionally in every recent Liunx distribution, I can see tmux taking over some of screen's mindshare. I'm told tmux has noticeably lower memory requirements too, though will only make a difference to users who are working with very small environments like cheap VPSs on over-sold hosts or embedded environments, as screen isn't that much of a monster to start with.

FYI: I'll be sticking with screen (via byobu where available) as I know it, it works and is stable (I've not had it hang/error/crash any time in the last <more-than-a-few> years) and it is very widely available.

So basically, announcing your product as or having people talk about your product as a killer of any sort, is mostly a bad thing, be it a good product or not. You want people to say "it's very good", not "it's an X-killer".

Or at least that is my experience and opinion on "X killer" as a branding-strategy.