sjc@mips.UUCP (Steve "The" Correll) (10/16/87)
In article <682@its63b.ed.ac.uk>, adam@its63b.ed.ac.uk (ERCF02 Adam Hamilton) writes: > Several years ago when I first met UNIX, the UKUUG distribution had a terminal > driver which did the paging function. (I.e. no more than a screenful of output > without some terminal input, like a space). I too had the privilege once of working on a system (thanks to jdb at s1.mordor.gov) which provided an ioctl call to enable paging and specify the screen size. Despite all of the aesthetic arguments against putting this into the kernel, in practice it was just plain pleasant to use. -- ...decwrl!mips!sjc Steve Correll
nather@ut-sally.UUCP (Ed Nather) (10/17/87)
In article <796@quacky.UUCP>, sjc@mips.UUCP (Steve "The" Correll) writes: > In article <682@its63b.ed.ac.uk>, adam@its63b.ed.ac.uk (ERCF02 Adam Hamilton) writes: > > Several years ago when I first met UNIX, the UKUUG distribution had a terminal > > driver which did the paging function. (I.e. no more than a screenful of output > > without some terminal input, like a space). > > I too had the privilege once of working on a system (thanks to jdb at > s1.mordor.gov) which provided an ioctl call to enable paging and specify the > screen size. Despite all of the aesthetic arguments against putting this into > the kernel, in practice it was just plain pleasant to use. > Paging is such a simple chore it really doesn't take up much code space. In the design of PCnix, a Unix-like collection of software tools for IBM PCs, I wrote a short pager in C and included it in any program that sends output to the screen. MS-DOS has an IOCTL call that allows you to find out if the output has been redirected into a file or device -- in that case the screen pause is bypassed. It's so convenient and intuitive I regularly make mistakes on "real" Unix, and have to go back and pipe things through "more." -- Ed Nather Astronomy Dept, U of Texas @ Austin {allegra,ihnp4}!{noao,ut-sally}!utastro!nather nather@astro.AS.UTEXAS.EDU
steve@nuchat.UUCP (Steve Nuchia) (10/27/87)
In article <796@quacky.UUCP>, sjc@mips.UUCP (Steve "The" Correll) writes: > In article adam@its63b.ed.ac.uk (ERCF02 Adam Hamilton) writes: >> Several years ago when I first met UNIX, the UKUUG distribution had a >> terminal driver which did the paging function. (I.e. no more than a >> screenful of output without some terminal input, like a space). > I too had the privilege once of working on a system (thanks to jdb at > s1.mordor.gov) which provided an ioctl call to enable paging and specify the > screen size. Despite all of the aesthetic arguments against putting this into > the kernel, in practice it was just plain pleasant to use. The default configuration of OS/9 for serial terminals pauses. It is a royal pain in the %^&((*&, especially since OS/9 commands tend to be of the old fashioned verbose "announce every move" kind. There is no describing the feeling of coming back from a meeting or extended coffee expedition to find that the compile you fired off half an hour ago only got through the first screenful of compiler version number announcements. GRRRR! Of course one develops ways of coping with this, just as one develops a Ctl-S reflex on some systems. The guys I worked with who spent more time on OS/9 would always follow a command like a compile with "several" returns, for instance. I just think that it is overall not an unalloyed win to have the driver do the pausing. -- Steve Nuchia | [...] but the machine would probably be allowed no mercy. uunet!nuchat!steve | In other words then, if a machine is expected to be (713) 334 6720 | infallible, it cannot be intelligent. - Alan Turing, 1947
peter@sugar.UUCP (Peter da Silva) (10/27/87)
TOPS-20 did all sorts of stuff in the terminal driver. Paging, cursor control, the whole schmeer. Of course, they also had a seperate CPU for the ttys. I found it a pain, particularly when I wanted to do my own cursor control from APL for a terminal it didn't have data on. Even just paging can bite you when you're doing stuff like that. Hell, has anyone tried using vi with software tabs set on lately? -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
crowl@cs.rochester.edu (Lawrence Crowl) (10/27/87)
In article <421@nuchat.UUCP> steve@nuchat.UUCP (Steve Nuchia) writes: [Is screen paging embedded in the terminal driver good?] >There is no describing the feeling of coming back from a meeting or extended >coffee expedition to find that the compile you fired off half an hour ago only >got through the first screenful of compiler version number announcements. >GRRRR! This is easily fixed by sending the program output to a file and then having the terminal driver display the file. This approach provides both paging and long untended output. The shell could provide this transparently. The disadvantages are that one is spending more time doing file i/o, and that nearly full file systems will fill up. These are costs worth paying. -- Lawrence Crowl 716-275-9499 University of Rochester crowl@cs.rochester.edu Computer Science Department ...!{allegra,decvax,rutgers}!rochester!crowl Rochester, New York, 14627
jejones@mcrware.UUCP (James Jones) (10/27/87)
<insert your favorite disclaimer here> In article <421@nuchat.UUCP>, steve@nuchat.UUCP (Steve Nuchia) writes: > The default configuration of OS/9 for serial terminals pauses. It > is a royal pain in the %^&((*&, especially since OS/9 commands tend to > be of the old fashioned verbose "announce every move" kind. > ... > There is no describing the feeling of coming back from a meeting > or extended coffee expedition to find that the compile you fired > off half an hour ago only got through the first screenful of > compiler version number announcements. GRRRR! I'm not sure why this is in comp.arch, but to correct possible misconceptions: Device descriptors for SCF devices (i.e. those controlled by the Sequential Character file manager) under OS-9 have two fields important to this discussion; one tells whether to pause after a certain number of lines goes by, and the other contains the "certain number." I've not stared in detail at how SCF decides about this, but it is smart enough that if you sit and type CR at the shell, it does not pause after the nth CR--the only gripe I personally have about it is that it doesn't notice when a line wraps around, so that you can lose stuff off the top sometimes. One can tweak these settings either by modifying the device descriptor module or by means of either of two utilities, tmode and xmode. (Tmode affects the path descriptor, which contains a copy of the salient piece of the device descriptor, while xmode mungs the loaded device descriptor module.) Indeed, one could put "tmode .2 nopause" in one's .login file if one is using the OS-9/68000 shell (.2 says "mung path #2", needed for the .login file since .0, the default, would be the .login file--not what one wants to mess with). There's also something to be said for the "-q" option on cc. James Jones
mikew@wyse1.wyse.com (Mike Wexler) (10/27/87)
In article <421@nuchat.UUCP> steve@nuchat.UUCP (Steve Nuchia) writes: >In article <796@quacky.UUCP>, sjc@mips.UUCP (Steve "The" Correll) writes: > >The default configuration of OS/9 for serial terminals pauses. It >is a royal pain in the %^&((*&, especially since OS/9 commands tend to >be of the old fashioned verbose "announce every move" kind. >... The solution to this is to be able to toggle the feature. If you have a command that turns it off that should be suitable for the situation where you are doing batch. I use X Windows now, and one of the things I miss is its page mode. You could select whether you wanted it to be default to Page Mode and pop up a menu a change it whenever you wanted to. When you switched the terminal into raw or cbreak mode it would automatically be turned off.
earl@mips.UUCP (Earl Killian) (10/27/87)
In article <421@nuchat.UUCP>, steve@nuchat.UUCP (Steve Nuchia) writes: > The default configuration of OS/9 for serial terminals pauses. It > is a royal pain in the %^&((*&, especially since OS/9 commands tend to > be of the old fashioned verbose "announce every move" kind. It may be that OS/9 doesn't do output pagination as well as other implementations do it, and therefore it was indeed a pain. The ITS operating system did this and it worked fairly well. For example, input resets the line counter, so that it takes a pageful of output after issuing a command before stopping. ITS also disables pausing if there is typeahead, which solves other problems. And it was very easy to turn on and off on the fly. Also, it was possible for a program to enable an interrupt (i.e. signal in the Unix world) so that it could do its own "more" processing when the time to stop arrived. And of course automatic output pagination must be an option. If you still don't like it, don't turn it on (or turn it off if it's the default). But let the people that like it have it. Unix borrowed many things from the ITS operating system (e.g. job control and symbolic links (ITS probably got symbolic links from Multics)). It's too bad Unix didn't borrow the ITS terminal system as well; it would have been a significant improvement because Unix still has one of the most primitive terminal interfaces I've seen. Fortunately, window systems will probably finally pull Unix out of the dark ages wrt terminals. At least I hope so.
guy%gorodish@Sun.COM (Guy Harris) (10/28/87)
> This is easily fixed by sending the program output to a file and then having > the terminal driver display the file. This approach provides both paging > and long untended output. And, if you use an editor on the file, provides the ability to move forward and backward through the output, with searching (assuming you have a reasonable editor). > The shell could provide this transparently. As can some editors. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
firth@sei.cmu.edu.UUCP (10/28/87)
For what it's worth, here's what we did in IAS on the PDP-11. (Well,
my good friend and systems person Alan Stout wrote the code, but I
contributed the low cunning.)
Paging was indeed done in the terminal driver; after 20 lines (or
whatever) it stopped until you typed ^Q. The frills were what made
it work:
(a) we reset the count whenever a new program attached to the terminal.
so you didn't get any hangups in normal user dialogue
(b) we reset the count at ^S, so the DEC "standard" ^S/^Q protocol could
still be used, and you always got a full page after ^Q
(c) we ignored the count if there was anything in the typeahead buffer,
on the principle that a user who had typed the next command didn't
really care what the current program was saying. So you could go
type a single space and go for coffee (and even erase the space when
you got back)
The result was far more satisfied users than dissatisfied ones.mjr@osiris.UUCP (10/28/87)
ENOUGH ! Why not build 'vi' or GNUemacs into the file system, too ? Remember, guys ? Keep it simple. Keep it modular ? There used to be some silly operating system or another designed along those lines. --mjr(); -- "We're fantastically incredibly sorry for all these extremely unreasonable things we did. I can only plead that my simple, barely-sentient friend and myself are underpriviledged, deprived and also college students." - Waldo "D.R." Dobbs.
dhesi@bsu-cs.UUCP (Rahul Dhesi) (10/29/87)
In article <3018@aw.sei.cmu.edu> firth@bd.sei.cmu.edu.UUCP (Robert Firth) writes about paging screen output: >(c) we ignored the count if there was anything in the typeahead buffer, > on the principle that a user who had typed the next command didn't > really care what the current program was saying. Bill Gates will love you. His MS-DOS operating system goes one step further: If there's a character in the typeahead buffer, the terminal driver completely ignores ^S. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
simon@its63b.ed.ac.uk (Simon Brown) (10/29/87)
In article <3619@sol.ARPA> crowl@cs.rochester.edu (Lawrence Crowl) writes: >In article <421@nuchat.UUCP> steve@nuchat.UUCP (Steve Nuchia) writes: >[Is screen paging embedded in the terminal driver good?] > >This is easily fixed by sending the program output to a file and then having >the terminal driver display the file. This approach provides both paging and >long untended output. The shell could provide this transparently. >The disadvantages are that one is spending more time doing file i/o, and that >nearly full file systems will fill up. These are costs worth paying. The only way in which this could be done semi-transparently would be for the shell to redirect output from each command executed into a pseudo-terminal (a different one for each command), with a master-end acting as a pager. Unfortunately, it isn't (so far as I know) possible to detect tty-mode changes over a pty, which means that the paging could *not* be automatically disabled if the command puts the terminal (ie, the slave end of the pty) into raw or cbreak mode, which wouldn't be the best at all. Also, the input would have to go through the pty as well, so that the paging could be re-initialized (ie, start a new virtual page) whenever input is read - output-only paging is not the way to go! Of course, this would mean that the file i/o would really be pty i/o, so it wouldn't be too slow, and the file-system wouldn't be involved - all the data would stay in the tty buffer space. A paging streams-module sounds a *much* cleaner way of doing it - pty's just aren't sophisticated enough. -- ---------------------------------- | Simon Brown | UUCP: seismo!mcvax!ukc!{lfcs,its63b}!simon | LFCS | JANET: simon@uk.ac.ed.{lfcs,its63b} | Department of Computer Science | ARPA: simon%lfcs.ed.ac.uk@cs.ucl.ac.uk | University of Edinburgh, | or simon%its63b.ed.ac.uk@cs.ucl.ac.uk | Scotland, UK. | or simon%cstvax.ed.ac.uk@cs.ucl.ac.uk ---------------------------------- "Life's like that, you know"
ron@topaz.rutgers.edu.UUCP (10/29/87)
The seperate CPU did little to offload work from the main CPU. The main reasdon it was there was so DEC didn't have to make special TOPS-20 tty cards. They just used the 11/40's UNIBUS. The machine still passed the characters to the main CPU one at a time, interrupting on each one. It's other big job in life is to print "%DECSYSTEM-20 NOT RUNNING" when the machine is down.
earl@mips.UUCP (Earl Killian) (10/30/87)
In article <1444@osiris.UUCP>, mjr@osiris.UUCP (Marcus J. Ranum) writes: > ENOUGH ! > > Why not build 'vi' or GNUemacs into the file system, too ? > > Remember, guys ? Keep it simple. Keep it modular ? There used to be > some silly operating system or another designed along those lines. And don't forget to keep it useless too.
henry@utzoo.UUCP (Henry Spencer) (10/30/87)
> >... the feeling of coming back from a meeting or extended coffee > > expedition to find that the compile you fired off half an hour ago only > >got through the first screenful of compiler version number announcements. > > This is easily fixed by sending the program output to a file and then having > the terminal driver display the file... There is a simpler and better fix. Any built-in terminal pager should have a magic character (we use control-T for obscure reasons) that says "disable paging until next input". Then you just start your long-running process, hit the paging-off character, and depart. And when you come back and start work again, paging turns back on automatically. This probably belongs somewhere other than comp.arch. comp.os.misc? -- PS/2: Yesterday's hardware today. | Henry Spencer @ U of Toronto Zoology OS/2: Yesterday's software tomorrow. | {allegra,ihnp4,decvax,utai}!utzoo!henry
jdb@mordor.s1.gov (John Bruner) (10/31/87)
When the subject of terminal output paging came up in "net.unix-wizards" a while back, Dennis Ritchie commented that PDP-7 UNIX did provide autopaging (eliminating an appeal to an historical precedent against automatic output pagination). As far as simplicity goes, UNIX terminal drivers are one of the messiest, most kludged-up pieces of code that I've seen. The BSD driver is particularly nauseating; the interface to it is far from clean and simple (e.g. how many ioctl's does it take to initialize a terminal's state?). One can still see the V6 driver hiding under V7 extensions plus nifty CRT-oriented editing extensions plus job control extensions plus .... In the light of all of this, I have difficulty accepting the argument that autopaging does not belong in the kernel for reasons of simplicity and elegance. The right solution is to toss out all of this garbage and use streams, so that users who want autopaging can push a paging filter onto their terminal output stream. I wish I had a V8 (or V9).... -- John Bruner (S-1 Project, Lawrence Livermore National Laboratory) jdb@mordor.s1.gov ...!seismo!mordor!jdb (415) 423-4848
henry@utzoo.UUCP (Henry Spencer) (11/01/87)
> Remember, guys ? Keep it simple. Keep it modular ? There used to be > some silly operating system or another designed along those lines. And if you look at even the earliest versions of said operating system, you'll find interesting code in the tty driver which essentially provides a complete virtual-terminal system for hardcopy terminals popular at Bell Labs circa 1975. (For those who haven't yet caught on, study things like the definitions of some of the delay settings.) Adding pagination is a (minimal) attempt at updating this to better match more modern terminals. The theoretical objections (which do have some merit) rapidly fall by the wayside when you try the idea for a while. This job really ought to be done by the terminal, but the kernel is the closest we can come to that with existing (cheap) hardware. -- PS/2: Yesterday's hardware today. | Henry Spencer @ U of Toronto Zoology OS/2: Yesterday's software tomorrow. | {allegra,ihnp4,decvax,utai}!utzoo!henry
daveb@geac.UUCP (11/02/87)
In article <843@gumby.UUCP> earl@mips.UUCP (Earl Killian) writes: | The ITS operating system did this and it worked fairly well... | | Unix borrowed many things from the ITS operating system (e.g. job | control and symbolic links (ITS probably got symbolic links from | Multics)). It's too bad Unix didn't borrow the ITS terminal system as | well; it would have been a significant improvement because Unix still | has one of the most primitive terminal interfaces I've seen. Could you comment a bit more on what ITS did? I've seen a brief discussion (in Brenie Greenberg's Emacs paper), but admit near-total ignornace of what it was like... -- David Collier-Brown. {mnetor|yetti|utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.
news@mfci.UUCP (Usenet) (11/03/87)
In article <16089@topaz.rutgers.edu> ron@topaz.rutgers.edu (Ron Natalie) writes: >The seperate CPU did little to offload work from the main CPU. >The main reasdon it was there was so DEC didn't have to make >special TOPS-20 tty cards. They just used the 11/40's UNIBUS. >The machine still passed the characters to the main CPU one at >a time, interrupting on each one. It's other big job in life >is to print "%DECSYSTEM-20 NOT RUNNING" when the machine is down. RSX20F did NOT interrupt the CPU on each character: it dropped each character into a circular queue in -20 memory, with no interrupts, and the -20 would scan the input queue every 20 milliseconds or so. No interrupts needed. Didn't want history to get rewritten.
rogerh@arizona.UUCP (11/05/87)
Nobody has mentioned yet that Sun's terminal emulator windows both provide this -- the vanilla one by stalling output when a page has gone by with no reads requested (this is switchable, default off); the editing one by having a scrollbar and saving text off the top. Roger Hayes, rogerh@arizona.edu
smith@COS.COM (Steve Smith) (11/06/87)
One of the nastiest kludges that I have ever been involved with was
caused by a "smart" terminal driver that did all kinds of tricks. The
system had a PDP 11/23 running RT11 and an HP 2626A "smart" terminal.
The idea was to "draw" forms on the terminal in local mode and then dump
them to the computer as a block transfer.
Ideally, the computer would be running "PIP filename=TT:" (for you UNIX
types, "cat >filename"). Enter the "smart" terminal driver. It uses
all sorts of control characters for its own purposes. Naturally, there
was an overlap with the characters that the terminal used. The killer
was control-O, which is "discard output" on RT11 and "turn off graphics
character set" on the 2626A. Needless to say, there was no way of
turning off the "discard" function, because it was wired into the
driver.
What should have been a one liner turned into about 2.5 pages of
spectacularly obscure PASCAL, using system calls that even the RT11
gurus had never seen before...
The moral is obvious. Drivers, as part of the operating system, should
be as clean, simple and general purpose as possible. If you want
something fancy, do it as an add-on THAT CAN BE REMOVED.
I've never had any heartburn appending "| more" to a command.
--
__
-- Steve / / \ / "Truth is stranger than
S. G. Smith I \ O | _ O \ I fiction because fiction
smith@cos.com / \__/ / has to make sense."rpw3@amdcad.AMD.COM (rpw3) (11/07/87)
In article <918@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >TOPS-20 did all sorts of stuff in the terminal driver. Paging, cursor control, >the whole schmeer. Of course, they also had a seperate CPU for the ttys... Yes, they did, but that separate CPU (a PDP-11/40) did NOTHING but emulate an expensive DZ-11 (at least, for local lines). It had a big, fancy, expensive DMA interface to the PDP-10, but a communications front-end made by a third party vendor I worked for (DCA) used a lowly DEC PDP-8 and a simple interrupt- per-character interface (DA10, sort of a "36-bit DR11C"), and got *much* higher throughputs than the official DEC front-end. In any case, all of that "stuff in the terminal driver" was in the terminal driver! ...which was in the PDP-10, not in the front-end. Rob Warnock Systems Architecture Consultant UUCP: {amdcad,fortune,sun,attmail}!redwood!rpw3 ATTmail: !rpw3 DDD: (415)572-2607 USPS: 627 26th Ave, San Mateo, CA 94403