A future version of screen will have a feature that will make screen
itself slightly less obtrusive. It will not fix the issue of C-a a a
a a [space], nor will it allow you to grab non-screen'd processes
into screen, but it will make starting a new screen session
(reattaching, actually) more reasonable: The -p option will be
extended with a '+' option, which will spawn a new shell. So,
one's .profile can end with screen -R -DD -p +, which will make sure
that you always end up with a new shell to do whatever in, but at the
same time leaving you with the safety of screen. One could even use
some of the scripting techniques for screen (a primer was recently
posted to the list) to manage nested screens reasonably well.
I'm currently working on a set of scripts to wrap and manage screen,
but nested screen management is still in the TODO.
4.0.2 lacks this enhancement ("-p +"), but I'm told that the very
next release (4.0.3?) will have it.
JP
On May 16, 2006, at 6:34 AM, Joe Zbiciak wrote:
"Me too!"
Freaky thing is, this *may actually be possible*.
If screen develops the capability to import TTY FDs from another
process, then the answer may be as simple as a wrapper around your
shell that does little more than hold the FDs for your TTY, and
pipes them through. (Well, it'd also need to do the right things
w/ signals, but let's not get caught up in details.) You could
arrange for this to run from your login scripts (or
perhaps .cshrc/.bashrc if you're careful--it'd have to somehow
autodetect its or screen's presence to avoid recursion). Such a
wrapper could be very, very lightweight, since it wouldn't even
need to do any terminal emulation, since it's not doing any
terminal multiplexing. All it'd need to know how to do is
surrender its FDs over a UNIX domain socket when requested by
screen for the import.
If screen sprouts the aforementioned capability, can we get that
wrapper as a tool also? I'd add it to my login scripts in a
heartbeat. It'd be like "screen, ultra light." So light weight
there's no excuse NOT to run it.
--Joe
We sell Spatulas, and that's all!http://spatula-city.org/~im14u2c/
http://sdk-1600.spatula-city.org/
http://intyos.spatula-city.org/
----- Original Message ----
From: Dave Waxman <[EMAIL PROTECTED]>
To: screen-users@gnu.org
Sent: Tuesday, May 16, 2006 8:03:00 AM
Subject: Re: attaching detached sessions to the current one
On May 16 08:37, Aaron Davies wrote:
On 5/16/06, Michael Schroeder
A related feature I'd love to see implemented some day is the ability
to import a non-screen process into screen. For example, I might
start
a compilation or a download in a normal shell, realize I have to go
somewhere, and want to detach it for later monitoring through screen,
but if I didn't have the forsight to start it in screen in the first
place, I can't do that now.
I'd agree 100%. This is the one thing I've been praying to see added
for YEARS. I always start the most important thing RIGHT before I
realize I have to go ...
--
Dave Waxman
[EMAIL PROTECTED]
http://waxman.org/
"Some Scientists claim that hydrogen, because it is so plentiful,
is the basic building block of the universe. I dispute that. I say
there is more stupidity than hydrogen, and that is the basic
building block of the universe." - Frank Zappa
_______________________________________________
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
_______________________________________________
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
--
<Beeth> Girls are like internet domain names, the ones I like are
already
taken.
<honx> well, you can stil get one from a strange country :-P
-- geekissues.org quote #369
_______________________________________________
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
