A little of A, a little of B. A new release is a bit newsworthy, since they don't happen super often. But at the same time, "never gets updated" is clearly not true.
The initial release of tmux was in 2007. The initial release of screen was in 1987. I assume they don't update as frequently because it's relatively stable.
I use screen because tmux forces me to explicitly define quick bindings for each binding where I don't want to lift my finger before pressing the letter. So, where I can write `C-a c` in screen without taking my finger off the keyboard, I have to explicitly add `bind-key C-c new-window` in tmux.conf for this. Otherwise it's not as ergonomic as in screen, and now I have to do configure this for each key I use, which granted isn't that many, but still it's a nuisance without a good justification. Tmux is fine for me if I ignore that. But some people miss certain screen features in tmux, so it's fair to mention that as well.
The only real downsites are if you use screen/minicom/etc inside tmux you tend to mash Ctrl-a quite a lot, but if anything that's easier than keeping track of which key goes with which level?
The above is how most people first configure tmux, since C-b is just awkward. `bind-key C-a send-prefix` is optional of course, but is used to forward C-a to the active window (beginning-of-line in shell and emacs). How would you do that in screen?
The default for `previous-window` is `prefix-p`. Run `tmux list-keys` to see all active bindings.
The churn is fairly low in screen and there's nothing wrong with that, just like xterm doesn't see huge changes but periodic releases with whatever changed.
* 4.2.0: Apr 2014
* 4.0.3: Aug 2008
* 4.0.2: Jan 2004
* 3.9.15: Mar 2003
* 3.9.11: Feb 2002
* 3.9.10: Sep 2001
> I've heard many people say that they use tmux because screen never gets updated.
Screen releases did slow down in the early 2000s. It was probably considered feature-complete, so I can understand. I hope the existence of tmux will push both projects to improve themselves, preferably without developing featuritis.
I stopped because those are the only ones on the GNU Savanna news section, and I didn't want to get it wrong. It was an unfortunate chance, seeing the rest of that schedule.
Yep I've been using screen for many many years. It's one of those tools that entirely changed how I work. Still haven't had sufficient motivation to switch to tmux, since screen just works and I know all of its key bindings very well.
FWIW, I've found that CTLR-j is the best choice for the primary escape sequence. As an emacs user CTRL-a was unacceptable as was pretty much CTRL-<everything else>.
I use Ctrl-@, also known as Ctrl-Space or the null character.
For another screen session that I run within a terminal in my main session (don't ask), I use Ctrl-].
(There's at least one keyboard/terminal setup that doesn't let me type the null character. When I use that, I temporarily change the escape character.)
I use backquote (i.e., I have "escape ``" in my screenrc). For some reason this appeals to me more than a control sequence, which I blame on Emacs. For a long time I used Emacs under screen almost exclusively, and I was desperate for a screen command sequence that didn't conflict with Emacs---which ruled out almost all the control key combos. Reaching for the top corner of the keyboard to begin an escape sequence feels pretty natural to me because of my history with Emacs on terminals that don't support the Meta modifier, and backquote doesn't conflict with key bindings for the editing modes I typically use in Emacs. Backquote is used infrequently enough in other contexts for it to interrupt my typing, with the exception command interpolation. (I wish I could say I came up with it on my own, but it was actually a friend of mine who clued me in.)
I love backquote for the escape char. It's better than ctrl-anything because it's one less keypress and the location is one of the easiest to hit blindly from a UX perspective (even ESC is more of a reach).
I'm using ctrl-z. When in screen, I don't have to background stuff as often (as I typically just want to leave it running in the foreground and open a new buffer instead). But when I do want to send something to the background ctrl-z z just works.
Is this a known and reported bug? Can I encourage you to report it on the mailing list? The current maintainers are receptive to feedback and relatively quick with patches.
> Also, the definition of one license is "more free" than the other is completely subjective and is wholly dependent on the perspective of the licensee.
That is just false. BSD has fewer restrictions. GPL has more restrictions. No subjective interpretation needed.
>> "The BSD license allows the software to be made non-free."
Let's clarify: Technically, it allows the copy (distributed with the proprietary software) to become non-free, though the original and any other copies of the original are still free. Technically, BSD is more "free" than GPL to the first copier, even if not so to everyone else who obtains it from the first copier. The "subjective interpretation" then is from the point of view of the next guy in line.
> The BSD license allows the software to be made non-free.
No, it doesn't.
It allows non-free software being made incorporating the free software, but the free software remains free. It also allows free software with different terms than the original to be made also incorporating the free software which remains available under the original terms.
In case of open source licenses, the opposite of "restrictive" is "permissive", not "more free".
Yes, the BSD license has fewer restrictions than the GPL. That makes the BSD license a more permissive license, not necessarily a more free license.
The BSD license allows licensed code to be used in proprietary software but the GPL requires any derivative work to be licensed under the GPL thereby guaranteeing that the licensed code is always used in free software. Therefore, one can argue that the GPL license is "more free".
Free, that being freedom, that being liberty, is not based on the existence of restrictions. The place where everyone can enjoy freedom the most is not the jungle, nor is it the lawless land.
Freedom from oppression means that the oppressors are restricted, and you can't install your spyware and call it DRM that can't be legally removed. Freedom from coercion means that you can't coerce someone, and security researchers can live without fear of EUAL's or copyright licenses that forbid the disassembling of software. No 7-year-old girl will be sued because of art which is based on what I have made, and no one will be sent to prison because they dared to share a copy to a friend.
"freedom is not as Sir Robert Filmer defines it: 'A liberty for everyone to do what he likes, to live as he pleases, and not to be tied by any laws'. Freedom is constrained by laws in both the state of nature and political society." - John Locke (1632–1704)
I'm actually saddened that things like tmux and zsh are under weak licenses. The GPL is a license designed to maintain users freedom, and the authors of many programs seem to not care enough about that anymore. It's almost as though they don't realise what an innovative license the GPL was and still is.
You mean write proprietary software? I refuse to do that.
To be fair, I have contributed code to Apache licensed projects (and in fact I maintain one). It still annoys me that it's not GPL licensed (the annoyance doesn't go the other way around for me, I am not annoyed when a project is GPL licensed).
I ssh into that server from an osx laptop and attach to the tmux session. After a ton of configuration mouse actions mostly work (copy/paste is always wonky).
I also ssh into that server from an Ubuntu laptop. The same configuration I needed to get mouse working for osx is no longer applicable.
I've never even thought of writing a screenrc and it's always worked great.
Why iTerm2? OS X Terminal.app supports mouse events just fine on OS X 10.11, and it even has a key shortcut to toggle mouse support on/off for those times when you want to select text instead of sending mouse events.
I think mouse support in Tmux is significantly better; it is hidden behind config flags but tmux supports window and screen switching, buffer scrolling (mouse wheel support), copy-on-select, plus you can bind mouse keys as part of functions.
Version 2.1 of tmux combined all those config flags to a simple :mouse=on, so you don't have to go through one by one to enable all the mouse features.
I've tried to switch to tmux a few times over the years, but the command line options and keybindings never stick in my brain. My fingers keep wanting to use the screen options. So, I always go back. I probably should just figure out how to make screen do what I want (scrolling back in history is probably the biggest one, and I know I had figured it out in the past...but my current systems don't have it working, I don't think, or I don't remember the incantation to do it). I wish screen worked more like a normal terminal session, is what I'm trying to say, and tmux seems to be closer to that ideal without configuration or learning new ways to do things. But, my muscle memory wants screen.
Sounds like you don't use many screen keybindings either? Likely just remapping the default key binding to match screen's in your .tmux.conf gets you 90% of the way there:
unbind C-b
set -g prefix C-a
bind C-a send-prefix
fwiw, the shortcut to enter copy mode in tmux and screen is the same C-a [
I'd end up trying to use the wrong bindings on systems that don't have the configuration yet. I've just got too many boxes/VMs (and have too many individual users on each) and haven't gone to the trouble to setup a solution for rc files in a long time (since before my current batch of servers was deployed). Solving that problem is probably a productive use of my time.
I solved the same situation by making a git repo of my rc files.
It's nice.
One thing to keep in mind is to have it look for local files/scripts to source too. That way you can keep per-system tweaks out of the global runtime configuration.
Also, passwords. Don't put passwords, or anything you don't want leaked in the rc repo. You could have it private, but that's not fool proof.
I was in the same position a while back. However, thanks to this article[1] and learning a little bit about tmux behavior, I'm happily tmuxified. I recommend it.
> Screen contents persisted through full-screen programs: in Screen, you lose your terminal's previous contents after leaving a full-screen program like an editor. Tmux doesn't have this problem.
Does this mean I can preserve scrollback among each terminal? If so, I'll switch tomorrow morning. That's screen's biggest drawback.
Oh, that's right. I'm so used to the terminal emulator's scrollback buffer keys I forgot that you just have to escape to get to this behavior. I suppose there's no way to have this work the way I want until/unless the terminal mode natively supported multiple sessions/screens.
If you want something more modular, you might want to look at dvtwm and abduco. I'm not using them, but others do successfully and it's worth mentioning in this thread.
It seems like a poor choice not to have the new version include compatibility code allowing it to attach to sessions created under the previous version.
This isn't the first time this has happened, either - last time a small patch was bandied around (I think I saw it on the Debian bug tracker) that fixed the problem.
I use screen on old servers and have tried to craft a tmux config that works several times, and failed.
Ubuntu repos include a nice package called byobu[1] that is a layer on top of tmux (or screen) that mostly makes copy/paste work like screen, while keeping the working scrollback from tmux instead of making it compatible with the usually-broken (in my experience) screen scrollback.
Byobu works well for me, so I'm using tmux on most of my servers now but it feels almost like screen.
The number one request I get from folks around screen is how to have more than 40 screens in a single screen session. It is a hard coded limit. (MAXWIN 40) Many people recompile it to have more, but I don't want to maintain yet another internal build of a package.
Screen is still awesome and I have taught many folks to use it.
Current default is 100.
You can also use maxwin command (for example 'maxwin 200', up to 2048) in your screenrc file to define other value, no need to recompile.
However do note that you can't change it in already started screen.
65 comments
[ 2.7 ms ] story [ 127 ms ] threadscreen-4.0.3 2008-08-07
screen-4.2.0 2014-04-27
(I mostly hear about this stuff because I still used screen and tons of people are like "why don't you tmux")
I had to still explicitly add `bind-key C-a previous-window` to emulate screen's `C-a a` to switch between last windows.
The default for `previous-window` is `prefix-p`. Run `tmux list-keys` to see all active bindings.
Timed releases of screen might be a good idea.
Screen releases did slow down in the early 2000s. It was probably considered feature-complete, so I can understand. I hope the existence of tmux will push both projects to improve themselves, preferably without developing featuritis.
I share your feelings, I hope it pushes both too.
FWIW, I've found that CTLR-j is the best choice for the primary escape sequence. As an emacs user CTRL-a was unacceptable as was pretty much CTRL-<everything else>.
For another screen session that I run within a terminal in my main session (don't ask), I use Ctrl-].
(There's at least one keyboard/terminal setup that doesn't let me type the null character. When I use that, I temporarily change the escape character.)
Edit: I guess that was obvious considering this gnu screen announcement contains as much (or more) discussion about tmux as screen.
Also, the definition of one license is "more free" than the other is completely subjective and is wholly dependent on the perspective of the licensee.
That is just false. BSD has fewer restrictions. GPL has more restrictions. No subjective interpretation needed.
Not everyone agrees. Hence, subjective interpretation. Saying otherwise is just trolling.
Let's clarify: Technically, it allows the copy (distributed with the proprietary software) to become non-free, though the original and any other copies of the original are still free. Technically, BSD is more "free" than GPL to the first copier, even if not so to everyone else who obtains it from the first copier. The "subjective interpretation" then is from the point of view of the next guy in line.
No, it doesn't.
It allows non-free software being made incorporating the free software, but the free software remains free. It also allows free software with different terms than the original to be made also incorporating the free software which remains available under the original terms.
Yes, the BSD license has fewer restrictions than the GPL. That makes the BSD license a more permissive license, not necessarily a more free license.
The BSD license allows licensed code to be used in proprietary software but the GPL requires any derivative work to be licensed under the GPL thereby guaranteeing that the licensed code is always used in free software. Therefore, one can argue that the GPL license is "more free".
Freedom from oppression means that the oppressors are restricted, and you can't install your spyware and call it DRM that can't be legally removed. Freedom from coercion means that you can't coerce someone, and security researchers can live without fear of EUAL's or copyright licenses that forbid the disassembling of software. No 7-year-old girl will be sued because of art which is based on what I have made, and no one will be sent to prison because they dared to share a copy to a friend.
"freedom is not as Sir Robert Filmer defines it: 'A liberty for everyone to do what he likes, to live as he pleases, and not to be tied by any laws'. Freedom is constrained by laws in both the state of nature and political society." - John Locke (1632–1704)
Without it you do not have the mental yardstick to evaluate things properly.
To be fair, I have contributed code to Apache licensed projects (and in fact I maintain one). It still annoys me that it's not GPL licensed (the annoyance doesn't go the other way around for me, I am not annoyed when a project is GPL licensed).
Right now the world seem poised to enter another major war.
This i attribute to the generation of politicians holding the reins has not experienced full scale war up front and personally.
Similarly, one has to experience the depths of proprietary lock-in to be really able to grasp what is being attempted with the GPL.
Ubuntu 14.04 server is running tmux.
I ssh into that server from an osx laptop and attach to the tmux session. After a ton of configuration mouse actions mostly work (copy/paste is always wonky).
I also ssh into that server from an Ubuntu laptop. The same configuration I needed to get mouse working for osx is no longer applicable.
I've never even thought of writing a screenrc and it's always worked great.
It's nice.
One thing to keep in mind is to have it look for local files/scripts to source too. That way you can keep per-system tweaks out of the global runtime configuration.
Also, passwords. Don't put passwords, or anything you don't want leaked in the rc repo. You could have it private, but that's not fool proof.
[1]: https://mutelight.org/practical-tmux
Does this mean I can preserve scrollback among each terminal? If so, I'll switch tomorrow morning. That's screen's biggest drawback.
What they seem to describe is altscreen behaviour which can be disabled with "altscreen off" in .screenrc .
This isn't the first time this has happened, either - last time a small patch was bandied around (I think I saw it on the Debian bug tracker) that fixed the problem.
Ubuntu repos include a nice package called byobu[1] that is a layer on top of tmux (or screen) that mostly makes copy/paste work like screen, while keeping the working scrollback from tmux instead of making it compatible with the usually-broken (in my experience) screen scrollback.
Byobu works well for me, so I'm using tmux on most of my servers now but it feels almost like screen.
[1] http://byobu.co/
Screen is still awesome and I have taught many folks to use it.