Re: screen vs. multiple xterm's + remote connection
On Mon, Aug 16 at 03:58AM -0700, Paul Scott wrote:
> Will Trillich wrote:
> >you can now switch to console (alt-ctl-f1)
or another xterm or another tty anywhere (other computers,
possibly on other continents) :)
> >and do "screen -D -R" to reattach to your original session!
> My editor was emacs. It remained running in X where without
> screen emacs was killed. Indeed I could restart the screen
emacs wasn't running under X -- it was running at the command
line under screen! :)
> >make some more changes, go out for lunch...
> >now visit a buddy across town and ssh in to your server from his
> >windows machine and do "screen -D -R" and take up where you left
> >off. when his computer freezes up, no worries (for you)...
> >now you travel to piscataway and borrow an imac there to ssh in
> >to your home machine and do "screen -D -R" and resume your
> >undo/redo state, command-line history, suspended jobs et al --
> >as if you hadn't ever left that first xterm.
> I haven't learned how to do this yet.
ah. hidden in my blather is the how-to -- also see the man page
does not start screen, but detaches the elsewhere
running screen session. It has the same effect as
typing "C-a d" from screen's controlling terminal. -D
is the equivalent to the power detach key. If no
session can be detached, this option is ignored.
so if you forgot to gracefully "^A d" detach a session at work
(or kill its operating window for example) you can force a
detach from elsewhere. suddenly, the cleaning folks at your
office are seeing your xterm say "[remote detached]" and now yuo
can reattach to it wherever you are. (note that your shell is
still active, tho -- the command line where you originally asked
for 'screen' is listening for commands.)
so now it's detached from your xterm at work -- how to reattach
it from home?
resumes a detached screen session. No other options
(except combinations with -d/-D) may be specified,
though an optional prefix of [pid.]tty.host may be
needed to distinguish between multiple detached
screen sessions. The second form is used to connect
to another user's screen session which runs in mul
tiuser mode. This indicates that screen should look
for sessions in another user's directory. This
> >in considering xterm and screen, they are NOT mutually
> >exclusive: i.e it's NOT "multiple xterms" VS. "multiple
> I didn't make that comparison. "screen" was singular above. :)
it's a bit gray with the singular/plural, isn't it? one konsole
window can have several tabs; one screen instance (session?) can
have several virtual terminal processes (sessions?)...
> I have a DSL router connecting my LAN to the Internet. I would
> like to learn and test some of the SSH combinations you do
> routinely. I would need to use PuTTY on a Windows 98 machine
> on this LAN to try to find this Debian sid machine on the
> Internet to see if I can do any of this. I have no trouble
> doing this on the LAN. I will read some HOWTO's but would take
> any quick suggestions you have for doing this.
you need to be able to ssh in, and must have 'screen' available.
# start a screen session
# do stuff, start editing, background a few manpages,
# then close windows or leave them open and head for home
# log in from home and detach the session at work:
# if you closed your windows at work it'll already be
# reattach/resume your session:
the author's favorite is
screen -D -R
# detach if possible, and reattach it (or create a session)
to really have some fun, start TWO xterm windows side-by-side
(imagine that one of them is a troubled newbie and the other is a
2. screen -x
NOW edit something (doesn't matter which window you use). it's
fun to resize one of them and try to figure out what happens. :)
I use Debian/GNU Linux version 3.0;
Linux boss 2.4.18-bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i586 unknown
DEBIAN NEWBIE TIP #114 from D & E Radel <email@example.com>
Installing gnome-apt (although a little buggy) is A GREAT WAY TO
FIND OUT WHAT PACKAGES ARE AVAILABLE and install/remove them
Newbie tip: Also I discovered that
apt-get remove [packagename]
works much better when there are dependancy problems than
dpkg -r [packagename]
Also see http://newbieDoc.sourceForge.net/ ...