Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!oliveb!sun!gorodish!guy From: guy@gorodish.Sun.COM (Guy Harris) Newsgroups: comp.unix.wizards Subject: Re: Input Line Editing Message-ID: <59879@sun.uucp> Date: 14 Jul 88 06:24:36 GMT References: <16456@brl-adm.ARPA> <9666@eddie.MIT.EDU> <2362@ncr-sd.SanDiego.NCR.COM> Sender: news@sun.uucp Lines: 26 > Isn't this what STREAMS are for? Since a stream module has access > to the ioctls it should know when it is or is not wanted. It would > replace the standard line discipline available in cooked mode. If it *replaces* the standard line discipline, there's nothing particularly streams-specific about it; you could do the same thing on a system with a non-streams tty driver by replacing the line discipline. You might get something more out of streams by sticking it *above* the standard line discipline and running the standard line discipline permanently in non-canonical mode. However, I'm not willing to say, off the top of my head, that the line editor would work sufficiently well without the ability to get at the state of the line discipline. Then again, I don't think this is what streams are for; I'd prefer to use them for things that you can't put in user mode. I'd rather have the input line editor run the real terminal, and emulate a terminal - or terminals, if you want multiple windows on a dumb terminal - via a pseudo-tty or pseudo-ttys. That way I can write my own input line editor if I want to, and not have to get somebody with sufficient privileges to link it into the kernel of every machine I use. Of course, if your OS implements the tty driver in user mode (consider a system - such as Aegis / DOMAIN/OS? - where "read" and "write" are implemented in user mode, along with the moral equivalent of "cdevsw"), you might be able to replace it without sufficient privilege.