GNU Screen v.4.4.0(lists.gnu.org)
lists.gnu.org
GNU Screen v.4.4.0
http://lists.gnu.org/archive/html/screen-users/2016-06/msg00014.html
65 comments
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.
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.
[1]: https://mutelight.org/practical-tmux
[1]: https://mutelight.org/practical-tmux
> 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.
Does this mean I can preserve scrollback among each terminal? If so, I'll switch tomorrow morning. That's screen's biggest drawback.
Um, each screen window remembers it's scrollback properly?
C-a [ - to enter 'scrollback' mode, and you can use arrows there.
What they seem to describe is altscreen behaviour which can be disabled with "altscreen off" in .screenrc .
What they seem to describe is altscreen behaviour which can be disabled with "altscreen off" in .screenrc .
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.
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
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.
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.
Yep, I even had a makefile that set the right bindings for new boxes. I ended up just learning the ctrl-B binding instead.
Ctrl-a ESC allows you to scroll up in your history.
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.
[1] http://byobu.co/
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/
I was reluctant to switch to tmux, but screen's never fixing its UTF8 display in hardstatus makes me sad.
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.
On the plus side tmux is a BSD style license and not GPL. So it is a more free (as in libre) software.
Edit: I guess that was obvious considering this gnu screen announcement contains as much (or more) discussion about tmux as screen.
Edit: I guess that was obvious considering this gnu screen announcement contains as much (or more) discussion about tmux as screen.
Unless your usage includes redistribution, GPL/BSD licensing differences have little effect on end-users.
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.
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.
> 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.
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. The GPL doesn't. To me, this means the GPL wins on freedom.
Not everyone agrees. Hence, subjective interpretation. Saying otherwise is just trolling.
Not everyone agrees. Hence, subjective interpretation. Saying otherwise is just trolling.
>> "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.
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.
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".
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)
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.
As with many tings i think you need to experience the bad side directly before you come to appreciate the good side.
Without it you do not have the mental yardstick to evaluate things properly.
Without it you do not have the mental yardstick to evaluate things properly.
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).
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 was pointing to a more general pattern.
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.
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.
One advantage of screen over tmux I found is that it has much better mouse support.
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.
The other advantage is `nethack` mode! `echo 'nethack on' >> ~/.screenrc`
Be careful! New screen tonight.Yup. I can never get tmux configured in a way that lets me use the mouse through a remote session from osx at work and Ubuntu at home.
I use this every single day and it works perfectly. Are you using the default OSX terminal? If so you should try iTerm2 instead.
I love iterm2! Here's my setup:
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.
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.
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.
For some context, the last few releases of screen were:
* 4.3.0: June 2015
* 4.2.1: April 2014
I can't tell whether you are trying to claim that it never gets updated or show that that isn't true.
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.
Of course it was true.
screen-4.0.3 2008-08-07
screen-4.2.0 2014-04-27
screen-4.0.3 2008-08-07
screen-4.2.0 2014-04-27
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.
While this is true, screen has not been getting some features that people see as important, like vertical splits.
(I mostly hear about this stuff because I still used screen and tons of people are like "why don't you tmux")
(I mostly hear about this stuff because I still used screen and tons of people are like "why don't you tmux")
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.
Why don't you just change the prefix key instead?
unbind C-b
set -g prefix C-a
bind-key C-a send-prefix
Nice, that seems to work. Is there a downside to using this?
I had to still explicitly add `bind-key C-a previous-window` to emulate screen's `C-a a` to switch between last windows.
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 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 default for `previous-window` is `prefix-p`. Run `tmux list-keys` to see all active bindings.
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?
screen supports vertical splits for me, on Debian 8
Vertical splits are present from 4.2.0 up.
Isn't a vertical split `Ctrl A, |`?
To reply to you and my other sibling, last I checked, some distros added this, but it's not upstream.
Why did you stop?
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.
* 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
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.
I share your feelings, I hope it pushes both too.
I share your feelings, I hope it pushes both too.
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.
Timed releases of screen might be a good idea.
Timed releases of screen might be a good idea.
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.
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.
This limit must be due to the older versions we have in CentOS 6. screen-4.0.3-19.el6.x86_64
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.
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.
a happy screen user! it's a true game changer!
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>.
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>.
actually i discovered it like a month ago
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.)
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.
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.
I never really used screen, because all I really want is dtach.
[deleted]