I'm about to get back into using GNU Screen, but I have been hearing people occasionally mention tmux as a better alternative. Does it really offer an alternative to all the features Screen offers, such as activity monitoring in different windows, etc.? What are the pros and cons of each?

migrated from stackoverflow.com Jan 21 '11 at 17:07

This question came from our site for professional and enthusiast programmers.

  • 6
    Also discussed at unix.stackexchange.com/questions/549/tmux-vs-gnu-screen – Lloyd Dewolf Jun 2 '11 at 20:32
  • 1
    In screen you can send commands to an attached session via screen -S automate_me -X stuff 'command'$(echo -ne '\015') you can't in tmux. Pretty useful if you're testing a virtualbox ISO/image and need to do some commands remotely quickly. For example I have it in a Vim command to quickly debug scripts in a Virtualbox screen. In earlier versions of tmux I found that screen handled more text passing by quickly whereas tmux crashed. Also screen doesn't require any configuration to handle UTF-8 etc. tmux does. – dezza Jun 11 '16 at 12:12
up vote 139 down vote accepted

Some of the (major) reasons I prefer tmux over screen:

  • Status bar is much easier to use. You can easily set up different text/styles for current window, windows with activity, etc. and you can put things on the left and right of the status bar, including shell commands that can be run at a specified interval (default 15s).
  • Almost any command you can run inside tmux can be run from a shell with tmux command [args]. This makes it very easily scriptable, as well as making it easy to do complex commands.
  • Much more accurate automatic window renaming. While screen sets the title based on the first word of the command, and requires shell configuration to do even that in a shell window, tmux keeps track of what processes are actually running in each window, and updates the title accordingly. This way you get dynamic renaming with any shell and zero configuration. For example: Let's say you're running Z Shell; the window's name would be "zsh". Now let's say you want to edit some configuration file, so you type sudo emacs /etc/somefile. While sudo is asking for your password, the window's name will be "sudo", but once you've done that and sudo launches emacs, the title will be "emacs". When you're all done and you exit emacs, the title will change back to "zsh". This is pretty useful for keeping track of windows, and it can also be especially useful in specific situations, like if you have some long-running process in another window that occasionally prompts you for input using dialog; the window name would change to "dialog" when that happened, so you would know you had to switch to that window and do something.
  • Nicer session handling (IMHO). You can do a lot more with sessions within tmux itself. You can easily switch, rename, etc. and you can move and share windows between sessions. It also has a different model, where each user has a server which controls his/her sessions and which the client connects to. The downside of this is that if the server crashes, you lose everything; I've never had the server crash on me, though.
  • tmux seems to be more actively developed. There are updates pretty frequently, and you can file a bug report or feature request according to this FAQ and get an answer within a few days.

Those are only the major things that immediately come to mind. There are other little things, too, and I'm sure I'm forgetting some things. It's definitely worth it to give tmux a try, though.

