tmux vs. screen
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?
gnu-screen tmux
migrated from stackoverflow.com Jan 21 '11 at 17:07
This question came from our site for professional and enthusiast programmers.
add a comment |
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?
gnu-screen tmux
migrated from stackoverflow.com Jan 21 '11 at 17:07
This question came from our site for professional and enthusiast programmers.
7
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 viascreen -S automate_me -X stuff 'command'$(echo -ne '15')
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
add a comment |
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?
gnu-screen tmux
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?
gnu-screen tmux
gnu-screen tmux
edited Jan 17 '16 at 18:16
Matthew Rankin
2,52531924
2,52531924
asked Jan 6 '11 at 15:20
Alison R.Alison R.
1,60521412
1,60521412
migrated from stackoverflow.com Jan 21 '11 at 17:07
This question came from our site for professional and enthusiast programmers.
migrated from stackoverflow.com Jan 21 '11 at 17:07
This question came from our site for professional and enthusiast programmers.
7
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 viascreen -S automate_me -X stuff 'command'$(echo -ne '15')
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
add a comment |
7
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 viascreen -S automate_me -X stuff 'command'$(echo -ne '15')
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
7
7
Also discussed at unix.stackexchange.com/questions/549/tmux-vs-gnu-screen
– Lloyd Dewolf
Jun 2 '11 at 20:32
Also discussed at unix.stackexchange.com/questions/549/tmux-vs-gnu-screen
– Lloyd Dewolf
Jun 2 '11 at 20:32
1
1
In screen you can send commands to an attached session via
screen -S automate_me -X stuff 'command'$(echo -ne '15')
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
In screen you can send commands to an attached session via
screen -S automate_me -X stuff 'command'$(echo -ne '15')
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
add a comment |
9 Answers
9
active
oldest
votes
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 withtmux 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 typesudo emacs /etc/somefile
. While sudo is asking for your password, the window's name will be "sudo", but once you've done that andsudo
launchesemacs
, the title will be "emacs". When you're all done and you exitemacs
, 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 usingdialog
; 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.
139
tmux development is more active because it's new. GNU Screen is almost 25 years old, so they've fixed most of the bugs.
– a paid nerd
May 4 '11 at 18:31
8
a paid nerd's comment is a very important qualification of your last point. And the second point as stated is not really a difference as it applies to screen as well unless you can be more specific.
– jw013
Nov 10 '11 at 4:31
14
@a paid nerd: techrepublic.com/blog/opensource/is-tmux-the-gnu-screen-killer/…
– sjas
Aug 10 '12 at 14:07
11
@apaidnerd that's a very rich statement: savannah.gnu.org/bugs/…
– Błażej Michalik
Jan 25 '17 at 2:36
add a comment |
(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.)
tmux
- 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 laggyNo 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 anotherFixed with thejoin-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 withjoin-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 withvim
, 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>
invim
.
– yo'
Feb 19 '14 at 10:14
1
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 '18 at 15:54
|
show 1 more comment
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.
add a comment |
The things I get out of tmux I don't get easily in screen are:
- make vertical pane splits
- multiplexing, which we use for remote and local pairing.
7
Doesn't screen support multiplexing with the-x
option andacladd
?
– poolie
Oct 20 '15 at 19:46
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 mainlinescreen
since 4.2, released in 2014. Many distros ship very old versions, especially Apple.
– Neal Fultz
May 3 '17 at 6:07
1
Both points are incorrect.
– Forivin
Apr 18 '18 at 16:08
2
Answer is not correct in 2018
– Alec Istomin
Sep 30 '18 at 6:14
add a comment |
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.
add a comment |
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.
add a comment |
I would say that screen’s availability is its strength, but its windowing system is not as easy to handle as tmux’s. I must say I use gnu-screen 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).
add a comment |
One of the maintainers of tmux, Thomas Adam, is also listed as a maintainer for the screen
project although he only touches tmux code. This is a huge pro of tmux over screen.
add a comment |
I've been a heavy user of Screen for a long time, but I use a version that I modified back in 2002. Mostly because I wanted to be able to have the window "next/prev" navigational ordering match the order in which new windows were created, similar to a tiling window manager like i3 or Ion. The standard Screen behavior is for 'next' and 'prev' to go by window number, so that usually a 'new' window (grabbing the smallest available number) will be located elsewhere than the 'next' window - confusing if you don't remember the numbers. My preferred behavior has since been implemented in Tmux as a flag to the new-window command in 2010, and the renumber-windows option in 2012. My Screen patch, which I tried to make as acceptable as possible, including documentation additions and so forth, did not generate any discussion on the Screen list in July 2002 (then "screen@informatik.uni-erlangen.de", can't find archives). In fact it was not even acknowledged, even when I sent it again a year later.
Since 2002, I "rebased" my patch a couple of times to apply to newer versions of Screen. However, when I got to version 4.3 (2015) I noticed an undocumented change which broke one of my uses of screen - namely that 'stuff' now interpolates environment variables. I didn't need that feature, and I couldn't figure out how to easily escape the argument to 'stuff' (so that I could send text containing dollar signs) so I just kept using version 4.0 (from 2004).
I use Screen's 'stuff' ('send-keys' in Tmux) in an Emacs function which sends the contents of the current Emacs region to a specific window number. That way when I am writing code in a scripting language, I open an interpreter, I give the intepreter window a special number, and then I can send lines of code from my editor window directly to the interpreter window using this Emacs binding. It's hacky but I like it better than the pure-Emacs solution, since I can also interact with the interpreter in its Screen window using standard keystrokes. It's a bit like a GUI IDE, but I don't have to use the mouse or stare at a blinking cursor.
Another feature I implemented in my patch is the ability to "mark" a window, and then to reposition the marked window to be "next" after the current one. For me this is a much more natural way of reordering windows than renumbering; it is like the copy/paste paradigm, or "drag-and-drop". (I recently figured out how to do this in i3 as well.)
It should be possible to do the same thing in Tmux, for example as of 2015 there is a facility for "marking" a pane. Or perhaps a more elementary solution could be worked out with stateful shell scripts. I implemented a short script and keybindings to try the "marked pane" method, and it worked a few times but then Tmux crashed with "[lost server]". Then I found Tmux crashing even without my trying to do anything complicated. Apparently it has been crashing for some users for a few years at least. Sometimes the server crashes, sometimes it starts using 100% of the CPU and becomes unresponsive. I've never seen Screen do either of these.
In theory, Tmux is superior to Screen in several ways. It has much better scriptability, meaning that you can do things like query the list of windows in the current session from the command line, which is impossible with Screen. For example in 2015 Screen added a command to "sort windows by title". I'm not sure when such a specialized command would be useful, but this and more practical variations (e.g. sort windows by CPU usage) could relatively easily be done from a shell script in Tmux. To me it would seem difficult to do anything so creative in Screen, at least without modifying the C code.
As other posters mentioned, Tmux has a single-server model which I see as the primary drawback, particularly when the server is crashing. It is possible to work around this by specifying a separate socket for each "session". Still I prefer Screen's one-server-per-session default, which seems slightly more elegant.
Working with the Screen code, back in 2002, was educational and enjoyable for me. Oddly enough, for all its additional features, Tmux has about 25% fewer lines of code than Screen (30k vs 40k). I noticed that Tmux uses many tree and list data structures, which were slightly difficult for me to understand. Screen seemed to prefer arrays.
As I understand it, because the Unix terminal interface is so stable, there is little need for the Screen or Tmux code to adapt to changes in the underlying operating system. These programs do not really have security updates like web browsers or web servers or even the shell. I haven't noticed any problems running my custom version of Screen, last updated in 2004 (except for needing to add some configuration files to prevent Systemd from deleting the socket; these files are typically part of the distribution package anyway). Perhaps I could just work around the problems I encountered in Tmux by running a Tmux version from before it started crashing. Of course, if enough users do this then it won't be very good for new users, since it means that fewer experts will be looking for bugs in the latest official versions of these programs. However, it's hard to motivate myself to switch to a product which is unstable for me (latest Tmux) or which lacks certain features that I want (standard Screen).
I know this doesn't provide an easy answer to the OP's question, but I hope that my perspective was useful.
add a comment |
9 Answers
9
active
oldest
votes
9 Answers
9
active
oldest
votes
active
oldest
votes
active
oldest
votes
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 withtmux 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 typesudo emacs /etc/somefile
. While sudo is asking for your password, the window's name will be "sudo", but once you've done that andsudo
launchesemacs
, the title will be "emacs". When you're all done and you exitemacs
, 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 usingdialog
; 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.
139
tmux development is more active because it's new. GNU Screen is almost 25 years old, so they've fixed most of the bugs.
– a paid nerd
May 4 '11 at 18:31
8
a paid nerd's comment is a very important qualification of your last point. And the second point as stated is not really a difference as it applies to screen as well unless you can be more specific.
– jw013
Nov 10 '11 at 4:31
14
@a paid nerd: techrepublic.com/blog/opensource/is-tmux-the-gnu-screen-killer/…
– sjas
Aug 10 '12 at 14:07
11
@apaidnerd that's a very rich statement: savannah.gnu.org/bugs/…
– Błażej Michalik
Jan 25 '17 at 2:36
add a comment |
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 withtmux 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 typesudo emacs /etc/somefile
. While sudo is asking for your password, the window's name will be "sudo", but once you've done that andsudo
launchesemacs
, the title will be "emacs". When you're all done and you exitemacs
, 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 usingdialog
; 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.
139
tmux development is more active because it's new. GNU Screen is almost 25 years old, so they've fixed most of the bugs.
– a paid nerd
May 4 '11 at 18:31
8
a paid nerd's comment is a very important qualification of your last point. And the second point as stated is not really a difference as it applies to screen as well unless you can be more specific.
– jw013
Nov 10 '11 at 4:31
14
@a paid nerd: techrepublic.com/blog/opensource/is-tmux-the-gnu-screen-killer/…
– sjas
Aug 10 '12 at 14:07
11
@apaidnerd that's a very rich statement: savannah.gnu.org/bugs/…
– Błażej Michalik
Jan 25 '17 at 2:36
add a comment |
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 withtmux 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 typesudo emacs /etc/somefile
. While sudo is asking for your password, the window's name will be "sudo", but once you've done that andsudo
launchesemacs
, the title will be "emacs". When you're all done and you exitemacs
, 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 usingdialog
; 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.
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 withtmux 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 typesudo emacs /etc/somefile
. While sudo is asking for your password, the window's name will be "sudo", but once you've done that andsudo
launchesemacs
, the title will be "emacs". When you're all done and you exitemacs
, 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 usingdialog
; 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.
edited Oct 31 '17 at 22:18
Victor Yarema
1193
1193
answered Jan 17 '11 at 20:36
qmegaqmega
2,1951108
2,1951108
139
tmux development is more active because it's new. GNU Screen is almost 25 years old, so they've fixed most of the bugs.
– a paid nerd
May 4 '11 at 18:31
8
a paid nerd's comment is a very important qualification of your last point. And the second point as stated is not really a difference as it applies to screen as well unless you can be more specific.
– jw013
Nov 10 '11 at 4:31
14
@a paid nerd: techrepublic.com/blog/opensource/is-tmux-the-gnu-screen-killer/…
– sjas
Aug 10 '12 at 14:07
11
@apaidnerd that's a very rich statement: savannah.gnu.org/bugs/…
– Błażej Michalik
Jan 25 '17 at 2:36
add a comment |
139
tmux development is more active because it's new. GNU Screen is almost 25 years old, so they've fixed most of the bugs.
– a paid nerd
May 4 '11 at 18:31
8
a paid nerd's comment is a very important qualification of your last point. And the second point as stated is not really a difference as it applies to screen as well unless you can be more specific.
– jw013
Nov 10 '11 at 4:31
14
@a paid nerd: techrepublic.com/blog/opensource/is-tmux-the-gnu-screen-killer/…
– sjas
Aug 10 '12 at 14:07
11
@apaidnerd that's a very rich statement: savannah.gnu.org/bugs/…
– Błażej Michalik
Jan 25 '17 at 2:36
139
139
tmux development is more active because it's new. GNU Screen is almost 25 years old, so they've fixed most of the bugs.
– a paid nerd
May 4 '11 at 18:31
tmux development is more active because it's new. GNU Screen is almost 25 years old, so they've fixed most of the bugs.
– a paid nerd
May 4 '11 at 18:31
8
8
a paid nerd's comment is a very important qualification of your last point. And the second point as stated is not really a difference as it applies to screen as well unless you can be more specific.
– jw013
Nov 10 '11 at 4:31
a paid nerd's comment is a very important qualification of your last point. And the second point as stated is not really a difference as it applies to screen as well unless you can be more specific.
– jw013
Nov 10 '11 at 4:31
14
14
@a paid nerd: techrepublic.com/blog/opensource/is-tmux-the-gnu-screen-killer/…
– sjas
Aug 10 '12 at 14:07
@a paid nerd: techrepublic.com/blog/opensource/is-tmux-the-gnu-screen-killer/…
– sjas
Aug 10 '12 at 14:07
11
11
@apaidnerd that's a very rich statement: savannah.gnu.org/bugs/…
– Błażej Michalik
Jan 25 '17 at 2:36
@apaidnerd that's a very rich statement: savannah.gnu.org/bugs/…
– Błażej Michalik
Jan 25 '17 at 2:36
add a comment |
(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.)
tmux
- 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 laggyNo 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 anotherFixed with thejoin-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 withjoin-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 withvim
, 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>
invim
.
– yo'
Feb 19 '14 at 10:14
1
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 '18 at 15:54
|
show 1 more comment
(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.)
tmux
- 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 laggyNo 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 anotherFixed with thejoin-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 withjoin-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 withvim
, 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>
invim
.
– yo'
Feb 19 '14 at 10:14
1
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 '18 at 15:54
|
show 1 more comment
(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.)
tmux
- 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 laggyNo 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 anotherFixed with thejoin-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
(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.)
tmux
- 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 laggyNo 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 anotherFixed with thejoin-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
edited May 27 '17 at 4:44
answered May 4 '11 at 18:28
a paid nerda paid nerd
1,95322431
1,95322431
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 withjoin-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 withvim
, 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>
invim
.
– yo'
Feb 19 '14 at 10:14
1
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 '18 at 15:54
|
show 1 more comment
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 withjoin-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 withvim
, 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>
invim
.
– yo'
Feb 19 '14 at 10:14
1
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 '18 at 15:54
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
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
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
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
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
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
1
1
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 '18 at 15:54
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 '18 at 15:54
|
show 1 more comment
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.
add a comment |
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.
add a comment |
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.
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.
answered Apr 10 '15 at 18:05
JustinJustin
14117
14117
add a comment |
add a comment |
The things I get out of tmux I don't get easily in screen are:
- make vertical pane splits
- multiplexing, which we use for remote and local pairing.
7
Doesn't screen support multiplexing with the-x
option andacladd
?
– poolie
Oct 20 '15 at 19:46
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 mainlinescreen
since 4.2, released in 2014. Many distros ship very old versions, especially Apple.
– Neal Fultz
May 3 '17 at 6:07
1
Both points are incorrect.
– Forivin
Apr 18 '18 at 16:08
2
Answer is not correct in 2018
– Alec Istomin
Sep 30 '18 at 6:14
add a comment |
The things I get out of tmux I don't get easily in screen are:
- make vertical pane splits
- multiplexing, which we use for remote and local pairing.
7
Doesn't screen support multiplexing with the-x
option andacladd
?
– poolie
Oct 20 '15 at 19:46
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 mainlinescreen
since 4.2, released in 2014. Many distros ship very old versions, especially Apple.
– Neal Fultz
May 3 '17 at 6:07
1
Both points are incorrect.
– Forivin
Apr 18 '18 at 16:08
2
Answer is not correct in 2018
– Alec Istomin
Sep 30 '18 at 6:14
add a comment |
The things I get out of tmux I don't get easily in screen are:
- make vertical pane splits
- multiplexing, which we use for remote and local pairing.
The things I get out of tmux I don't get easily in screen are:
- make vertical pane splits
- multiplexing, which we use for remote and local pairing.
answered Jan 6 '11 at 15:38
community wiki
Jed Schneider
7
Doesn't screen support multiplexing with the-x
option andacladd
?
– poolie
Oct 20 '15 at 19:46
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 mainlinescreen
since 4.2, released in 2014. Many distros ship very old versions, especially Apple.
– Neal Fultz
May 3 '17 at 6:07
1
Both points are incorrect.
– Forivin
Apr 18 '18 at 16:08
2
Answer is not correct in 2018
– Alec Istomin
Sep 30 '18 at 6:14
add a comment |
7
Doesn't screen support multiplexing with the-x
option andacladd
?
– poolie
Oct 20 '15 at 19:46
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 mainlinescreen
since 4.2, released in 2014. Many distros ship very old versions, especially Apple.
– Neal Fultz
May 3 '17 at 6:07
1
Both points are incorrect.
– Forivin
Apr 18 '18 at 16:08
2
Answer is not correct in 2018
– Alec Istomin
Sep 30 '18 at 6:14
7
7
Doesn't screen support multiplexing with the
-x
option and acladd
?– poolie
Oct 20 '15 at 19:46
Doesn't screen support multiplexing with the
-x
option and acladd
?– poolie
Oct 20 '15 at 19:46
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
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
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
1
1
Both points are incorrect.
– Forivin
Apr 18 '18 at 16:08
Both points are incorrect.
– Forivin
Apr 18 '18 at 16:08
2
2
Answer is not correct in 2018
– Alec Istomin
Sep 30 '18 at 6:14
Answer is not correct in 2018
– Alec Istomin
Sep 30 '18 at 6:14
add a comment |
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.
add a comment |
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.
add a comment |
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'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.
answered Apr 19 '12 at 17:30
William PursellWilliam Pursell
1,250913
1,250913
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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 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.
edited Jan 17 '16 at 16:19
answered Jan 17 '16 at 16:10
Matthew RankinMatthew Rankin
2,52531924
2,52531924
add a comment |
add a comment |
I would say that screen’s availability is its strength, but its windowing system is not as easy to handle as tmux’s. I must say I use gnu-screen 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).
add a comment |
I would say that screen’s availability is its strength, but its windowing system is not as easy to handle as tmux’s. I must say I use gnu-screen 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).
add a comment |
I would say that screen’s availability is its strength, but its windowing system is not as easy to handle as tmux’s. I must say I use gnu-screen 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).
I would say that screen’s availability is its strength, but its windowing system is not as easy to handle as tmux’s. I must say I use gnu-screen 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).
edited Aug 25 '16 at 4:53
Scott
15.7k113990
15.7k113990
answered Jun 21 '12 at 15:27
TafTTafT
18118
18118
add a comment |
add a comment |
One of the maintainers of tmux, Thomas Adam, is also listed as a maintainer for the screen
project although he only touches tmux code. This is a huge pro of tmux over screen.
add a comment |
One of the maintainers of tmux, Thomas Adam, is also listed as a maintainer for the screen
project although he only touches tmux code. This is a huge pro of tmux over screen.
add a comment |
One of the maintainers of tmux, Thomas Adam, is also listed as a maintainer for the screen
project although he only touches tmux code. This is a huge pro of tmux over screen.
One of the maintainers of tmux, Thomas Adam, is also listed as a maintainer for the screen
project although he only touches tmux code. This is a huge pro of tmux over screen.
edited Jan 24 at 18:41
answered Dec 15 '17 at 22:15
ninrodninrod
1599
1599
add a comment |
add a comment |
I've been a heavy user of Screen for a long time, but I use a version that I modified back in 2002. Mostly because I wanted to be able to have the window "next/prev" navigational ordering match the order in which new windows were created, similar to a tiling window manager like i3 or Ion. The standard Screen behavior is for 'next' and 'prev' to go by window number, so that usually a 'new' window (grabbing the smallest available number) will be located elsewhere than the 'next' window - confusing if you don't remember the numbers. My preferred behavior has since been implemented in Tmux as a flag to the new-window command in 2010, and the renumber-windows option in 2012. My Screen patch, which I tried to make as acceptable as possible, including documentation additions and so forth, did not generate any discussion on the Screen list in July 2002 (then "screen@informatik.uni-erlangen.de", can't find archives). In fact it was not even acknowledged, even when I sent it again a year later.
Since 2002, I "rebased" my patch a couple of times to apply to newer versions of Screen. However, when I got to version 4.3 (2015) I noticed an undocumented change which broke one of my uses of screen - namely that 'stuff' now interpolates environment variables. I didn't need that feature, and I couldn't figure out how to easily escape the argument to 'stuff' (so that I could send text containing dollar signs) so I just kept using version 4.0 (from 2004).
I use Screen's 'stuff' ('send-keys' in Tmux) in an Emacs function which sends the contents of the current Emacs region to a specific window number. That way when I am writing code in a scripting language, I open an interpreter, I give the intepreter window a special number, and then I can send lines of code from my editor window directly to the interpreter window using this Emacs binding. It's hacky but I like it better than the pure-Emacs solution, since I can also interact with the interpreter in its Screen window using standard keystrokes. It's a bit like a GUI IDE, but I don't have to use the mouse or stare at a blinking cursor.
Another feature I implemented in my patch is the ability to "mark" a window, and then to reposition the marked window to be "next" after the current one. For me this is a much more natural way of reordering windows than renumbering; it is like the copy/paste paradigm, or "drag-and-drop". (I recently figured out how to do this in i3 as well.)
It should be possible to do the same thing in Tmux, for example as of 2015 there is a facility for "marking" a pane. Or perhaps a more elementary solution could be worked out with stateful shell scripts. I implemented a short script and keybindings to try the "marked pane" method, and it worked a few times but then Tmux crashed with "[lost server]". Then I found Tmux crashing even without my trying to do anything complicated. Apparently it has been crashing for some users for a few years at least. Sometimes the server crashes, sometimes it starts using 100% of the CPU and becomes unresponsive. I've never seen Screen do either of these.
In theory, Tmux is superior to Screen in several ways. It has much better scriptability, meaning that you can do things like query the list of windows in the current session from the command line, which is impossible with Screen. For example in 2015 Screen added a command to "sort windows by title". I'm not sure when such a specialized command would be useful, but this and more practical variations (e.g. sort windows by CPU usage) could relatively easily be done from a shell script in Tmux. To me it would seem difficult to do anything so creative in Screen, at least without modifying the C code.
As other posters mentioned, Tmux has a single-server model which I see as the primary drawback, particularly when the server is crashing. It is possible to work around this by specifying a separate socket for each "session". Still I prefer Screen's one-server-per-session default, which seems slightly more elegant.
Working with the Screen code, back in 2002, was educational and enjoyable for me. Oddly enough, for all its additional features, Tmux has about 25% fewer lines of code than Screen (30k vs 40k). I noticed that Tmux uses many tree and list data structures, which were slightly difficult for me to understand. Screen seemed to prefer arrays.
As I understand it, because the Unix terminal interface is so stable, there is little need for the Screen or Tmux code to adapt to changes in the underlying operating system. These programs do not really have security updates like web browsers or web servers or even the shell. I haven't noticed any problems running my custom version of Screen, last updated in 2004 (except for needing to add some configuration files to prevent Systemd from deleting the socket; these files are typically part of the distribution package anyway). Perhaps I could just work around the problems I encountered in Tmux by running a Tmux version from before it started crashing. Of course, if enough users do this then it won't be very good for new users, since it means that fewer experts will be looking for bugs in the latest official versions of these programs. However, it's hard to motivate myself to switch to a product which is unstable for me (latest Tmux) or which lacks certain features that I want (standard Screen).
I know this doesn't provide an easy answer to the OP's question, but I hope that my perspective was useful.
add a comment |
I've been a heavy user of Screen for a long time, but I use a version that I modified back in 2002. Mostly because I wanted to be able to have the window "next/prev" navigational ordering match the order in which new windows were created, similar to a tiling window manager like i3 or Ion. The standard Screen behavior is for 'next' and 'prev' to go by window number, so that usually a 'new' window (grabbing the smallest available number) will be located elsewhere than the 'next' window - confusing if you don't remember the numbers. My preferred behavior has since been implemented in Tmux as a flag to the new-window command in 2010, and the renumber-windows option in 2012. My Screen patch, which I tried to make as acceptable as possible, including documentation additions and so forth, did not generate any discussion on the Screen list in July 2002 (then "screen@informatik.uni-erlangen.de", can't find archives). In fact it was not even acknowledged, even when I sent it again a year later.
Since 2002, I "rebased" my patch a couple of times to apply to newer versions of Screen. However, when I got to version 4.3 (2015) I noticed an undocumented change which broke one of my uses of screen - namely that 'stuff' now interpolates environment variables. I didn't need that feature, and I couldn't figure out how to easily escape the argument to 'stuff' (so that I could send text containing dollar signs) so I just kept using version 4.0 (from 2004).
I use Screen's 'stuff' ('send-keys' in Tmux) in an Emacs function which sends the contents of the current Emacs region to a specific window number. That way when I am writing code in a scripting language, I open an interpreter, I give the intepreter window a special number, and then I can send lines of code from my editor window directly to the interpreter window using this Emacs binding. It's hacky but I like it better than the pure-Emacs solution, since I can also interact with the interpreter in its Screen window using standard keystrokes. It's a bit like a GUI IDE, but I don't have to use the mouse or stare at a blinking cursor.
Another feature I implemented in my patch is the ability to "mark" a window, and then to reposition the marked window to be "next" after the current one. For me this is a much more natural way of reordering windows than renumbering; it is like the copy/paste paradigm, or "drag-and-drop". (I recently figured out how to do this in i3 as well.)
It should be possible to do the same thing in Tmux, for example as of 2015 there is a facility for "marking" a pane. Or perhaps a more elementary solution could be worked out with stateful shell scripts. I implemented a short script and keybindings to try the "marked pane" method, and it worked a few times but then Tmux crashed with "[lost server]". Then I found Tmux crashing even without my trying to do anything complicated. Apparently it has been crashing for some users for a few years at least. Sometimes the server crashes, sometimes it starts using 100% of the CPU and becomes unresponsive. I've never seen Screen do either of these.
In theory, Tmux is superior to Screen in several ways. It has much better scriptability, meaning that you can do things like query the list of windows in the current session from the command line, which is impossible with Screen. For example in 2015 Screen added a command to "sort windows by title". I'm not sure when such a specialized command would be useful, but this and more practical variations (e.g. sort windows by CPU usage) could relatively easily be done from a shell script in Tmux. To me it would seem difficult to do anything so creative in Screen, at least without modifying the C code.
As other posters mentioned, Tmux has a single-server model which I see as the primary drawback, particularly when the server is crashing. It is possible to work around this by specifying a separate socket for each "session". Still I prefer Screen's one-server-per-session default, which seems slightly more elegant.
Working with the Screen code, back in 2002, was educational and enjoyable for me. Oddly enough, for all its additional features, Tmux has about 25% fewer lines of code than Screen (30k vs 40k). I noticed that Tmux uses many tree and list data structures, which were slightly difficult for me to understand. Screen seemed to prefer arrays.
As I understand it, because the Unix terminal interface is so stable, there is little need for the Screen or Tmux code to adapt to changes in the underlying operating system. These programs do not really have security updates like web browsers or web servers or even the shell. I haven't noticed any problems running my custom version of Screen, last updated in 2004 (except for needing to add some configuration files to prevent Systemd from deleting the socket; these files are typically part of the distribution package anyway). Perhaps I could just work around the problems I encountered in Tmux by running a Tmux version from before it started crashing. Of course, if enough users do this then it won't be very good for new users, since it means that fewer experts will be looking for bugs in the latest official versions of these programs. However, it's hard to motivate myself to switch to a product which is unstable for me (latest Tmux) or which lacks certain features that I want (standard Screen).
I know this doesn't provide an easy answer to the OP's question, but I hope that my perspective was useful.
add a comment |
I've been a heavy user of Screen for a long time, but I use a version that I modified back in 2002. Mostly because I wanted to be able to have the window "next/prev" navigational ordering match the order in which new windows were created, similar to a tiling window manager like i3 or Ion. The standard Screen behavior is for 'next' and 'prev' to go by window number, so that usually a 'new' window (grabbing the smallest available number) will be located elsewhere than the 'next' window - confusing if you don't remember the numbers. My preferred behavior has since been implemented in Tmux as a flag to the new-window command in 2010, and the renumber-windows option in 2012. My Screen patch, which I tried to make as acceptable as possible, including documentation additions and so forth, did not generate any discussion on the Screen list in July 2002 (then "screen@informatik.uni-erlangen.de", can't find archives). In fact it was not even acknowledged, even when I sent it again a year later.
Since 2002, I "rebased" my patch a couple of times to apply to newer versions of Screen. However, when I got to version 4.3 (2015) I noticed an undocumented change which broke one of my uses of screen - namely that 'stuff' now interpolates environment variables. I didn't need that feature, and I couldn't figure out how to easily escape the argument to 'stuff' (so that I could send text containing dollar signs) so I just kept using version 4.0 (from 2004).
I use Screen's 'stuff' ('send-keys' in Tmux) in an Emacs function which sends the contents of the current Emacs region to a specific window number. That way when I am writing code in a scripting language, I open an interpreter, I give the intepreter window a special number, and then I can send lines of code from my editor window directly to the interpreter window using this Emacs binding. It's hacky but I like it better than the pure-Emacs solution, since I can also interact with the interpreter in its Screen window using standard keystrokes. It's a bit like a GUI IDE, but I don't have to use the mouse or stare at a blinking cursor.
Another feature I implemented in my patch is the ability to "mark" a window, and then to reposition the marked window to be "next" after the current one. For me this is a much more natural way of reordering windows than renumbering; it is like the copy/paste paradigm, or "drag-and-drop". (I recently figured out how to do this in i3 as well.)
It should be possible to do the same thing in Tmux, for example as of 2015 there is a facility for "marking" a pane. Or perhaps a more elementary solution could be worked out with stateful shell scripts. I implemented a short script and keybindings to try the "marked pane" method, and it worked a few times but then Tmux crashed with "[lost server]". Then I found Tmux crashing even without my trying to do anything complicated. Apparently it has been crashing for some users for a few years at least. Sometimes the server crashes, sometimes it starts using 100% of the CPU and becomes unresponsive. I've never seen Screen do either of these.
In theory, Tmux is superior to Screen in several ways. It has much better scriptability, meaning that you can do things like query the list of windows in the current session from the command line, which is impossible with Screen. For example in 2015 Screen added a command to "sort windows by title". I'm not sure when such a specialized command would be useful, but this and more practical variations (e.g. sort windows by CPU usage) could relatively easily be done from a shell script in Tmux. To me it would seem difficult to do anything so creative in Screen, at least without modifying the C code.
As other posters mentioned, Tmux has a single-server model which I see as the primary drawback, particularly when the server is crashing. It is possible to work around this by specifying a separate socket for each "session". Still I prefer Screen's one-server-per-session default, which seems slightly more elegant.
Working with the Screen code, back in 2002, was educational and enjoyable for me. Oddly enough, for all its additional features, Tmux has about 25% fewer lines of code than Screen (30k vs 40k). I noticed that Tmux uses many tree and list data structures, which were slightly difficult for me to understand. Screen seemed to prefer arrays.
As I understand it, because the Unix terminal interface is so stable, there is little need for the Screen or Tmux code to adapt to changes in the underlying operating system. These programs do not really have security updates like web browsers or web servers or even the shell. I haven't noticed any problems running my custom version of Screen, last updated in 2004 (except for needing to add some configuration files to prevent Systemd from deleting the socket; these files are typically part of the distribution package anyway). Perhaps I could just work around the problems I encountered in Tmux by running a Tmux version from before it started crashing. Of course, if enough users do this then it won't be very good for new users, since it means that fewer experts will be looking for bugs in the latest official versions of these programs. However, it's hard to motivate myself to switch to a product which is unstable for me (latest Tmux) or which lacks certain features that I want (standard Screen).
I know this doesn't provide an easy answer to the OP's question, but I hope that my perspective was useful.
I've been a heavy user of Screen for a long time, but I use a version that I modified back in 2002. Mostly because I wanted to be able to have the window "next/prev" navigational ordering match the order in which new windows were created, similar to a tiling window manager like i3 or Ion. The standard Screen behavior is for 'next' and 'prev' to go by window number, so that usually a 'new' window (grabbing the smallest available number) will be located elsewhere than the 'next' window - confusing if you don't remember the numbers. My preferred behavior has since been implemented in Tmux as a flag to the new-window command in 2010, and the renumber-windows option in 2012. My Screen patch, which I tried to make as acceptable as possible, including documentation additions and so forth, did not generate any discussion on the Screen list in July 2002 (then "screen@informatik.uni-erlangen.de", can't find archives). In fact it was not even acknowledged, even when I sent it again a year later.
Since 2002, I "rebased" my patch a couple of times to apply to newer versions of Screen. However, when I got to version 4.3 (2015) I noticed an undocumented change which broke one of my uses of screen - namely that 'stuff' now interpolates environment variables. I didn't need that feature, and I couldn't figure out how to easily escape the argument to 'stuff' (so that I could send text containing dollar signs) so I just kept using version 4.0 (from 2004).
I use Screen's 'stuff' ('send-keys' in Tmux) in an Emacs function which sends the contents of the current Emacs region to a specific window number. That way when I am writing code in a scripting language, I open an interpreter, I give the intepreter window a special number, and then I can send lines of code from my editor window directly to the interpreter window using this Emacs binding. It's hacky but I like it better than the pure-Emacs solution, since I can also interact with the interpreter in its Screen window using standard keystrokes. It's a bit like a GUI IDE, but I don't have to use the mouse or stare at a blinking cursor.
Another feature I implemented in my patch is the ability to "mark" a window, and then to reposition the marked window to be "next" after the current one. For me this is a much more natural way of reordering windows than renumbering; it is like the copy/paste paradigm, or "drag-and-drop". (I recently figured out how to do this in i3 as well.)
It should be possible to do the same thing in Tmux, for example as of 2015 there is a facility for "marking" a pane. Or perhaps a more elementary solution could be worked out with stateful shell scripts. I implemented a short script and keybindings to try the "marked pane" method, and it worked a few times but then Tmux crashed with "[lost server]". Then I found Tmux crashing even without my trying to do anything complicated. Apparently it has been crashing for some users for a few years at least. Sometimes the server crashes, sometimes it starts using 100% of the CPU and becomes unresponsive. I've never seen Screen do either of these.
In theory, Tmux is superior to Screen in several ways. It has much better scriptability, meaning that you can do things like query the list of windows in the current session from the command line, which is impossible with Screen. For example in 2015 Screen added a command to "sort windows by title". I'm not sure when such a specialized command would be useful, but this and more practical variations (e.g. sort windows by CPU usage) could relatively easily be done from a shell script in Tmux. To me it would seem difficult to do anything so creative in Screen, at least without modifying the C code.
As other posters mentioned, Tmux has a single-server model which I see as the primary drawback, particularly when the server is crashing. It is possible to work around this by specifying a separate socket for each "session". Still I prefer Screen's one-server-per-session default, which seems slightly more elegant.
Working with the Screen code, back in 2002, was educational and enjoyable for me. Oddly enough, for all its additional features, Tmux has about 25% fewer lines of code than Screen (30k vs 40k). I noticed that Tmux uses many tree and list data structures, which were slightly difficult for me to understand. Screen seemed to prefer arrays.
As I understand it, because the Unix terminal interface is so stable, there is little need for the Screen or Tmux code to adapt to changes in the underlying operating system. These programs do not really have security updates like web browsers or web servers or even the shell. I haven't noticed any problems running my custom version of Screen, last updated in 2004 (except for needing to add some configuration files to prevent Systemd from deleting the socket; these files are typically part of the distribution package anyway). Perhaps I could just work around the problems I encountered in Tmux by running a Tmux version from before it started crashing. Of course, if enough users do this then it won't be very good for new users, since it means that fewer experts will be looking for bugs in the latest official versions of these programs. However, it's hard to motivate myself to switch to a product which is unstable for me (latest Tmux) or which lacks certain features that I want (standard Screen).
I know this doesn't provide an easy answer to the OP's question, but I hope that my perspective was useful.
answered Jan 16 at 6:25
MetamorphicMetamorphic
14317
14317
add a comment |
add a comment |
7
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 '15')
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