Checksum: 06773 Path: utzoo!utgpu!woods From: woods@gpu.utcs.toronto.edu (Greg Woods) Date: Sat, 27-Aug-88 16:20:10 EDT Message-ID: <1988Aug27.162010.332@gpu.utcs.toronto.edu> Organization: G. A. W. Consulting Newsgroups: comp.unix.wizards Subject: Re: transferring processes under csh Summary: job control done right (SysV too?) References: <1074@imagine.PAWL.RPI.EDU> <1264@mcgill-vision.UUCP> Reply-To: woods@gpu.utcs.Toronto.EDU (Greg Woods) Keywords: job control In article <1264@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes: > In article <1074@imagine.PAWL.RPI.EDU>, hiebeler@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