Is tmux the GNU Screen killer?(techrepublic.com)
techrepublic.com
Is tmux the GNU Screen killer?
http://www.techrepublic.com/blog/opensource/is-tmux-the-gnu-screen-killer/1901
16 comments
> There was talk of a version 4.1, which would include this functionality, being released “soon” — but that talk was as far back as February 2007, and GNU Screen 4.1 still has not materialized.
Fedora 15 comes with screen-4.1.0-0.3.20101110git066b098.fc15.x86_64. It's not an official release, but it doesn't mean that user can not benefit from new features like the vertical splitting mentioned by rbanffy.
Fedora 15 comes with screen-4.1.0-0.3.20101110git066b098.fc15.x86_64. It's not an official release, but it doesn't mean that user can not benefit from new features like the vertical splitting mentioned by rbanffy.
I found it to be quite buggy, however, so I built 4.00.03 from source and use that instead. (Lack of vertical split doesn't bother me very much.)
Tmux is slightly nicer than GNU Screen is some respects but I still use GNU Screen.
For one, Screen is everywhere. I can go from system to system and it'll be there.
Also, I use a Mac and Tmux doesn't work with the Mac's clipboard; probably the biggest reason I can't use Tmux.
Screen has had vertical splitting for sometime now, just get a beta release or build from source (https://savannah.gnu.org/git/?group=screen). That's what I use and find very stable.
For one, Screen is everywhere. I can go from system to system and it'll be there.
Also, I use a Mac and Tmux doesn't work with the Mac's clipboard; probably the biggest reason I can't use Tmux.
Screen has had vertical splitting for sometime now, just get a beta release or build from source (https://savannah.gnu.org/git/?group=screen). That's what I use and find very stable.
This:
> Screen has had vertical splitting for
> sometime now, just get a beta release
> or build from source
> Screen is everywhere. I can go from
> system to system and it'll be there.
[deleted]
> Also, I use a Mac and Tmux doesn't work with the Mac's clipboard.
Same story on Linux. Integrating the tmux or screen clipboards with the X clipboard is DIY.
I get that it's annoying if you're frequently moving data back and forth between these worlds, but I personally do this less and less as the years go by, and spend more and more time in the terminal. tmux has made this pretty pleasant. I have my editor (vim), mail (mutt), chat (irssi+bitlbee), and a browser for reading documentation (w3m), all at fixed window assignments. Copy and paste between these programs using the keyboard for text selection is nice. Reliable activity notifications for the mail and chat windows are something I can't live without anymore (and something screen lacks).
Same story on Linux. Integrating the tmux or screen clipboards with the X clipboard is DIY.
I get that it's annoying if you're frequently moving data back and forth between these worlds, but I personally do this less and less as the years go by, and spend more and more time in the terminal. tmux has made this pretty pleasant. I have my editor (vim), mail (mutt), chat (irssi+bitlbee), and a browser for reading documentation (w3m), all at fixed window assignments. Copy and paste between these programs using the keyboard for text selection is nice. Reliable activity notifications for the mail and chat windows are something I can't live without anymore (and something screen lacks).
So you avoid X altogether? How would there be updates without X? And if using X, why not use apps that have desktop update functionality (where that is important)?
I'm legitimately curious as I've been experimenting with the same cli apps and found some worth it (vim, weechat) and others a regression.
Is it just for the ability to use these programs on a remote server? Or do they improve workflow even on a local machine?
I'm legitimately curious as I've been experimenting with the same cli apps and found some worth it (vim, weechat) and others a regression.
Is it just for the ability to use these programs on a remote server? Or do they improve workflow even on a local machine?
So you avoid X altogether? How would there be updates without X? And if using X, why not use apps that have desktop update functionality (where that is important)?
Not sure what you're asking here. I use X but switch between a fullscreen terminal running tmux and fullscreen Chrome. With tmux, you can multiplex a bunch of terminal windows, monitoring some of them for activity. For instance, if new mail arrives, mutt will repaint and its window will be flagged as active in the status bar at bottom.
I also use this as an ad-hoc notifications system: for example, kick off a long build, redirecting output to a file, and monitor its tmux window. When the process exits your shell prompt is printed again (activity!) and voila, you get a "build is complete" notification.
Is it just for the ability to use these programs on a remote server? Or do they improve workflow even on a local machine?
YMMV of course, but...
I use both remote and local tmux sessions. Reattaching to remote sessions and picking up where you left off is obviously useful, but it also comes in handy locally if X crashes, or if you need to remote in from a different machine. I build up a fair amount of "working state" inside a tmux session: an editor with tens or hundreds of files open, sql prompts, chat logs, shells with important history, etc. With suspend / resume you can go for months without having to tear down and rebuild that state. If I entrusted all that state to a gui, it certainly wouldn't live as long.
As for workflow, the world of text and text manipulation really has advantages once you get comfortable in it. Random access to programs is O(1) fast: in my setup, "^A 0" for editor, "^A 4" for mail, etc and it's obvious what number to hit for other ones. Compare to Alt-Tab style switching which is more like O(n) as you cycle through the list. I find the fine-grain motor control of mouse-based copy and paste cognitively wasteful and annoying. Keyboard-based selection of text lets you use your favorite editor bindings to jump to word boundaries, end of sentence, end of line etc and is much more pleasant. Searching any terminal output via "/" or "?" is handy.
You get the drift. ;)
Not sure what you're asking here. I use X but switch between a fullscreen terminal running tmux and fullscreen Chrome. With tmux, you can multiplex a bunch of terminal windows, monitoring some of them for activity. For instance, if new mail arrives, mutt will repaint and its window will be flagged as active in the status bar at bottom.
I also use this as an ad-hoc notifications system: for example, kick off a long build, redirecting output to a file, and monitor its tmux window. When the process exits your shell prompt is printed again (activity!) and voila, you get a "build is complete" notification.
Is it just for the ability to use these programs on a remote server? Or do they improve workflow even on a local machine?
YMMV of course, but...
I use both remote and local tmux sessions. Reattaching to remote sessions and picking up where you left off is obviously useful, but it also comes in handy locally if X crashes, or if you need to remote in from a different machine. I build up a fair amount of "working state" inside a tmux session: an editor with tens or hundreds of files open, sql prompts, chat logs, shells with important history, etc. With suspend / resume you can go for months without having to tear down and rebuild that state. If I entrusted all that state to a gui, it certainly wouldn't live as long.
As for workflow, the world of text and text manipulation really has advantages once you get comfortable in it. Random access to programs is O(1) fast: in my setup, "^A 0" for editor, "^A 4" for mail, etc and it's obvious what number to hit for other ones. Compare to Alt-Tab style switching which is more like O(n) as you cycle through the list. I find the fine-grain motor control of mouse-based copy and paste cognitively wasteful and annoying. Keyboard-based selection of text lets you use your favorite editor bindings to jump to word boundaries, end of sentence, end of line etc and is much more pleasant. Searching any terminal output via "/" or "?" is handy.
You get the drift. ;)
I see. I was not aware that tmux has/can be configured to have a status bar at the bottom. That makes activity updates possible.
Thanks also for elaborating about workflow. I use a similar setup with chrome and xterm and a tiling WM. I like the idea of integrating tmux and suspend/resume to build up and return to state.
Thanks also for elaborating about workflow. I use a similar setup with chrome and xterm and a tiling WM. I like the idea of integrating tmux and suspend/resume to build up and return to state.
OSX clipboard integration? Can you elaborate?
screen and tmux have a copy mode (this is "inside" of the terminal emulator, I'm not talking about using your mouse to select text in Terminal.app) that allow you to copy text. I assume he wants copy there to yank the text to the OS X clipboard.
It's possible in tmux, but kind of annoying (the best solution I've found requires another key combo press to push your copy into the system clipboard).
It's possible in tmux, but kind of annoying (the best solution I've found requires another key combo press to push your copy into the system clipboard).
Yes, I'd like to hear more about this too. Does screen integrate with the OS X copy / paste buffer?
You can select stuff with the mouse in the terminal and whatever you select is then available to be pasted with CMD+V.
What the parent refers to is the ability to press C-b to enter the buffer scroll, then select text there and unfortunately -- not -- having that available to OSX's paste buffer, but only internally inside tmux.
This means that if you want to copy that stuff to OSX's paste buffer you have to go through the intermediate step of pasting it inside a new buffer (say, Vim) inside tmux, then select it again with the standard terminal selection feature and only then it will be available to OSX's CMD+V.
hope that clears it up.
What the parent refers to is the ability to press C-b to enter the buffer scroll, then select text there and unfortunately -- not -- having that available to OSX's paste buffer, but only internally inside tmux.
This means that if you want to copy that stuff to OSX's paste buffer you have to go through the intermediate step of pasting it inside a new buffer (say, Vim) inside tmux, then select it again with the standard terminal selection feature and only then it will be available to OSX's CMD+V.
hope that clears it up.
> For one, Screen is everywhere. I can go from system to system and it'll be there.
And that would be why I still use screen, for the most part. Tmux is nice, but it isn't prevalent (yet.)
And that would be why I still use screen, for the most part. Tmux is nice, but it isn't prevalent (yet.)
Exactly. I need something that'll let me move from linux, to AIX, to z/OS, to even RHEL on Z. Screen lets me do that. Tmux doesn't come close.
Learning two products is too hard. This is why I would never use Linux at home since I need to use Windows at work.
> Tmux doesn't work with the Mac's clipboard
I don't use OSX but in linux you press Shift then select with mouse...
I don't use OSX but in linux you press Shift then select with mouse...
Anytime I see "Is X the Y killer" it's no.
Can we please have better link titles?
In this case I think tmux replaced screen easily over a year ago.
http://qa.debian.org/popcon-graph.php?packages=screen+tmux&#...
tmux still has a long hill to climb.
FWIW, my .screenrc is 4 lines. My .tmuxrc is 26 lines, and all it tries to do is get a behavior comprable to screen. Ie, using the same ctrl-a, supporting ctrl-ac without needing to release ctrl before the second character, allowing titles to pass thru tmux to the title bar, etc.
tmux still has a long hill to climb.
FWIW, my .screenrc is 4 lines. My .tmuxrc is 26 lines, and all it tries to do is get a behavior comprable to screen. Ie, using the same ctrl-a, supporting ctrl-ac without needing to release ctrl before the second character, allowing titles to pass thru tmux to the title bar, etc.
> my .screenrc is 4 lines. My .tmuxrc is 26 lines
> all it tries to do is get a behavior comprable to screen
I've never used tmux and I find your post to be biased towards screen. tmux isn't being touted as a 'drop-in replacement' for screen, but that seems to be how you are evaluating it.
The answer to you is no, I think it is. It's a question at least, it's not it it _is_ a killer. That I think is misleading. At least with this title you still have to come to your own conclusion.
But yes, better article titles.
But yes, better article titles.
I agree that the answer to that question is almost always "no". But I think this case is a rare exception where the answer is "yes", or at least "probably".
--- a GNU screen user who intends to switch over to tmux at some point.
--- a GNU screen user who intends to switch over to tmux at some point.
The biggest advantage of tmux is if you want to go multi-user. It can be done with screen, but it involves some pretty heinous setuid hacks.
tmux doesn't invent its own permissions system; it just communicates over a socket. Anyone with permissions to read the socket can join. Anyone with permissions to write to the socket can interact. It's stupid easy.
tmux doesn't invent its own permissions system; it just communicates over a socket. Anyone with permissions to read the socket can join. Anyone with permissions to write to the socket can interact. It's stupid easy.
No, Byobu is. https://launchpad.net/byobu
A (GNU Screen) Killer Feature: Provide an easy way to 'screen' an existing running process.
it's doable, but not terribly easy, at least as of last report. see retty http://pasky.or.cz/dev/retty/ or screenify http://www.zsh.org/mla/users/2008/msg00421.html.
> A feature that GNU Screen users have wanted for a long time is vertical splitting
^A-| works just fine here. IIRC, it's been working for quite some time.
^A-| works just fine here. IIRC, it's been working for quite some time.
This was added to the codebase a long time ago, the article is incorrect.
Actually, the article is correct. However almost all distributions also add the patch to the code before they compile it.
So vertical splitting, while not in the main tree yet, is pretty much available if you've installed GNU screen on any recent Linux distribution.
So vertical splitting, while not in the main tree yet, is pretty much available if you've installed GNU screen on any recent Linux distribution.
IIRC it's in the codebase but not in a stable release yet. It also carries a performance penalty in Screen but not in tmux.
tmux is pretty amazing, I use it almost exclusively over screen or byobu.
The only thing that beats it is iTerm2 on OS X in terms of ease of splitting, tabs, and ability to scroll each pane using mouse scroll wheel, etc.
The only thing that beats it is iTerm2 on OS X in terms of ease of splitting, tabs, and ability to scroll each pane using mouse scroll wheel, etc.
Soon you will be able to get both: http://code.google.com/p/iterm2/wiki/TmuxIntegration. This means that you will get iterm's native window splitting if you use tmux inside iterm or plain tmux if you are using another terminal
I welcome every effort to supplement the crummy OSX window manager, but the iTerm tiling system is sadly a false start.
They have the tab/split metaphor backwards. Real tiling WMs (such as ion3) put tabs on the individual split panes instead of having one global tab bar at the top - and for good reasons.
As it stands you can not, for example, drag an iTerm tile to its own window or group multiple sessions in one tile. This may seem minor to the casual user but is a showstopper for those of us who would benefit from the tiling the most.
They have the tab/split metaphor backwards. Real tiling WMs (such as ion3) put tabs on the individual split panes instead of having one global tab bar at the top - and for good reasons.
As it stands you can not, for example, drag an iTerm tile to its own window or group multiple sessions in one tile. This may seem minor to the casual user but is a showstopper for those of us who would benefit from the tiling the most.
O.o that's nice. Now THAT would be a reason I would consider to switch to tmux.
Will there ever be a windows equivalent of screen? At the moment I can emulate its tabbing functionality using Console2, but that is still a long way short of the power of screen.
You can do a minimal install of cygwin including screen, and then run it in console2. It is workgin quite nicely for me.
There's also mintty which I think it's putty without the network and serial code.
I use it to copy/paste with the mouse. You can also set "UTF-8" in the options if you need.
I use it to copy/paste with the mouse. You can also set "UTF-8" in the options if you need.
It took me about 15 seconds, a window resize, a horizontal split, a vertical one and a couple rotate windows to crash it.
* I found a bug! What do I do?
Please send bug reports by email to [email protected] or [email protected]. Please include as much of the following information as possible:
- the version of tmux you are running;
- the operating system you are using and its version;
- the terminal emulator you are using and the TERM setting when tmux was started;
- a description of the problem;
- if the problem is repeatable, the steps to repeat the problem;
- for screen corruption issues, a screenshot and the output of "infocmp $TERM" from outside tmux are often very useful.
http://tmux.svn.sourceforge.net/viewvc/tmux/trunk/FAQ
Please send bug reports by email to [email protected] or [email protected]. Please include as much of the following information as possible:
- the version of tmux you are running;
- the operating system you are using and its version;
- the terminal emulator you are using and the TERM setting when tmux was started;
- a description of the problem;
- if the problem is repeatable, the steps to repeat the problem;
- for screen corruption issues, a screenshot and the output of "infocmp $TERM" from outside tmux are often very useful.
http://tmux.svn.sourceforge.net/viewvc/tmux/trunk/FAQ
Everytime I see "GNU Screen killer", I think it has the same chance of surviving as "iPhone killers" or "iPod killers". It might be better, but being touted as something which will "kill" something established, it's almost always doomed to "fail", that term (also) being warranted or not.
I still see little reason to part from screen after all these years, and despite various offers of "better" options troughout the years. On the other hand, I did ditch my iPhone for an Android-phone. Although it was an Android-phone not labeled as an "iPhone killer".
I still see little reason to part from screen after all these years, and despite various offers of "better" options troughout the years. On the other hand, I did ditch my iPhone for an Android-phone. Although it was an Android-phone not labeled as an "iPhone killer".
The "X killer" thing is media reaction though, especially of open source projects, rather than necessarily a goal of the project.
I doubt the people working on tmux have "killing screen" as one of their priorities (or even one of their cares). They wanted something that worked differently, and decided that going from scratch rather than using the screen codebase (either because they didn't like the code, or for licensing reasons, or they though they' be touching so much of the existing code that it would just be cleaner to start from scratch, or some combination of the above) was preferable.
It'll take a lot to replace screen, but given it offers features in its stable branch that screen doesn't have or only has in beta (the horizontal splitting talked about since ~2009 has been in beta since then) and is available standard in OpenBSD and probably optionally in every recent Liunx distribution, I can see tmux taking over some of screen's mindshare. I'm told tmux has noticeably lower memory requirements too, though will only make a difference to users who are working with very small environments like cheap VPSs on over-sold hosts or embedded environments, as screen isn't that much of a monster to start with.
FYI: I'll be sticking with screen (via byobu where available) as I know it, it works and is stable (I've not had it hang/error/crash any time in the last <more-than-a-few> years) and it is very widely available.
I doubt the people working on tmux have "killing screen" as one of their priorities (or even one of their cares). They wanted something that worked differently, and decided that going from scratch rather than using the screen codebase (either because they didn't like the code, or for licensing reasons, or they though they' be touching so much of the existing code that it would just be cleaner to start from scratch, or some combination of the above) was preferable.
It'll take a lot to replace screen, but given it offers features in its stable branch that screen doesn't have or only has in beta (the horizontal splitting talked about since ~2009 has been in beta since then) and is available standard in OpenBSD and probably optionally in every recent Liunx distribution, I can see tmux taking over some of screen's mindshare. I'm told tmux has noticeably lower memory requirements too, though will only make a difference to users who are working with very small environments like cheap VPSs on over-sold hosts or embedded environments, as screen isn't that much of a monster to start with.
FYI: I'll be sticking with screen (via byobu where available) as I know it, it works and is stable (I've not had it hang/error/crash any time in the last <more-than-a-few> years) and it is very widely available.
So a single blog post touting something as an 'X killer' is enough to make that product bad?
I'm not saying the product is bad, only that if it gets recognized or talked about as an "X killer" it will almost always fail deliver the specified "killing", and hence it's a "failure" in that regard. You also risk creating higher expectations than you can reasonably deliver.
So basically, announcing your product as or having people talk about your product as a killer of any sort, is mostly a bad thing, be it a good product or not. You want people to say "it's very good", not "it's an X-killer".
Or at least that is my experience and opinion on "X killer" as a branding-strategy.
So basically, announcing your product as or having people talk about your product as a killer of any sort, is mostly a bad thing, be it a good product or not. You want people to say "it's very good", not "it's an X-killer".
Or at least that is my experience and opinion on "X killer" as a branding-strategy.
Still, you have to admit, the iPhone is working pretty well as a Nokia killer ;)
His point still holds -- the iPhone was never touted as a "Nokia killer" -- it was touted as a "magical" new experience. And the popular press was quite dismissive at first of Apple's ability to compete in the mobile market.
I found tmux to be more intuitive and it actually works out of the box in a pleasant manor on both openbsd and debian without acres of configuration. That was enough for me to switch from screen.
Front page? really? Do people even try to come up with article subjects lately?
I just made that switch myself recently, and found getting things set up how I liked them with screen extremely frustrating. With tmux, I was all set within an hour. I tried screen for a couple of weeks, then tried tmux, and was hooked almost immediately.
I found scripting tmux to be much simpler, and setting up things like having the bottom bar notify me if there was new text in a window was so much easier in tmux.
Install on OS X was easy: brew install tmux
As a side benefit, having nested screen sessions (or nested tmux sessions) is kind of annoying. My solution is to use tmux on my laptop, and run screen on all of my servers. That way there's no nesting. I don't spend much time mucking around on the server, but so far I've found this quite satisfactory.