(Sessions are collections of windows that can be detached and reattached later. Windows may contain one or more panes. For example configs, check out here and here.)


  • Pros
    • Can send keys to other panes, kind of like an IDE
    • Easy keybindings -- with the right config, you'll feel at home from Vim or Screen
    • Vim-ish and Emacs-ish bindings built-in
    • Good layout management, a lot like a tiling window manager
    • Unicode seems to Just Work with modern terminals
    • Some terminal issues fixed with TERM=tmux
  • Cons
    • Slow -- unsure why, but keystrokes seem laggy No more issues with slowness
    • Multiplexing forces the whole session width and height to the smallest attached terminal
    • Has crashed multiple times on Mac OS X, losing the entire session
    • Has failed on Linux after upgrade, where I couldn't reconnect to my old session
    • Misses command keystrokes occasionally - ^A ^[ takes a few tries for copy mode
    • Can't move a pane from one window to another Fixed with the join-pane command
    • No line unwrapping (or "reflow" or "rewrap") after terminal width change (window resizing)

GNU Screen

  • Pros
    • Extremely stable (v1.0 was in 1987)
    • Some terminal issues fixed with TERM=screen
    • Emacs-ish bindings built in
    • Easy to move and control horizontal panes
    • When multiplexing, any attached terminal can resize a pane
  • Cons
    • No vertical splits without patch (except on Ubuntu)
    • Pane splits are lost when detaching
    • Getting Unicode to work takes a little finesse and determination
    • Crazy status line configuration
  • Are the laggy keystrokes only when pressing Esc? tmux has a delay where it waits to see if you're entering an xterm sequence or just a lone Esc, and combined with vim's, it can seem pretty laggy. Set escape-time to a lower value like 50. – Eevee Jun 4 '11 at 21:37
  • It's also funny you say ^A ^[ doesn't work sometimes; I have the same problem with screen, but never tmux! And I believe you can move panes around with join-pane. – Eevee Jun 4 '11 at 21:38
  • I find that screen uses quite a lot more memory, which could be included as a disadvantage. – paradroid Aug 14 '11 at 22:31
  • 5
    Well, tmux sucks with vim, in some cases (mine namely), no solution ever posted anywhere works, and even people spending some time solving the issue of mine weren't able to. It's annoying when you can't use <C-Left> and <C-Right> in vim. – yo' Feb 19 '14 at 10:14
  • No vertical splits without patch (except on Ubuntu) I don't think that is true. I've been using screen for a few years now and I never had any issues splitting horizontally or vertically on Debian and Fedora. Even on Android with Termux it works like a charm. – Forivin Apr 18 at 15:54

A pro for screen: it is available pretty much out-of-the-box on Linux and Solaris. When you have to switch back and forth between platforms, it is nice not to have the mental context switch.

I'm sure you can get tmux compiled on any platform, but sometimes you have just enough access to make use of screen, but the actual system admins don't really want to add any software that isn't absolutely necessary.

The things I get out of tmux I don't get easily in screen are:

  1. make vertical pane splits
  2. multiplexing, which we use for remote and local pairing.
  • 5
  • As previous post mentions, screen has vertical pane splits (requires a patch w/o Ubuntu, apparently). Also, multiplexing works fine and has for many years. – EntangledLoops Jan 27 '17 at 16:25
  • vertical splits have been in mainline screen since 4.2, released in 2014. Many distros ship very old versions, especially Apple. – Neal Fultz May 3 '17 at 6:07
  • Both points are incorrect. – Forivin Apr 18 at 16:08

I've been using tmux for about 2 days now, so my unbridled enthusiasm for it has not yet been tempered by hitting annoying use cases. While going through the usual growing pains of transitioning from one program to another, I was struck by several positive features, but the feature that has me believing I'll never go back to screen is the utility of the copy-n-paste mode. In screen, you cannot enter copy mode, scroll back in the buffer, and then go to another window. In tmux, you can have multiple windows simultaneously in copy mode with the buffer scrolled back to different positions. Also, there are multiple copy buffers. And you don't need to patch the source to get fFtT cursor movement.

I have replaced GNU Screen with tmux in every use case except one—when I need a HyperTerminal equivalent to connect to serial ports. As Aaron Toponce noted in his article "Connecting To Serial Null Modems With GNU Screen", the tmux FAQ states:

screen has builtin serial and telnet support; this is bloat and is unlikely to be added to tmux.

My typical tmux use-case is to create multi-pane and multi-window development sessions in combination with tmuxinator. If you want to learn tmux, I recommend getting Brian P. Hogan's book, tmux: Productive Mouse-Free Development.

I would say that screen’s availability is its strength, but its windowing system is not as easy to handle as ’s. I must say I use most of the time at present and as a result have plenty of terminal tabs instead of Screen windows.

@Jed Schneider: You can get vertical pane splits with Ctrl+A and then | (vertical bar).

One of the maintainers of tmux, Thomas Adam, is also listed as a maintainer for the screen project although he only touches tmux code, which is huge pro of tmux over screen.

Has anyone considered you may be less likely to lose your session running screen, depending on how you use it?

I've been learning tmux over the last few days and really like it, especially the amazing customization that can be done in ~/.tmux.conf.

But it occurred to me, with screen, at least in the way I use it most, sessions live on the remote machine I'm running screen on. Usually to run a long running command which I may then detach from and come back to later. I only rarely run screen locally from my workstation to connect to other hosts.

With tmux, at least in the way I use it most, it and its connected sessions are running locally on my workstation.

If my workstation loses its connection, I imagine tmux drops connections to all the servers I was connected to?

I suppose that could be a pro for screen over tmux, depending on how you use it?

  • 2
    Is that was a questions or an answers? The purpose of both - screen and tmux is do not use terminals file's descriptor(stdin,stdout,stderr) assigned to particular connection by OS, that is why both of them can survive network disruption and continue to run. If you setup external connections from tmux/screen to remote resources and those connection get broken it is not related at all to tmux/screen since both of them can not control such things. I suggest you to edit your answer if you dont want to be flagged since answer supposed to answer a question – Alex Jan 11 '17 at 19:02

protected by bwDraco Jan 10 '17 at 23:21

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.