Path: utzoo!utgpu!watmath!att!dptg!mtune!jrw From: jrw@mtune.ATT.COM (Jim Webb) Newsgroups: comp.unix.questions Subject: Re: Where Goeth the Line-editing? (was Re: Strangeness in shell) Summary: Look! Up in the sky. It's a bird. It's a plane. It's a frog? No, it's a stream module! :-) Message-ID: <8055@mtune.ATT.COM> Date: 7 Aug 89 19:52:52 GMT References: <432@mccc.UUCP> <9700009@osiris.cso.uiuc.edu> <2277@auspex.auspex.com> <13303@bloom-beacon.MIT.EDU> Organization: AT&T ISL Middletown NJ USA Lines: 23 In article <13303@bloom-beacon.MIT.EDU>, jik@athena.mit.edu (Jonathan I. Kamens) writes: > In multics, it was possible to install a driver that lived at the > gateway between the actual terminal and user processes. This driver > would intercept and process *all* input before sending it to the > process. Therefore, if you wrote a line-editing driver and installed > it, it would work for *every* program on the system, without fail. > There were, of course, ways to turn off the line-editing features for > programs that needed character-by-character input. This is *exactly* what a streams module does in SVR3 and beyond. For example, when you are talking over a streams based tty line, you are talking thru a streams module that handles backspaces, and kill characters, and tabs, and the like. It then sends the data to the process when it gets the end of line character. So, it would be fairly trivial to code up a streams driver to do the line editting we all like in ksh, provided you wanted to keep your history in kernel space at least :-) -- Jim Webb "Out of Phase -- Get Help" att!mtune!jrw #include jrw@mtune.att.com