Re: shipping processes between ttys

[Rhialto]

On Sun 07 Dec 2014 at 03:25:36 +, David Holland 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. :-)

For a long time I have sort of wanted some variation on this. I wonder
if your plan can be generalized in a sensible way to accomplish my idea.

Suppose I run some long-running process. It delivers its output to the
tty. After a while I realise that this was a mistake; I want the output
redirected to a file instead. Killing the process and restarting is not
an option (too much time already spent on the task, or whatever). How to
do that?

The same thing, but the other way around. Or with stdin. In other words,
changing the actual files that file descriptors are connected to.
Possibly even plumbing a stdout and stdin together with a pipe.

-Olaf.
-- 
___ Olaf 'Rhialto' Seibert  -- The Doctor: No, 'eureka' is Greek for
\X/ rhialto/at/xs4all.nl-- 'this bath is too hot.'


pgpneMS3nsZro.pgp
Description: PGP signature

Re: shipping processes between ttys

[Andy Ruhl]

On Sat, Dec 6, 2014 at 8:25 PM, David Holland dholland-t...@netbsd.org
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...

Andy