You might want to consider tmux (http://tmux.sourceforge.net/) as an alternative. Its cleaner (and, incidentally, BSD-licensed) codebase means that it's getting features that have been gathering dust on screen's to-do list for ages. Most notably, its dwm/XMonad-style layouts (http://tmux.sourceforge.net/tmux6.png) are really nice. AFAICT, screen doesn't even officially have vertically split windows yet, it's still an unofficial patch.
Either way, if you use Unix, learn to use screen or tmux. They're tremendouslyuseful. (Also: Noisy wireless connections are the new flaky dialup, when it comes to resuming shell sessions.)
I rephrased my comment - I think it's the cleaner codebase that makes the big difference. Its BSD license has some perks, though - for one thing, it's part of the OpenBSD base system now, which means security auditing and excellent maintainers. That will probably also lead to more features in the long run.
I was able to make tmux hang in a matter of a few minutes of playing with it (and not even trying hard). It's definitely got promise, but it also still has a way to go.
Started tmux, split the window a few times, ^B <space> a few times, and it hung. I've submitted a sample to the developer. (It's getting stuck somewhere around screen_write_copy.)
Grab a process that you forgot to start inside neercs
Great screensaver
Real time thumbnails of your shells
Special effects when closing a window
Various window layouts...
It also gives OSX RS-232 terminal emulation capability. As far as I know OSX ships with no other such program. Once you get your USB dongle's driver situation under control you just:
screen devicebaud
ex:
screen /dev/tty.usbserial-FTDPZOEJ 115200
Very useful for embedded system hackers and others who still need to speak RS-232.
I have not used a single other serial console since I accidentally discovered this feature in screen a few years ago. Hyperterminal, minicom, gtkterm, et. al. were the bane of my existence.
I often use idiosyncratic screen setups with very specifically-purposed windows. I support this behavior with a special config file that launches screen with certain windows pre-loaded for certain uses:
I use stuff because it's the most straightforward way to send commands with carriage returns (015 in octal) to a window.
I make this even more effortless by using a special alias in my .bashrc:
alias scd='screen -c /home/mcantor/.screenrc-dev'
I also use a few other aliases to support common uses:
alias scr='screen -rd'
alias scx='screen -x'
alias lsc='screen -list'
Also, don't forget the very useful -S switch:
screen -S someproject
Or, you can use Ctrl-a :sessionname, if you're already within a session, to rename it. That way, screen -list and screen -r can use your sessionnames, and you don't have to parse or remember the process ID's.
There is no reason why you shouldn't use screen when ssh'ing in and working on remote machines, it will save you tons of time in case the connection goes down, plus allows your to keep a persistent working environment on remote boxes.
ssh -t user@host screen -rx
That will drop you immediately to a running screen on connect
I hope you mean on the server. IIRC, some things like GNOME will source .profile or .bash_profile so that you can have globally customized $PATH,etc variables.
I use screen every day for administering multiple remote servers. I don't know how I functioned before I used screen. One of the coolest things are "backtick" commands you can put in the caption string. Here is a pastie of my screenrc and one of the backtick files which displays the free RAM of the system in the caption line, updating every 30 seconds (ymmv on the free RAM command depending on how your distro's `free` command displays its output)
The difficulty of scrolling back in the buffer (C-a ESC PgUp is a longer and more tedious key sequence than Shift+PgUp), and lack of full terminal support (e.g. man, less, etc. don't restore screen contents on exit) mean I strictly only use screen on ssh connections.
Perhaps the terminal support issue could be worked out with better termcap etc. settings, but I haven't found the answers. I asked questions here:
> (C-a ESC PgUp is a longer and more tedious key sequence than Shift+PgUp)
Try entering Copy Mode ('C-a ['). Once in Copy Mode you can page up and down without any modifiers. Just hit ']' to exit Copy Mode. You can also use the up and down arrows in Copy Mode. It's mostly meant for selecting regions of text to yank, but I find it's the easiest way to access the scrollback buffer.
C-a ESC is copy mode, as far as I am aware. At least that's what it says down the bottom of the screen when I do it.
To be clear, C-a ESC puts me in a mode where I can then freely page through the scrollback buffer with PgUp and PgDn, but the problem is that's 4 key presses required for something that only needs 2 in a normal terminal, and Ctrl (with A), Esc, and PgUp are about as far apart as you can get on a keyboard, which doesn't make for efficiency.
Well, I always just used C-a [ to get into copy mode. Another thing to consider is that once you are in copy mode you don't have to hit or continue to hold down the shift key along with PgUp/PgDn.
I personally don't find that to be an annoyance, though. Especially not when stacked up against all of the other benefits you get from using screen.
I understand. The primary benefits of screen to me is disconnect / reconnect, and as such it's useful for servers, but local terminals, not so much.
The other advantage of "rich" support is mousewheel combined with selection: with Cygwin rxvt, I can scroll up, begin a selection with the mouse, and scroll down with the mouse wheel and thereby copy multiple pages of scrollback buffer into the Windows clipboard, ready for e.g. paste in to blog article.
The advantage of keyboard-free casual scrollback when I'm writing such articles, checking what I did earlier, is something you learn to take for granted, and is quite obviously missing with screen.
Many thanks for posting this. This is exactly the kind of thing I come to HN to find. I use screen on occasion but never really had it in my mind that I should be using it as a productivity tool.
I have once again found minor enlightenment and am already more productive because of it. Its nice when procrastinating on HN turns into a net win!
Screen is great. I wish there were an analogous tool that let me group several running X apps into a long-running session that I could connect to/disconnect from locations. Any idea if this is possible today?
I realize that this is really old, but I came back searching for something in the comments, and I now have something to add to this. I came across something (that is no longer maintained) called xmove which was describe as 'screen for X11'. http://en.wikipedia.org/wiki/Xmove
NX is supposedly able to do this, but last time I looked (which, admittedly, was two or three years ago) you had to expect serious problems if the set of available fonts on the different display servers was different (i.e. in all realistic scenarios). Oh, and it only worked on x86-32.
I've been satisfied with just using multiple tabs in Terminal.app in OS X, but I'm curious if anyone has switched from that solution to screen and wouldn't go back? (for local use in particular)
I use screen constantly and would never go back. The detachability is incredibly useful. Say I had to go to a meeting - I shut my laptop and it goes to sleep. This would normally kill any SSH session (and thus leave vim swap files lying about in my case)... but with screen I can just pick up where I left off last time.
It's also great if you want to run something big - say a job that would take 5 hours. I'm free to do whatever I want without fear that killing my ssh session will also kill the job.
I've switched from Terminal.app tabs to screen for a couple of reasons:
1) It's obvious why you'd want this for remote sessions, and I want a consistent feel whether I'm sshing into remote machines or just on my local machine.
2) I like to allocate a different screen session for each project. I can use the Terminal.app tabs to differentiate between these and between remote sessions on other machines. I could technically use multiple Terminal.app windows instead, but meh.
One thing I've found to be annoying: I can't get gnuplot to work from within a screen window (using the default AquaTerm output).
I know that there was a patch (a long time ago ~2006) for gnome-terminal that made it 'screen aware' so that each screen 'window' was a gnome-terminal tab.
I got frustrated with tabs in Terminal.app because of the keyboard shortcuts : Shift+Apple+arrows
In screen I use ^a, " to get a list of screens, then j/k to pick a screen. That may not seem like a win, but it keeps my fingers on the home keys, and feels smoother.
That and the fact that I split windows in screen fairly often means I won't go back to terminal tabs...
I've been using Screen for a number of years now, but I've recently come across Ubuntu's repackaging of it - https://help.ubuntu.com/9.04/serverguide/C/screen-profiles.h.... This seems like a fantastic way to introduce screen to new users, who are probably intimidated by screen's default bare-bones config.
I used ctrl-z, when I'm in screen I rarely need to push something to the background (prefer to just start a new vc in screen), and ofcourse I can still background something with ctrl-z z.
A screen within a screen gets ctrl-v, just because it seems mostly unused and is next to z on a dvorak keyboard :)
` cannot be used since in terminal C + ` or C + SPC or C + @ translates into same thing(only allowed characters are @ [ \ ] ^ and _ ). I personally prefer using \
Oh, I'm using just ` , not C-`. It's like hitting ESC in vi. (I also noticed that space and shift-space are indistinguishable, which is a bit annoying because in Emacs I use S-spc for languages with lots_of_soft_spacing or-several-words-joined-with-dashes.)
You could try C-o (open-line by default) or C-z (suspend/minimize by default). I use C-z as a personal command prefix. Emacs really puts those ctrl shortcuts to work, it's damn near impossible to find one that I don't use at least semi-regularly.
edit: You could maybe try C-9 or use a symbol. I was only thinking in letters.
But no, seriously, screen is one of the more useful programs I've ever used. I have a screen session running on a server somewhere, and just log into it from whatever terminal I happen to be using at the time. It's pretty much the best.
You may be kidding, but you are right on both counts. Emacs is so much better when your control key is next to 'a'. Your hands prefer it when 'aoeu' is right under your left hand. You will prefer it when your colleagues can't figure out how to type on you computer.
I was serious in that Ctrl-Z is easier to hit with dvorak, and with caps lock as control it becomes even easier, but I don't expect anyone to switch for that reason.
If you look at it through the eyes of the GNU people, you're making an active choice any time you use software. By using GNU software, you're supporting the FSF and the GNU project.
Some people would rather support the BSD license instead.
The same way there are people that want their entire software usage to be GPL/MIT/BSD/etc, there are people that want everything to be non-GPL. Unless you are going to be hacking on GNU Screen and feel the need to do something that the GPL forbids, there's really no reason to stop yourself from using a software package just because it's GPL-licensed.
I think it's ironic that your argument is remarkably similar to "nothing stops you from using a closed source program unless you planned to start hacking on the source." Sometimes you don't know when you start using something what amount of hacking may be required.
Yes, but you can contribute to GPL-licensed projects. It's just specific things that you are limited in. We're talking orders of magnitude. 'closed-source and GPL' and 'MIT/BSD and GPL' aren't even in the same ballpark.
One thing you can't do with a GPLed application -- and something I do all the time -- is try to support copyfree licensing rather than copyleft licensing.
I use screen for bazillion of years already. When doing stuff with django I like to C-a c to make a new screen, then C-a :resize 10 so that I have two screens on one (you can switch between them with C-a TAB). So in the smaller one I run server and in larger whatever I need to. Excellent when having two or more monitors with one being dedicated to full screen terminal setup like that.
This IS a hacker's ideal Terminal - a while ago I set out to write my own shell with all the features I wanted. A huge portion of the functionality I intended to implement is accomplished with GNU Screen. Since I found Screen - I haven't felt enough need to keep developing my own shell!
In the same vein, if you use a repl on a remote machine you should check out detachtty if you're not already using it. It's particularly nice for use within emacs because it doesn't eat the whole screen and it doesn't eat ^A.
In general, one should probably know their way around GNU screen in addition to tmux just because you'll probably encounter it on more installations. Much in the same way that it's really to your benefit to know a bit about vi even if you are an Emacs user.
All my rxvts run screen automatically. This means if I then leave my workstation and need to access one of the terminals remotely I can just duplicate it with screen -x.
Either way, if you use Unix, learn to use screen or tmux. They're tremendouslyuseful. (Also: Noisy wireless connections are the new flaky dialup, when it comes to resuming shell sessions.)