screen-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Deatached Sessions Dissapair after reboot.


From: Erik Osheim
Subject: Re: Deatached Sessions Dissapair after reboot.
Date: Thu, 2 Oct 2008 19:59:16 -0400

On Thu, Oct 02, 2008 at 03:43:09PM +0100, address@hidden wrote:
> I generally have long running screen sessions that have certain
> windows open, not always the same so not worth setting in .screenrc.
> Is it possible for screen to save session? Or at least just save the
> window name, number, path and just some basic info that would be able
> to use to reopen the same configuration?
> 
> Sorry if this is seen as ambushing the thread I thought it was a
> relavent enough question to ask in this thread.

It might be possible for screen to detect what it "thinks" is the last
command you ran in each window, and write that out to a file. Just off
the top of my head, here are the problems with that:

1. Job control/shell tricks

2. Whether to re-run commands from absolute or relative locations (e.g.
if you are in ~/alpha, run "xyz ./foo", then later resume from ~/beta,
should you do "xyz ./foo" or "xyz ~/alpha/foo".

3. Commands you would not want to repeat (e.g. rm, cvs, svn, dd, tar,
mv, cp, gunzip, yum, apt-get, etc.)

The recurring theme is that commands would very probably go wrong,
potentially catastrophically wrong, and that users would probably not
want a 95% success for a mildly convenient action if 5% of the time
something really horrible happened. For commands that it's (presumably)
always safe to run a .screenrc or script is much more reliable than
this sort of feature.

I imagine it would probably be possible to save a log of what windows
existed with some info, so that if screen crashes you could at least
see what was going on, but that's about it.

-- Erik

P.S. It's certainly true that many of my coworkers are surprised to
see their screen sessions die when the servers get turned over every
year or so. People expect this feature, despite its complexity.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]