All about GNU Screen | Hacker News Reader

All about GNU Screen

lugatgt.org

72 pointsmace26 comments

I love screen.

I use it on a daily basis for ~10 years.

What still bothers me mightily is that, up to this day, nobody has bothered to get the history scrolling right (neither in tmux, btw). You still have to press an awkward key combination to switch to "copy mode", the normal mechanisms (PGUP, mousewheel, scrollbar) only result in garbage.

I've tried various partial fixes ("altscreen off") but none works properly across sessions or with multiple windows. Years back I even tried to patch screen myself but had to surrender over the (for me) crufty code-base.

And that despite the solution being fairly obvious: Just redraw the entire window while scrolling, just like irssi and plenty other console apps do it. And just like screen itself does it in copy-mode.

I wish someone would finally take on this issue...

You can scroll through the history of your terminal, but not of individual screens by adding this to your .screenrc file.

termcapinfo xterm|xterm-color ti@:te@

Not 100% there, but does well for me.

Yes I have that, it's the partial solution I mentioned.

It unfortunately doesn't preserve the history during detach/reattach. And the history gets scrambled when you switch between windows.

tmux is a great BSD-licensed alternative:

http://tmux.sourceforge.net/

I've tried both, and the licensing issue aside, I've found I prefer tmux.

Anyway, not wanting to turn this into a gnu vs. bsd, tmux vs. screen argument, but I didn't eve know tmux existed until someone pointed me to it, so I'm just passing on the knowledge.

Can you elaborate on why you prefer tmux? Myself, I use byobu, a set of user-friendly wrapper scripts around screen.

One of the big things is that it preserves split screen arrangements upon detachment. I SSH into a server and basically use Screen/tmux as my IDE, and losing my split screen setup when I detach is very annoying.

Personally I appreciate the client-server design and the memory savings it lends when connecting multiple terminals to the same tmux session:

http://www.linuxized.com/2010/05/switching-from-gnu-screen-t...

Plus the more liberal BSD license but that's more of an ideological issue.

tmux has been recommended frequently lately, but I have not tried it. This seems to be decent summary of the differences between it and screen:

http://unix.stackexchange.com/questions/549/tmux-vs-gnu-scre...

off hand from just playing with tmux for the past 20 minutes, it looks like tmux better abstracts its commands from how it internally tracks the windows and sessions than does screen.

In particular, when i've played with screen, i found that i was frequently stymied by the broken abstraction of the way screen stored its state vs what I wanted to do.

byobu sadly doesn't work on macbooks, but it looks cool!

to further clarify: when choosing a session (and thus a collection of windows), in screen the process id info etc is exposed at the user level, which perhaps is useful to someone, but not for how use terminal and such. Thus because these things are not as directly exposed via the interaction model that tmux does, doing stuff becomes simpler and semantically clearer

I did a short (free) screencast about tmux if you want a more visual run-through: http://peterc.org/blog/2010/216-tmux.html

tmux was able to split windows vertically before screen was able to mostly due to politics, AFAIK.

thanks! this looks very interesting and worth looking into

I'm a fan of dtach + dvtm. tmux looks pretty great too.

A nice function (not mentioned in this presentation) is the ability to send commands (-X) to a specific window in a screen session. This allows you to completely control GNU Screen the shell or another programming environment while benefiting from the persistent or logging of a session.

    screen -d -m -S mysession
    screen -S mysession -X screen -a -tjob1 'top'

Using -X you can call the commands available within GNU Screen to control the session or the windows.

The Gnu Screen command 'stuff' writes directly to the STDIN on the window. This is how the REPL integration setups with screen/vim that appear on HN from time to time work. e.g.

  screen -a window1 -X stuff 'import sys'

would send 'import sys' to whatever app was reading STDIN on window1.

If you haven't heard of it, Xpra is sort of like screen for X, in that it lets you run persistent X sessions (rootlessly, unlike VNC). Shifter (http://shifter.devloop.org.uk/) packages screen and Xpra together with a nice user-friendly interface for Windows, OpenSolaris, BSD, Mac OS, Linux, etc., and it includes a patch for Xpra so that it works for Windows!

I strongly recommend having a look at the Gnu Screen customization in Ubuntu Server.

http://blog.dustinkirkland.com/2008/12/ubuntu-server-include...

That project has matured a lot, it's now called byobu. It's friggin' awesome. https://launchpad.net/byobu

I was just thinking today how wonderful it would be if my web browser let me navigate tabs with the same key bindings as screen.

If I had a nickel for every time I've done "select all" when I wanted to quickly switch back to the last active tab.

My biggest impediment to using screen is emacs key binding conflicts. I never took the time to determine an acceptable solution. Can an emacs guru share their solution...?

I use ctrl-_ (aka ctrl-7) for screen/tmux commands. I don't its functionality in Vim. Not sure if it helps for Emacs.

Change the C-a binding to C-z.

I use backtick as the screen command, which is fine unless you write a lot of bash scripts.

$ screen -e '``'

I'll give that a try ... I had to do screen -e '\`\`'

So many people hit this, and then use screen less, and everyone adopts a different alternative.

I suspect a screen fork which simply adopts new standard emacs/bash-compatible defaults could eventually overtake the original in usage.

Reply on news.ycombinator.com