Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!apple!bbn!news From: news@bbn.COM (News system owner ID) Newsgroups: comp.os.minix Subject: Re: job control Message-ID: <46797@bbn.COM> Date: 11 Oct 89 21:49:48 GMT References: <3492@ast.cs.vu.nl> <3498@solo10.cs.vu.nl> <3539@ast.cs.vu.nl> <3554@solo2.cs.vu.nl> <3592@ast.cs.vu.nl> <3630@solo5.cs.vu.nl> <1989Oct10.022740.20068@utzoo.uucp> Reply-To: pplacewa@capella.bbn.com (Paul W. Placeway) Organization: Bolt Beranek and Newman Inc., Cambridge MA Lines: 25 henry@utzoo.uucp (Henry Spencer) writes: < (This would probably make a good research topic for some ambitious folks. < I'd suggest starting with a basic principle: the job-control system < should manage both input and output, so that no program needs to be < modified to know about job control and it is the job of the system -- < not the user or the programs -- to refresh the screen when switching < from one process to another.) Amen. Esp. to the tty state stuff. Garbage like tcsh has to do (automatically restoring a sane state to the tty driver) should not be needed at all. I'd also add a not-so-radical concept from Tops-20 (and predecessors), CMU's tty hacks, etc.: one should be able to change the controlling tty of a stopped process transparently. As I understand them, the CMU hacks seperate the upper and lower halves of the BSD tty driver, so that a pair can be glued together on the fly. This method is pretty (OK, _really_) ugly, though. More room for improvement. < A bit of tolerance is worth a < megabyte of flaming. Amen to that too. -- Paul Placeway