jik@athena.mit.edu (Jonathan I. Kamens) (08/07/89)
A good place to look for an example of one way to have a uniform line-editing interface is in Multics (Multics people correct me if I'm wrong, because I'm writing this second-hand -- I never even got to login to MIT Multics before it went away :-(). 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. So Multics did what several people have been suggesting -- make the terminal editing capabilities separate both from the program and the actual terminal by putting it in a driver that can be modified or replaced by the user. Wouldn't it be great if you could use line-editing in ed? History substitution? Wouldn't it be great if all of the shells used the same characters and commands for history substitution and command-line editing? You get the idea.... Jonathan Kamens USnail: MIT Project Athena 432 S. Rose Blvd. jik@Athena.MIT.EDU Akron, OH 44320 Office: 617-253-4261 Home: 216-869-6432
shepperd@dms.UUCP (Dave Shepperd) (08/07/89)
From article <13303@bloom-beacon.MIT.EDU>, by jik@athena.mit.edu (Jonathan I. Kamens): > > [stuff deleted] > > 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. > Actually, Un*x has this "feature" as well. At least, sort of. The concept of line disciplines was developed to address this issue (or other protocol handling requirements). Line discipline 0 is responsible for doing the input editing you get when doing normal (such as echo, backspace processing, line kill, signals, etc). It also does the stuff such as adding extra cr's, lf's, null's or other things in the output stream as so indicated by various stty flags. Line disciplines don't do the job as neatly as is desired (a better idea, STREAMS, was invented which does the job quite a bit better). I wrote a command line editor using the line discipline mechanism on Xenix (cuz that's what I had) and can say it's no picnic. I haven't a clue whether it'll work on another flavor of Unix since I don't have one (other than SCO/UNIX 3.2) and am not interested in getting one just yet. Although I haven't brought up SCO/Unix 3.2 (it doesn't have support for the Ethernet boards I have), from what I can gather in its doc set, the line discipline mechanism is exactly the same as on Xenix 2.3.2, so it ought to install and work without any trouble (I'll believe it when I see it). I've been using my editor for some months now as have all the other Xenix users here and we have found it to be quite indispensible. None of us understands why an interactive line editor hasn't been part of the distribution of most flavors of Un*x for years. -- Dave Shepperd. shepperd@dms.UUCP or weitek!dms!shepperd Atari Games Corporation, Sycamore Drive, Milpitas CA 95035. (Arcade Video Game Manufacturer, NOT Atari Corp. ST manufacturer).
guy@auspex.auspex.com (Guy Harris) (08/08/89)
>> 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. > >Actually, Un*x has this "feature" as well. At least, sort of. Except that the Multics driver could live in user mode, and be inserted into the I/O stream by J. Random User without getting the help of a system administrator; UNIX line disciplines and streams modules tend to live in the kernel, which means that, in general, 1) they require a privileged user to install them and 2) their pages are wired down. With a reasonable pseudo-tty-like mechanism, you can run the input line editor as a separate process, buying back the advantages of the Multics one (you can even do much of it without as wonderful a pseudo-tty mechanism as you'd like - can you say "EMACS shell window"?).
jrw@mtune.ATT.COM (Jim Webb) (08/08/89)
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 <std/disclaimer.h> jrw@mtune.att.com
ag@cbmvax.UUCP (Keith Gabryelski) (08/08/89)
To comp.unix.wizards since it seems more appropriate. In article <795@dms.UUCP> shepperd@dms.UUCP (Dave Shepperd) writes: >From article <13303@bloom-beacon.MIT.EDU>, by jik@athena.mit.edu (Jonathan I. Kamens): >> 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. >> > >Actually, Un*x has this "feature" as well. At least, sort of. The >concept of line disciplines was developed to address this issue (or >other protocol handling requirements). Line discipline 0 is responsible >for doing the input editing you get when doing normal (such as echo, >backspace processing, line kill, signals, etc). It also does the stuff >such as adding extra cr's, lf's, null's or other things in the output >stream as so indicated by various stty flags. Line disciplines don't do >the job as neatly as is desired (a better idea, STREAMS, was invented >which does the job quite a bit better). We actually just wrote a line discipline that emulates the TOPS-20 line discipline for our SYSV3.2 port to the Amiga (echoing only when input was read), ^O, ^V, ^W, and no backspacing over your prompt. I was going to add history and real command line editting, but finally came to my senses that the kernel was just not the place for such a user-configurable/messy thing. The best suggestion I've heard is a daemon the user runs that gets handed each character the user types and deals with them and the canon buffer appropriately. I did finally break down and added a last command hack but am sure this will disappear when something better is found. I am open to suggestions. Pax, Keith
guy@auspex.auspex.com (Guy Harris) (08/09/89)
>This is *exactly* what a streams module does in SVR3 and beyond.
And what a line discipline did/does in other UNIX releases, except that,
as I noted elsewhere, the Multics stuff didn't live in the kernel, while
line disciplines and streams modules do.shepperd@dms.UUCP (Dave Shepperd) (08/09/89)
From article <7564@cbmvax.UUCP>, by ag@cbmvax.UUCP (Keith Gabryelski): > > We actually just wrote a line discipline that emulates the TOPS-20 > line discipline for our SYSV3.2 port to the Amiga (echoing only when > input was read), ^O, ^V, ^W, and no backspacing over your prompt. > > I was going to add history and real command line editting, but finally > came to my senses that the kernel was just not the place for such a > user-configurable/messy thing. > I agree that putting the editor in kernel code is ugly, however, since there doesn't seem to be any better way to do it without bringing the system to its knees, and IMHO line editing is absolutely required, it has to be there. Until somebody cooks up something better (like everybody starts using STREAMS), I'm going to keep using my kernel code line editor. > The best suggestion I've heard is a daemon the user runs that gets > handed each character the user types and deals with them > and the canon buffer appropriately. > Don't forget that the daemon would have to get all the output text too. During development of my discipline I noticed that many utilities do single character output to the terminal. I believe the poor system would really slow down if all terminal I/O had to be routed through another usermode task. -- Dave Shepperd. shepperd@dms.UUCP or motcsd!dms!shepperd Atari Games Corporation, 675 Sycamore Drive, Milpitas CA 95035. (Arcade Video Game Manufacturer, NOT Atari Corp. ST manufacturer).
guy@auspex.auspex.com (Guy Harris) (08/10/89)
>I agree that putting the editor in kernel code is ugly, however, >since there doesn't seem to be any better way to do it without >bringing the system to its knees, and IMHO line editing is >absolutely required, it has to be there. Until somebody cooks >up something better (like everybody starts using STREAMS), >I'm going to keep using my kernel code line editor. And even once everybody starts using STREAMS, you'll *still* keep it (although modified for STREAMS), since streams modules run in the kernel. However, don't assume that there "isn't any better way to do it without bringing the system to its knees" before trying one of the other ways; try snarfing Ken Almquist's "atty", for instance, if you have BSD-flavored pseudo-ttys.
mouse@mcgill-vision.UUCP (der Mouse) (08/18/89)
In article <805@dms.UUCP>, shepperd@dms.UUCP (Dave Shepperd) writes: > From article <7564@cbmvax.UUCP>, by ag@cbmvax.UUCP (Keith Gabryelski): >> [stuff about command-line in the kernel] > I agree that putting the editor in kernel code is ugly, however, > since there doesn't seem to be any better way to do it without > bringing the system to its knees, Why does everyone keep saying this? Doing this at the user level does not *necessarily* bring the system to its knees. (You managed to push one of my buttons.) There are systems where it will, yes. But there are many systems where it won't. On one system I use regularly, for example, here's what happens when I type a simple character like x: - Two interrupts, each one involving waking up a user process (one each for pressing and releasing the key) - Switch back to kernel mode (write on a socket) - Switch back to user mode, different process (read the socket) - Kernel mode (write on a pty) - User mode, process #3 (read the pty) - Kernel mode (write echo to pty) [see below] - User mode, process #2 (read pty) - Switch back to kernel mode (write on the socket) - Back to user mode, process #1 (read the socket) - Finally see the x appear on my screen. The system in question is a Sun running X. I can now rlogin from that window. This adds more switches and two trips over the Ethernet. Funny, but performance is still just fine, thank'eeverymuch. ["see below": At least 90% of my keystrokes are typed to things that use cbreak+noecho mode, so yes, there is a trip to user mode here.] > I believe the poor system would really slow down if all terminal I/O > had to be routed through another usermode task. There are lots of counterexamples. Where did you acquire this belief? There are, undoubtedly, many systems where this is true. It is *not* universally true. And as CPUs get faster compared to humans, it is becoming less and less worth worrying about, IM(ns)HO. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu