Re: shipping processes between ttys

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sun, Dec 07, 2014 at 07:02:42AM -0700, Andy Ruhl wrote:
 > > Somebody mentioned reptyr (https://github.com/nelhage/reptyr) in chat
 > > tonight, and so I was thinking about how one might do it properly;
 > > this is a topic I've looked at in the past from time to time, so I
 > > think I have a viable plan for it. Which I'm going to post, both for
 > > feedback and in the hope that I can trick someone into implementing it
 > > for me. :-)
 > >
 > > (1) It seems clear that the unit of transfer should be a whole process
 > > group (or "job"); if you want to move your mailreader, it makes sense
 > > for the editor it spawned to go with it, and so on.
 > >
 > > (2) It also seems desirable as part of the same machinery to be able
 > > to reconnect to jobs that have been lost because of a disconnect. For
 > > that and some technical reasons I think moving a job should have two
 > > parts: first detaching it from one tty and then attaching it to
 > > another. It follows from Occam's razor that a job that's been detached
 > > but not yet reattached should be in the same state as a background job
 > > that's been hung up on; formally, an orphaned process group.
 > >
 > 
 > I hate to ask an obvious question, but what is the application of this in a
 > world where "screen" exists? I went to the link and it says "when you
 > forget to start something in screen" which seems like the only obvious
 > reason to use something like this. Although screen isn't perfect I
 > suppose...

Because screen's a hack... also, if you have ten bazillion xterms open
on your desktop, do you connect them all to the same screen instance?
And if so, how do you keep track of which sessions belong to what? (Or
is this a problem only I have?)

% ps -x | grep xterm | wc -l
      40

-- 
David A. Holland
dholland%netbsd.org@localhost