transferring processes under csh

[Greg Woods]

In article <1264 at mcgill-vision.UUCP> mouse at mcgill-vision.UUCP (der Mouse) writes:
> In article <1074 at imagine.PAWL.RPI.EDU>, hiebeler at pawl23.pawl.rpi.edu (David Hiebeler) writes:
> > Does anyone know of a way to transfer processes between different
> > incantations of csh?
> >
> > [Suppose I put a job in the background on one terminal.]
> > Is there any way at all that I can, _from another terminal_, bring
> > that job into the foreground _on the new terminal_?
> 
> Insofar as this is possible, it's not exceptionally useful, and insofar
> as it's useful, it's not possible.

I would say, that if it was available, it would be exceptionally useful.
This would be job control for Unix, implemented with the Unix philosophy
in mind.  In fact, I've heard lots of mainframe type people complain
about this lacking feature.

[ der Mouse again: ]
> But, and I suspect this is the reason this capability isn't available
> right now, this isn't good enough.  Suppose the job is an editor - vi,
> say.  The terminal will in general be a different type, implying that
> all vi's knowlege about the terminal must be reworked.  Unfortunately,
> there's no way for vi to find out what the current terminal type is!
> Or rather, no practical way.  It would require that the shell rewrite
> the environment in the vi process.  And a mechanism to signal vi that
> it has to reread the environment.  And nontrivial code in vi to handle
> this change.  And in every other screen-oriented program.  And
> rewriting the environment is, in general, not even possible without
> kernel modifications so extensive as to amount to half of a rewrite.

Part of the necessary mechanisms do exist.  SIGCONT tells a process it
is continuing from a stop.  It might be better if the process could
determine if it was continuing in the foreground, or background, though
I guess SIGTTIN & SIGTTOU are sufficient.

I think it would be wrong to have the kernel sneak in and change a
stopped process's environment list.  Perhaps a device driver
(/dev/environ) could be used by a process, upon SIGCONT, to read a new
environment from.  Would it read the entire new environment and be able
to pick and choose, or would the (new) parent process only make certian
values available?  Naturally, any complex programme that wanted to take
advantage of this new method of job control would require enhancement.

I think it is necessary for the kernel to re-wire stdin, stdout, and
stderr for the child process to the new tty, and possibly to somehow
make the child a member of the new ttygroup.  Maybe this will be
implicit when the child ppid is changed in the process table?

[ der Mouse again: ]
> There are also some difficult questions: what does the old parent
> process see?  An exited child?  Killed by some special signal number?
> Child vanishes without dying (the truth, but highly confusing to
> existing programs)?  And presumably you'd want to take over a whole job
> at once....  Perhaps I'll try to implement this.  One thing's for sure:
> it should be interesting.

The old parent should see an exited child, hopefully with a new exit
value from sysexits.h that would reveal its fate.  Remember also that
SIGCHLD only means that the child's status has changed.

In most cases I'd imagine that the parent would already be dead anyway.
Maybe only foster children can be allowed to be adopted by a new parent.

Of course children can only be adopted by a parent with the same real or
effective UID, or by a superuser process.  What kind of security
precautions need to be taken by a superuser process?  Should this even
be allowed by the superuser, since the superuser can always su?

If the orphan child is a process group leader, do you adopt the whole
family?  I think so.  If you did this for SysV would there be extensions
required to better manage "control terminals"?  (These extensions are
probably necessary for BSD style Job Control anyway.)

I guess a new system call is required:  adopt(pid, ttyfd, ...).

It's too bad System V doesn't have "real" job control....  Maybe they'd
have done it right....  Mabey they will yet....  ISC did their best with
their SysV csh implementation in 386/ix, but if you put a job in the
background, and then hang up, it never gets SIGHUP.  It seems that the
background job is in a new process group, without a control terminal,
even though it's stdout remains tied to the old tty.  It's a quick and
dirty way to lock up a port.

Termio(7) is far easier to understand and use than newtty(4), but it's
just not as feature laden.  Termio(7) for SysV needs to be able to
generate SIGTSTP, SIGTTIN, and SIGTTOU; these and SIGSTOP must do what
they are supposed to do in the kernel; and termio(7) must learn to erase
tabs, and not erase past the beginning of the input buffer.  Then all of
us SysV lovers wouldn't really care to see BSD again!  I suppose one
could write a new line discipline to understand the tabs and erasing
bit, but the kernel needs new hooks for the new signals.  Anybody game?
I have the feeling you'd end up re-compiling a lot of utilities to hook
this stuff in, even if you were careful about the values of new
constants (ie: signals), and didn't care to add capability to anything
to explicitly use these new features.  A new command (ntty) could be
written instead of extending stty.  Even so, I think you'd need a source
license, even if someone else wrote the new modules.  Anyone want to
prove me wrong by doing it?

How about the ability to adopt (migrate) jobs from another machine on a
homogeneous network?
-- 
						Greg Woods.

UUCP: utgpu!woods, utgpu!{ontmoh, ontmoh!ixpierre}!woods
VOICE: (416) 242-7572 [h]		LOCATION: Toronto, Ontario, Canada