dam@mtgzz.att.com (d.a.morano) (09/01/88)
> article <12016@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: > > one of the few things I like about DOS and VMS is that the > >characters are echoed as they are read, not as they are typed. This > >prevents display of info designed to be read "no echo." Fortunately > >article <4619@cbmvax.UUCP>, ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: > Yes! Unix-style echo just plain sucks, in my opinion. The right place I have used both styles of echo now for quite a while and I tend to prefer the style where the characters are echoed as they are read. There are many things that I can't stand in MSDOS and VMS but they got this thing right. Sometimes I refer to the preferred style (MSDOS/VMS) as 'type behind' because the characters are echoed behind (or after) the start of a read to the TTY. Also, on UNIX(TM), the echoed characters can get displayed in the middle of a write(2) to the terminal. This serves to destroy background escape sequences that may be printing to the terminal from a background process using write(2) directly. The resulting effect is garbage on the terminal display. I would like to see a new line discipline that fixes these problems. The VMS terminal driver seems to handle all of these subtle features beautifully. When ever I have had to write a terminal driver, I always code for the preferred 'type behind' feature, the atomic write(2) operations, as well as other little good features. Dave Morano Opinions expressed are mine alone and do not necessarily represent those of AT&T Bell Laboratories. UNIX is a registered trademark of AT&T.
john@polyof.UUCP ( John Buck ) (09/02/88)
In article <4477@mtgzz.att.com>, dam@mtgzz.att.com (d.a.morano) writes: > > article <12016@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: > > > one of the few things I like about DOS and VMS is that the > > >characters are echoed as they are read, not as they are typed. This > > >prevents display of info designed to be read "no echo."... > I have used both styles of echo now for quite a while and I tend to > prefer the style where the characters are echoed as they are read. > There are many things that I can't stand in MSDOS and VMS but they > got this thing right. ... Nah. Type-ahead at read time can cause you lots of grief (lots more than the default way Unix handles it.) Spose you type three or four commands head (I often do this, as do other's at our site). I, for one, want to see what the system got! I don't want to find out later that I made a mistake in typing the first "typed-ahead" command. This could cause the subsequent commands I type to not function properly!. If you are going to delay echo until read, you might as well forget about type ahead. (I, do not type commands correct 100% of the time, more often than not, I make mistakes). If "scrambled" input/output bothers you (and you are on a Berkeley system), just do a "^R" to retype the input the system has so far... The only thing that gets screwed up is the output, which you probably don't care THAT much about anyway. The other thing we did (for people who can't stand mixed input/output), is to add an option to the tty line disc to not perform any output (ttwrite) type calls to the terminal, if a line is in the middle of being typed. (pos > 0). As soon as you hit a RETURN, the output that may have backed-up is flushed. (It's kind of like typing a '^S' before every character you type ahead on a new line, and a '^Q' when the RETURN is hit.) (Apollo does this on their serial-line driver...) I'm curious to know: do you folks who tolerate "invisible" type-ahead ever make mistakes in typing commands (ahead)? If so, when do you detect the mistakes? Before it's too late? How do you see what you are correcting? polyof!john
gwyn@smoke.ARPA (Doug Gwyn ) (09/02/88)
In article <371@polyof.UUCP> john@polyof.UUCP ( John Buck ) writes: >I'm curious to know: do you folks who tolerate "invisible" type-ahead >ever make mistakes in typing commands (ahead)? If so, when do you detect >the mistakes? Before it's too late? How do you see what you are correcting? In a UNIX implementation of deferred echo, presumably one would type ^R to check his most recent input line while there is still time to edit it (before typing a newline).
jfh@rpp386.Dallas.TX.US (The Beach Bum) (09/02/88)
In article <371@polyof.UUCP> john@polyof.UUCP ( John Buck ) writes: >I'm curious to know: do you folks who tolerate "invisible" type-ahead >ever make mistakes in typing commands (ahead)? If so, when do you detect >the mistakes? Before it's too late? How do you see what you are correcting? i touch type. generally i know that i have made a mistake before i even see what i have typed. i don't even know what i am correcting when i correct, just that i have typed some wrong character (like the d in typed just now, i typed a space (and did it again just there ;-) and then went back and corrected it to be a d) my question has always been: how many programmers, etc, touch type? -- John F. Haugh II (jfh@rpp386.Dallas.TX.US) HASA, "S" Division "If the code and the comments disagree, then both are probably wrong." -- Norm Schryer
daveh@marob.MASA.COM (Dave Hammond) (09/02/88)
In article <8418@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In a UNIX implementation of deferred echo, presumably one would >type ^R to check his most recent input line while there is still >time to edit it (before typing a newline). Only if the UNIX implementation supports ^R. Dave Hammond UUCP: {uunet|...}!marob.masa.com!!daveh DOMAIN: daveh@marob.masa.com ------------------------------------------------------------------------------
gwyn@smoke.ARPA (Doug Gwyn ) (09/03/88)
In article <397@marob.MASA.COM> daveh@marob.masa.com (Dave Hammond) writes: -In article <8418@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: ->In a UNIX implementation of deferred echo, presumably one would ->type ^R to check his most recent input line while there is still ->time to edit it (before typing a newline). -Only if the UNIX implementation supports ^R. Well, of course. If it didn't already support ^R, one would add that as part of the implementation.
dwc@homxc.UUCP (Malaclypse the Elder) (09/03/88)
In article <371@polyof.UUCP>, john@polyof.UUCP ( John Buck ) writes: > > I'm curious to know: do you folks who tolerate "invisible" type-ahead > ever make mistakes in typing commands (ahead)? If so, when do you detect > the mistakes? Before it's too late? How do you see what you are correcting? > i can't stand the invisible type-ahead on dos. i really would like to know what i am typing into the system. i wind up not typing ahead at all. the solution you presented sounds real good to me. danny chen att!homxc!dwc
dwc@homxc.UUCP (Malaclypse the Elder) (09/03/88)
In article <6140@rpp386.Dallas.TX.US>, jfh@rpp386.Dallas.TX.US (The Beach Bum) writes: > i touch type. generally i know that i have made a mistake before i even > see what i have typed. i don't even know what i am correcting when i > correct, just that i have typed some wrong character (like the d in > typed just now, i typed a space (and did it again just there ;-) and then > went back and corrected it to be a d) my question has always been: how > many programmers, etc, touch type? i also touch type. but i am also insecure. i like to see what i am typing in. you never know when your fingers are in the correct spot on the keyboard or whether you hit the space bar to soon and you type something like: rm back * tmp* instead of rm back* tmp* this has happened to me before. (even when i look, i make mistakes when i type ahead). danny chen att!homxc!dwc
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (09/04/88)
In article <8418@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In a UNIX implementation of deferred echo, presumably one would >type ^R to check his most recent input line while there is still >time to edit it (before typing a newline). No, no, no... part of the beauty of doing echo the non-unix way is that you don't need to ^R to see what you typed. It's unix-echo that causes your input line to get screwed up so you have to type ^R. With echo done right, you wouldn't even need a ^R feature except when some extraneous output happens while you are in the middle of a line -- such as when someone write()s to your terminal or if a background job does some output. -- -=] Ford [=- . . (In Real Life: Mike Ditto) . : , ford@kenobi.cts.com This space under construction, ...!ucsd!elgar!ford pardon our dust. ditto@cbmvax.commodore.com
gwyn@smoke.ARPA (Doug Gwyn ) (09/04/88)
In article <4659@cbmvax.UUCP> ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: >No, no, no... part of the beauty of doing echo the non-unix way is that you >don't need to ^R to see what you typed. It's unix-echo that causes your >input line to get screwed up so you have to type ^R. So how the hell can you see what you typed so far without having to wait until the matching input operation is initiated? I have used deferred-echo systems and one DOES need ^R.
warner@hydrovax.nmt.edu (M. Warner Losh) (09/05/88)
In article <371@polyof.UUCP>, john@polyof.UUCP ( John Buck ) writes... >I'm curious to know: do you folks who tolerate "invisible" type-ahead >ever make mistakes in typing commands (ahead)? If so, when do you detect >the mistakes? Before it's too late? This tends to be less of a problem than you might think. "Type behind" as one person called it is great. It allows you to do things like have a smart terminal driver that remembers the last thing you typed so you can go back and edit it (not like that !$ stuff in csh, but less powerful). I make mistakes with the invisible type ahead. Many times I do catch it before it's too late. With VMS you can do a ^X anytime the terminal is not in "raw" mode and clear the current type ahead buffer. How does one do this under unix? (Really, I'd like to know, but I don't think it can be done if you have entered several commands...) > How do you see what you are correcting? How do you see what you are correcting when you type the password to your system. It's the same sort of deal. > >polyof!john -- Warner Losh warner@hydrovax.nmt.edu ...!unmvax!nmtsun!warner%hydrovax My spelling and views are my own. Only the letters have been changed...
mikep@ism780c.isc.com (Michael A. Petonic) (09/05/88)
In article <4659@cbmvax.UUCP> ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: >In article <8418@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >>In a UNIX implementation of deferred echo, presumably one would >>type ^R to check his most recent input line while there is still >>time to edit it (before typing a newline). >No, no, no... part of the beauty of doing echo the non-unix way is that you >don't need to ^R to see what you typed. It's unix-echo that causes your >input line to get screwed up so you have to type ^R. Following the thread, I think Doug was saying that if an O.S. used MS-DOS echo and if you wanted to check what you typed (while another command is running), you could type ^R to see it. This would be desirable since the MS-DOS way doesn't echo out until it reads the input and those of us less gifted would have a way of visually scanning the line to make sure it's correct. -MikeP -- Michael A. Petonic mikep@ism780c.isc.com ``Have a heart... But don't take mine.''
eirik@tekcrl.TEK.COM (Eirik Fuller) (09/05/88)
All this talk about how to properly jumble input and output an a tty device reminds me of a rather obvious fact: on a tty device, input and output get jumbled. Actually, with some shells you'll see your input twice, once while the shell has temporarily reverted to echo mode, and again when it cleans up (I am thinking in particular of tcsh). I think the (gag, retch) Puniflex shell does something similar ... This reminder gives me a sudden urge to hack xterm so that there is a separate row (something like a status line) in which typeahead gets echoed as it's typed. But, if I wait long enough, this urge will pass. Besides, a vague memory tells me Apollo thought of this already, or something like it anyway. The point, if there is one, is that windowing systems could, in principle, eliminate such arguments about increasingly-but-never-quite obsolete things like terminals.
lew@gsg.UUCP (Paul Lew) (09/06/88)
[background for new reader]:
* Most Unix systems echo input characters as soon as one types.
It makes you see what you type but the output may not be 'pretty'.
* VMS and DOS defer the echoing until the shell is ready to read next
command. You can get cleaner listing files this way but you better
know what you typed.
* It is a trade-off between these 2 methods
[my 2 cents]:
One way to solve this problem can be found in today's windowing systems which
separate input editing window from output window and you will not have this
problem.
--
Paul Lew {oliveb,harvard,decvax}!gsg!lew (UUCP)
General Systems Group, 5 Manor Parkway, Salem, NH 03079 (603) 893-1000limes@sun.com (Greg Limes) (09/07/88)
In article <3028@tekcrl.CRL.TEK.COM>, eirik@tekcrl (Eirik Fuller) writes: >This reminder gives me a sudden urge to hack xterm so that there is a >separate row (something like a status line) in which typeahead gets >echoed as it's typed. But, if I wait long enough, this urge will pass. >Besides, a vague memory tells me Apollo thought of this already, or >something like it anyway. A not-so-vague memory tells me that IBM thought of this many years back. At least, that is how I remember interacting with the mainframe where I worked during college. This feature also shows up in some terminal emulators, usually in the guise of a "conference" or "line-oriented" mode. -- Greg Limes [limes@sun.com] semper ubi, sub ubi
gwyn@smoke.ARPA (Doug Gwyn ) (09/08/88)
In article <1059@nmtsun.nmt.edu> warner@hydrovax.nmt.edu (M. Warner Losh) writes: >With VMS you can do a ^X anytime the terminal is >not in "raw" mode and clear the current type ahead buffer. How does one >do this under unix? I don't know of any UNIX implementation that provides such a feature, although it is doable and I've often wished I had it (its utility is not limited to deferred-echo terminal handlers). The nearest equivalent on UNIX is to type the interrupt key, which in many cases will flush type-ahead. Unfortunately it also sends a signal to the process group!
mikep@ism780c.isc.com (Michael A. Petonic) (09/08/88)
In article <1059@nmtsun.nmt.edu> warner@hydrovax.nmt.edu (M. Warner Losh) writes: >In article <371@polyof.UUCP>, john@polyof.UUCP ( John Buck ) writes... >>I'm curious to know: do you folks who tolerate "invisible" type-ahead >>ever make mistakes in typing commands (ahead)? If so, when do you detect >>the mistakes? Before it's too late? > >This tends to be less of a problem than you might think. "Type behind" >as one person called it is great. It allows you to do things like have >a smart terminal driver that remembers the last thing you typed so you can >go back and edit it (not like that !$ stuff in csh, but less powerful). Being able to edit "remembered" lines is totally unrelated to type-ahead and type-behind methods of echoing. For example, look at KSH. >I make mistakes with the invisible type ahead. Many times I do catch it >before it's too late. With VMS you can do a ^X anytime the terminal is >not in "raw" mode and clear the current type ahead buffer. How does one >do this under unix? (Really, I'd like to know, but I don't think it can >be done if you have entered several commands...) On BSD systems, there is a key (default ^O) that flushes the input queue. It is specified by: ``stty flush <char>''. Yes, it works if you have typed several lines ahead. >> How do you see what you are correcting? >How do you see what you are correcting when you type the password to your >system. It's the same sort of deal. Yes, but a password only has to be typed once per session, while presumably, you'd do type-ahead more than once a session. -MikeP -- Michael A. Petonic mikep@ism780c.isc.com ``Have a heart... But don't take mine.''
jgh@root.co.uk (Jeremy G Harris) (09/08/88)
In article <4659@cbmvax.UUCP> ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: >.... It's unix-echo that causes your >input line to get screwed up so you have to type ^R. Fuel to the fire: The Amiga CLI echos immediately but holds output until the input line is completed. Jeremy -- Jeremy Harris jgh@root.co.uk
peter@ficc.uu.net (Peter da Silva) (09/08/88)
In article <371@polyof.UUCP>, john@polyof.UUCP ( John Buck ) writes: > The other thing we did (for people who can't stand mixed input/output), is > to add an option to the tty line disc to not perform any output (ttwrite) > type calls to the terminal, if a line is in the middle of being typed. > (pos > 0). As soon as you hit a RETURN, the output that may have backed-up > is flushed. (It's kind of like typing a '^S' before every character you > type ahead on a new line, and a '^Q' when the RETURN is hit.) The Amiga Console Device does this, and it's marvelous. (It actually does this by locking the console window's layer while the line is being typed, so graphics and other stuff going on behind its back are intercepted as well). Cromemco once did an utterly horrid UNIX lookalike called Cromix, but it had one nice feature... if you set the tty modes right, it would echo both when you typed and when the tty was read if you had typeahead. Sort of like what ksh does when you have complete lines of typeahead now. -- Peter da Silva `-_-' Ferranti International Controls Corporation. "Have you hugged U your wolf today?" peter@ficc.uu.net
guy@gorodish.Sun.COM (Guy Harris) (09/09/88)
> On BSD systems, there is a key (default ^O) that flushes the input > queue. It is specified by: ``stty flush <char>''. Yes, it works if > you have typed several lines ahead. Oh, no, it doesn't! ^O flushes *output*, not *input*, on a vanilla BSD system. (Yes, I tried it. It flushes output, not input.)
nate@mipos2.intel.com (Nate Hess) (09/09/88)
In article <4477@mtgzz.att.com>, dam@mtgzz (d.a.morano) writes: >Also, on UNIX(TM), the echoed >characters can get displayed in the middle of a write(2) to the terminal. >This serves to destroy background escape sequences that may be printing >to the terminal from a background process using write(2) directly. The >resulting effect is garbage on the terminal display. A simple, straight-forward, and beneficial solution to the problem of background jobs writing garbage to the screen is to do stty tostop which will cause background jobs to stop on output, just as they do by default for input. This is especially handy for background find commands, etc. Your mileage may vary, --woodstock -- "What I like is when you're looking and thinking and looking and thinking...and suddenly you wake up." - Hobbes nate@mipos3.intel.com ...!{decwrl|hplabs!oliveb|amd}!intelca!mipos3!nate
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (09/09/88)
In article <1059@nmtsun.nmt.edu> warner@hydrovax.nmt.edu (M. Warner Losh) writes: >I make mistakes with the invisible type ahead. Many times I do catch it >before it's too late. With VMS you can do a ^X anytime the terminal is >not in "raw" mode and clear the current type ahead buffer. How does one >do this under unix? (Really, I'd like to know, but I don't think it can >be done if you have entered several commands...) In article <15410@ism780c.isc.com> mikep@ism780c.UUCP (Michael A. Petonic) writes: : : On BSD systems, there is a key (default ^O) that flushes the input : queue. It is specified by: ``stty flush <char>''. Yes, it works if : you have typed several lines ahead. That's odd, ^O certainly doesn't have that effect on my BSD system. It flushes output, not input. Is your kernel hacked maybe? When I want flush all my input, I just do a ^Z and then "fg" or "bg". Larry Wall lwall@jpl-devvax.jpl.nasa.gov
ka@june.cs.washington.edu (Kenneth Almquist) (09/09/88)
jfh@rpp386.Dallas.TX.US (The Beach Bum) writes: > i touch type. generally i know that i have made a mistake before i even > see what i have typed. i don't even know what i am correcting when i > correct, just that i have typed some wrong character (like the d in > typed just now, i typed a space (and did it again just there ;-) and then > went back and corrected it to be a d) my question has always been: how > many programmers, etc, touch type? I touch type, but the only error I am generally aware of without seeing it is when I don't strike a key squarely--and then I have to look to see whether I struck 0, 1, or 2 characters. I kind of like the EMACS shell mode, where if you are typing away, output is inserted before the stuff you are typing. (Unfortunately EMACS doesn't know when data is actually read; once you hit RETURN subsequent output is inserted after the line you typed.) The two window approach used by Apollo sounds pretty good also. I'm *not* recomending that these features be added to the tty driver. I've concluded that the UN*X model of sticking all the tty handling intelligence inside the kernel isn't very good. Let the terminal do all the stuff like line editing, or, for people with dumb terminals, let the work be done by an emulation program running on the host which makes their dumb terminals look like smart ones. Kenneth Almquist
barmar@think.COM (Barry Margolin) (09/09/88)
In article <371@polyof.UUCP>, john@polyof.UUCP ( John Buck ) writes: > The other thing we did (for people who can't stand mixed input/output), is > to add an option to the tty line disc to not perform any output (ttwrite) > type calls to the terminal, if a line is in the middle of being typed. > (pos > 0). As soon as you hit a RETURN, the output that may have backed-up > is flushed. Multics has had an option like this since about 1973; it is called "polite" mode. However, it would not block the output forever -- if you start typing a line and then stop typing for something like 30 seconds, it will flush the pending output. It also has a "replay" mode to go with this. If you have polite mode off, or if the timeout I described above occurs, this mode causes the interrupted line to be re-echoed. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
mikep@ism780c.isc.com (Michael A. Petonic) (09/10/88)
In article <2816@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes: >In article <15410@ism780c.isc.com> mikep@ism780c.UUCP (Michael A. Petonic) writes: >: On BSD systems, there is a key (default ^O) that flushes the input >: queue. It is specified by: ``stty flush <char>''. Yes, it works if >: you have typed several lines ahead. > >That's odd, ^O certainly doesn't have that effect on my BSD system. It flushes >output, not input. Is your kernel hacked maybe? > >When I want flush all my input, I just do a ^Z and then "fg" or "bg". Quite correct. I'm sorry, grave mistake here.... Of course, it SHOULD flush input. Presumably, if you're going to discard output, there would be few cases if you had input queued up and fewer cases where you'd want that queued input read. -MikeP -- Michael A. Petonic mikep@ism780c.isc.com ``Have a heart... But don't take mine.''
bzs@encore.UUCP (Barry Shein) (09/11/88)
When TOPS-20 bit the dust we got a lot folks switching over to Unix and in doing so calling for more TOPS-20'ish features in Unix, things they sorely missed. Fortunately, a lot of those things went beyond simple matters of style and were often good suggestions (eg. PMAP), or at least apparently interesting (eg. STI.) Now we seem to have a migration from MS/DOS and VMS... Is there anything more interesting to suggest from those systems than "type behind"? (as I remember TOPS-20 did have both styles available as a "stty" [SET TERM] flag.) No, you're not getting all upper-case/mono-case everything, don't even ask, 026 punchcard support just isn't the wave of the future. (When in Rome do as the Romans do?) -Barry Shein, ||Encore|| I suppose in a another few years they'll be screaming for OS/2 features as that botch dies out (hmm, how about CMS? MVS?) P.S. Not a criticism, I always like to look at and hear about other systems for ideas (TOPS-20 really is/was fertile ground.) I just don't like to hear screaming that mere stylistic differences one has become accustomed to are "essential" or other hyperbole. Note that it wouldn't be that hard to emulate the stylistic features as a user application rather than make them part of the O/S, if you're certain they're so damned critical then consider it a business opportunity to sell an emulator (heh heh.)
daveb@geac.UUCP (David Collier-Brown) (09/12/88)
Gentlebeings, we may be wandering down the garden path here:
It is probably a bad idea to select **either** echo-on-entry or
echo-on-read behavior...
Being able to set the echoing behavior ("local echo") and
forwarding character(s) is a usefull facility of various network's
PADs (Packet Assempler-Disassemblers), and has been used to improve
the apparent response of distant machines over a network[1]. I
strongly suspect it can be used in a local environment for similar
purposes, having prototyped a field editor that did exactly that.
Remebering the commnet of the designers of Unix about having to
choose a single, simple way to do each seperate thing, I suspect
that they correctly chose to
1) echo on input, by default, and
2) allow one to change this behavior.
Since they did so, a given application (like the shell) can choose
to set the behavior however it likes: other applications (like an
editor) can change it to what they want when desirable.
So you pays your money and takes your choice.
--dave c-b
[1] printing characters are echoed immediatly and not forwarded
until timeout or entry of non-printing characters. Non-printing
characters are not echoed, but are forwarded along with the rest
of the packet to the host. See also Bernie Greenbergs' article
on Multics Emacs, which put this "negotiated echo" to good use.
--
David Collier-Brown. | yunexus!lethe!dave
78 Hillcrest Ave,. | He's so smart he's dumb.
Willowdale, Ontario. | --Joyce C-Bguy@gorodish.Sun.COM (Guy Harris) (09/14/88)
> Of course, it SHOULD flush input. Presumably, if you're going to discard > output, there would be few cases if you had input queued up and > fewer cases where you'd want that queued input read. Why should it flush input? As far as I know, it didn't do so in the DEC OSes from which it was derived; those times when I used ^O under RT-11 I never had any input queued so it wouldn't have made any difference whether it did or didn't, and not doing so is presumably simpler. (I don't know that I've ever used ^O under UNIX, except when testing tty drivers. There's a problem with it in UNIX that is less severe under the aforementioned DEC OSes: ^O was in the DEC OSes far enough back in history that applications that wanted to *force* messages to appear already did the magic special function to do so. However, it was grafted onto some versions of UNIX after the fact, so most applications that might want to force a message to appear don't know how to do so and, thus, don't do so.)
trb@haddock.ima.isc.com (Andrew Tannenbaum) (09/16/88)
In article <8458@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <1059@nmtsun.nmt.edu> warner@hydrovax.nmt.edu (M. Warner Losh) writes: >>With VMS you can do a ^X anytime the terminal is >>not in "raw" mode and clear the current type ahead buffer. How does one >>do this under unix? > >I don't know of any UNIX implementation that provides such a feature, >although it is doable and I've often wished I had it (its utility is >not limited to deferred-echo terminal handlers). The MASSCOMP tty system has these features, plus everything else that you would want in a UNIX-style tty handler. When I was working at MASSCOMP (until last 1985) our major thrust was the integration of features from 4BSD and System V. Steve Zimmermann took the System V termio structure and integrated the 4BSD functionality, plus a lot more. For example, there were separate keys for kill line and kill input buffer. There might have even been a way to retype the whole input buffer (like ^R). There was a full fledged tty --more-- processing mode, which included scroll and noscroll options. There was a status line (^T) that had about 30 option bits. You could find out how much system resources your current process was using, and you could find out the current program name, current system call (and whether it was complete). This came in really handy when your make bombed because some phase of the C compiler was busted - you just type make and then a bunch of ^T's, until it bombed. It also had DEC-style delayed echo of typeahead (as an option). It was source code compatible with both AT&T and BSD tty ioctl calls. It supported job control on both sides - in general, it had what I wanted. It was modular enough that we loaded the same code into the 68K-based tty mux board that we loaded into the kernel. Anyway, this is the tty system that MASSCOMP still distributes with its UNIX. I believe that the MASSCOMP man pages explain it fully. I wish it was the standard. Andrew Tannenbaum Interactive Boston, MA +1 617 247 1155 P.S. For you fans of goofy code, one of the funniest parts of the BSD tty.c was the code for figuring out the number of screen spaces used by a tab that you were backspacing over. The BSD code essentially does a ^O followed by a ^R (throwing away the output) to calculate the column, and then turns FLUSHO off. Steve rewrote this code to make backspacing over tabs a little more efficient and straightforward.
scs@athena.mit.edu (Steve Summit) (09/16/88)
In article <8458@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <1059@nmtsun.nmt.edu> warner@hydrovax.nmt.edu (M. Warner Losh) writes: >>With VMS you can do a ^X anytime the terminal is >>not in "raw" mode and clear the current type ahead buffer. >I don't know of any UNIX implementation that provides such a feature... Well, early versions of pdp11 Venix used control-E for this purpose. I haven't noticed (or missed) it recently... Steve Summit
pja@ralph.UUCP (Pete Alleman) (09/17/88)
In article <8458@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <1059@nmtsun.nmt.edu> warner@hydrovax.nmt.edu (M. Warner Losh) writes: >>With VMS you can do a ^X anytime the terminal is >>not in "raw" mode and clear the current type ahead buffer. How does one >I don't know of any UNIX implementation that provides such a feature, >although it is doable and I've often wished I had it (its utility is Venix/11 from VenturCom has this feature (^E flushes the input buffer). It's nice to have, but I don't really miss it that much when I use other versions of unix. I guess one need not flush the entire buffer very often when he can see what he is typing :-> -- Pete Alleman ralph!pja or digitran!pja
bitbug@vsi1 (James Buster) (09/21/88)
In the implementations I've seen, ^U (line kill) flushes the current type-ahead
buffer. Why do we need a new character for an already implemented feature?
--------------------------------------------
James Buster
Mad Hacker Extraordinaire
...!{ames,sun,decwrl}!vsi1!bitbug
vsi1!bitbug@ames.arc.nasa.gov
--------------------------------------------gwyn@smoke.ARPA (Doug Gwyn ) (09/21/88)
In article <1019@vsi1.UUCP> bitbug@vsi1 (James Buster) writes: >In the implementations I've seen, ^U (line kill) flushes the current >type-ahead buffer. (Assuming you've seen implementations like UNIX:) No it doesn't; it flushes the input line currently being canonicalized. Lines before the nearest preceding delimiter (newline or "EOF") have already been sent on to another queue and ^U doesn't affect them.