rfm@frog.UUCP (Bob Mabee) (08/22/85)
{}
(referring to novice and expert users of ls)
> From *both* viewpoints, it is simpler to have pagination available in the
> tty driver. This means that the implementors don't have to kludge it into
> every program, and the users need neither lightning reflexes nor high
> sophistication. Try it, you'll like it.
> --
> Henry Spencer @ U of Toronto Zoology
This sounds like a fruitful topic of discussion. I would like to see this
become a "standard extension" like file locking.
Please tell us more about your user interface. Do you require a Y every
23 lines of output? Only after 23 lines without intervening input (so
you never notice pagination while running less verbose commands?
What are the drawbacks? Do "portable" UNIX programs have to be modified
to disable pagination for editing, communications, etc? Does the TTY
driver have to decode cursor motion sequences (as Multics did)?
--
Bob Mabee @ Charles River Data Systems
decvax!frog!rfmhahn@AMES-NAS.ARPA (Jonathan Hahn) (08/23/85)
I cringed when I came across the first reference to tty pagination at the driver level (actually, I think the first reference was intended to be sarcastic), but then I recalled an implementation I encountered that was somewhat respectable: When pagination mode is turned on, the tty driver will suspend output (a la canonical ^S) after it sends 23 <CR><LF>s to the terminal. As long as pagination mode is no, pagination repeats after output is resumed. ^S turns pagination mode on and suspends output ^Q turns pagination mode off and resumes output When pagination is on, <BREAK> requests a new page/resumes output (these days this might upset some terminal servers). I don't recall specifically, but I suspect that terminal input would reset top-of-page so interactive terminal dialog wouldn't be bothered with pagination. This was implemented at Ampex Corp. on V7 and is on an old Usenix distribution tape (<=1981, meeting location = Boulder, CO). -jonathan hahn hahn@ames-nas.arpa ...!ucbvax!atd!avsdT:jon (I don't think this works. Aside: can the ':' be quoted so mailers don't change it to a '.'?)
jack@boring.UUCP (08/24/85)
I implemented a kernel paginator in V7, which was about half an hour work. It's invoked with the cr3 delay, and works only if the terminal is in normal (cooked) mode. It halts after 23 lines of output with no intervening input, and is restarted by a <CR>. Also, you can type ^Q, which will turn the paginator off, until the next time input is requested. If someone wants the code, drop me a line at jack@htsa.UUCP. -- Jack Jansen, jack@mcvax.UUCP The shell is my oyster.
dan@rna.UUCP (Dan Ts'o) (08/25/85)
In article <280@frog.UUCP> rfm@frog.UUCP (Bob Mabee) writes: >{} >(referring to novice and expert users of ls) >> From *both* viewpoints, it is simpler to have pagination available in the >> tty driver. This means that the implementors don't have to kludge it into >> every program, and the users need neither lightning reflexes nor high >> sophistication. Try it, you'll like it. >> -- >> Henry Spencer @ U of Toronto Zoology > >This sounds like a fruitful topic of discussion. I would like to see this >become a "standard extension" like file locking. > >Please tell us more about your user interface. Do you require a Y every >23 lines of output? Only after 23 lines without intervening input (so >you never notice pagination while running less verbose commands? Also: What about terminals that don't have 24 lines ? Some have 16 and some have 66 ? Do you have yet another ioctl() ? What happen when you print lines that wrap around the screen ? Does the kernel know how to count character spacing, know the screen width, whether the terminal has AM and XN and account for it when making page breaks ? The better pagers allow reverse and forward viewing. I find this capability indispensible. Do you plan to add a buffer in the kernel to allow reviewing of previous lines ? Does your implementation handle well situations where the application is sending more than 24 lines but since it is using cursor addressing, it is self consistent ? Does your kernel recognize cursor motion sequences or do you have to turn off paging every time you run such an application ? (e.g. graphics, some screen editors) Maybe you expect such applications to run in RAW or CBREAK and don't do paging in those modes, or maybe you expect such applications to shut off paging themselves. Yes, I know paging works fine for many situations. Cheers, Dan Ts'o Dept. Neurobiology Rockefeller Univ. 1230 York Ave. NY, NY 10021 212-570-7671 ...cmcl2!rna!dan rna!dan@cmcl2.arpa
henry@utzoo.UUCP (Henry Spencer) (08/27/85)
This article is a collection of replies to several comments on in-kernel tty paging. > You mean like on TOPS-20? Where it seems the tty drivers use TERMCAP or an > equivalent (if you type more than 1 line & hit ^U it cursors to the beginning > of the input line (maybe several terminal lines above) and sends a CL sequence! Interesting, but it has nothing to do with output pagination. > Please tell us more about your user interface. Do you require a Y every > 23 lines of output? Only after 23 lines without intervening input (so > you never notice pagination while running less verbose commands? Glossing over a few fine points, any time 22 lines of output are seen without any intervening input, the tty driver stops and waits for a RETURN. (Actually any input character will do, but RETURN arriving while the tty is in a paging wait cancels the wait and disappears, while anything else cancels the wait and sticks around.) No, the "22" is not burned into the kernel, it is set by an ioctl, generally to a number ultimately derived from termcap. > What are the drawbacks? The only significant thing we've found is that it's hard to get line-wrap handling 100% right. > Do "portable" UNIX programs have to be modified > to disable pagination for editing, communications, etc? No, switching to CBREAK or RAW mode turns it off implicitly. The only things we have modified (except our kernel) are stty to know about the paging ioctl, getty's terminal initialization to set the defaults right (from termcap, by the way), and our local pager program "p" to exploit kernel paging if it's on. Nothing else. > Does the TTY > driver have to decode cursor motion sequences (as Multics did)? No. > [a similar scheme...] > ^S turns pagination mode on and suspends output > ^Q turns pagination mode off and resumes output Wrong choice of control characters. Nowadays one must assume that ^S and ^Q are strictly, completely, and entirely reserved for flow control between the terminal and the host. We had a bug in this in our early versions, in fact. One thing which we do find valuable is a control character (settable via the paging ioctls, default ^T) which turns paging off until the next input character. This lets you disable paging temporarily for something like verbose program output that you don't want to see in detail. The ability to do this conveniently is important. > The > advantage of not having pagination in the kernel is the ability to have > tailored paginators. Agreed. But for most people, a poor pager that's built in generally beats a wonderful pager that always has to be invoked explicitly. I dislike building things like this into the kernel; there really ought to be some way to run all one's terminal i/o through a central agent without having to build the agent into the kernel. Doing that efficiently isn't simple. We decided that an ugly implementation now beat a clean one five years down the road. We were right. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
henry@utzoo.UUCP (Henry Spencer) (08/27/85)
> What about terminals that don't have 24 lines ? Some have > 16 and some have 66 ? Do you have yet another ioctl() ? The size is of course set by ioctl, since no way would we consider imbedding something like that into the kernel. > What happen when you print lines that wrap around the screen ? > Does the kernel know how to count character spacing, know the screen width, > whether the terminal has AM and XN and account for it when making page breaks ? This is somewhat of a headache. The kernel is *already* counting character spacing, please note, so that's not an issue. It gets it right for the simple cases, and most non-simple cases want to use CBREAK mode anyway. The ioctl includes an indication of screen width. The AM/XN mess is not yet fully accounted for, although there's nothing impossible about doing so. (Before people start moaning about how unUnixish it is to put such things into the kernel, check out the definition of newline delay type 1. Such details of terminal handling have a long history of being in the kernel!) > The better pagers allow reverse and forward viewing. I find > this capability indispensible. Do you plan to add a buffer in the kernel to > allow reviewing of previous lines ? This, we have not done; it would be a major added complication. We find the in-kernel pager very useful without it. We agree that the in-kernel pager is not the answer to all mankind's problems, or even all Unix's pagination problems. We are not convinced that "more" and its kin do in fact represent such an answer, either! > Does your implementation handle well situations where the > application is sending more than 24 lines but since it is using cursor > addressing, it is self consistent ? Does your kernel recognize cursor motion > sequences or do you have to turn off paging every time you run such an > application ? (e.g. graphics, some screen editors) Maybe you expect such > applications to run in RAW or CBREAK and don't do paging in those modes, or > maybe you expect such applications to shut off paging themselves. Our experience has been that such applications invariably run in CBREAK or RAW; paging is applicable only to COOKED mode. This was a slightly ad-hoc decision that has worked very well in practice. We are opposed on principle to having an unbounded number of programs know about paging. > Yes, I know paging works fine for many situations. That it does. We do still have explicit pager programs, but they get far less use nowadays. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
tim@cithep.UucP (Tim Smith ) (09/01/85)
>> The better pagers allow reverse and forward viewing. I find >> this capability indispensible. Do you plan to add a buffer in the kernel to >> allow reviewing of previous lines ? > > This, we have not done; it would be a major added complication. We find > the in-kernel pager very useful without it. We agree that the in-kernel > pager is not the answer to all mankind's problems, or even all Unix's > pagination problems. We are not convinced that "more" and its kin do in > fact represent such an answer, either! Time for a third point of view here. Pagination belongs in the terminal! Note that the terminal already knows how many lines long the screen is. It also knows what happens at the last column. It alread knows about escape sequences recognized by itself, so it can deal with cursor addressing programs. And with what RAM prices have been doing, it is not unreasonable for a terminal to have lots of memory, so you can back up. Besides, in the future, I think most "terminals" will be personal computers running terminal emulator programs. While I'm at it, the terminal is also where history belongs... -- unlk a6 rts Tim Smith ihnp4!{wlbr!callan,cithep}!tim
andrew@stc.UUCP (Andrew Macpherson) (09/04/85)
>> From *both* viewpoints, it is simpler to have pagination available in the >> tty driver. ...... Try it, you'll like it. >> -- >> Henry Spencer @ U of Toronto Zoology > >What are the drawbacks? Do "portable" UNIX programs have to be modified >to disable pagination for editing, communications, etc? >-- > Bob Mabee @ Charles River Data Systems We have such a tty driver on an 11/34 running Xenix 2.?. In 'normal' use with keyboard input, one does not see the paginator, only when a program is producing reams of output. It was a pain in the neck to find a process blocking on tty output when one didn't want the paginator, and supreme relief when one realised that one had forgotten >more|less<. The problem is, that version of Xenix does not have Berkley job control. The times I've wanted to.. ^Z Stopped. % stty length={0|24} % fg to turn off or on the pager for a command started with the terminal in the wrong mode. Conclusion, on balance quite nice, ( yes, I damn it with faint praise ). I might consider it excellent if I had had job control with it, and the above sequence worked. -- Regards, Andrew Macpherson. <andrew@stc.UUCP> {creed, datlog, idec, iclbra, iclkid, root44, stl, ukc}!stc!andrew
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (09/05/85)
> Pagination belongs in the terminal! > While I'm at it, the terminal is also where history belongs... Hear, hear! Please enter my order for one stream I/O system with downloadable DMD terminal driver. Or isn't it available yet?
zben@umd5.UUCP (09/06/85)
In article <124@cithep.UucP> tim@cithep.UucP (Tim Smith ) writes: >Time for a third point of view here. Pagination belongs in the terminal! >Note that the terminal already knows how many lines long the screen is. It >also knows what happens at the last column. It alread knows about escape >sequences recognized by itself, so it can deal with cursor addressing >programs. > >And with what RAM prices have been doing, it is not unreasonable for a >terminal to have lots of memory, so you can back up. Besides, in the >future, I think most "terminals" will be personal computers running >terminal emulator programs. > >While I'm at it, the terminal is also where history belongs... I agree with the thrust of the arguments. The latest complaint of my boss is that his Zenith PC with Ethernet interface can dump stuff to the screen faster than it can be read (by several orders of magnitude, probably). After having talked him OUT of modifying every program in creation to meter its output, and having convinced him that the place to solve the problem is in the micro, your argument looks very good. Most clones have oodles of memory to spare when running terminal simulators. Why not just accept the hundred thousand bytes into memory directly, then either scroll them onto the screen with keyboard control, or let the user page the screen up and down in the circular buffer with the last 250,000 bytes received. But, consider the difficulties of doing paging and history in the terminal if a window environment is used. You probably want to have N history streams, at least one for each window running the shell, probably one for each window in general. The paging would also have to know which window is filling up, and how big it is. While one COULD extract this information from the cursor addressing sequences on the fly, the principle-of-least-messiness requires us to at least look at other solutions. So, do all the window stuff in the terminal! Tag output on the host-micro link with which window it is destined for, and let software in the micro do the actual screen management. Since it knows which window the output is for, it can do the MORE? stuff easily enough. It could probably know enough about where you are on the screen to determine which window you are typing into, and know which history stack to pull from, push to, and use the same information to tag incoming lines so the software on the host knows which of the processes to which to deliver the input. I dunno, just random thoughts. I mean, I use a Volker Craig in ADM3 mode. This window stuff is still hypothetical here... -- Ben Cranston ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben zben@umd2.ARPA
henry@utzoo.UUCP (Henry Spencer) (09/06/85)
> At caltech we have a network that lives between most computers and > most terminals, now unfortunately the network uses ^S/^Q (of course) > and any ^S, ^Q you type on your terminal will go to the network > not to the computer. So putting pagination in the tty driver > really confuses novice users, the documentation says that pressing > ^Q gets things started again, but it doesn't... As has already been pointed out, using ^Q to restart paging is a terrible mistake because it is increasingly necessary to reserve ^S^Q exclusively for low-level flow control. Don't confuse this implementation mistake with a general problem with the concept. > Time for a third point of view here. Pagination belongs in the terminal! > ...[the terminal knows best what is happening on its screen]... > While I'm at it, the terminal is also where history belongs... This is 100% correct. But if one does not have such terminals, that is not cause to give up in despair. > We have such a tty driver on an 11/34 running Xenix 2.?. In 'normal' use > with keyboard input, one does not see the paginator, only when a program > is producing reams of output. It was a pain in the neck to find a process > blocking on tty output when one didn't want the paginator... > The problem is, that version of Xenix does not have Berkley job control. > The times I've wanted to.. [use job control to turn paging off/on for a > particular already-started process] I'm not sure whether I mentioned this earlier: it is *important* to have a clean and simple way of turning paging off temporarily, to solve this exact problem. Having a single special character that turns paging off until the next input character works wonderfully well -- you can turn the paging off for a ream of output, and it turns itself back on automatically. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
gww@aphasia.UUCP (George Williams) (09/11/85)
> > At caltech we have a network that lives between most computers and > > most terminals, now unfortunately the network uses ^S/^Q (of course) > > and any ^S, ^Q you type on your terminal will go to the network > > not to the computer. So putting pagination in the tty driver > > really confuses novice users, the documentation says that pressing > > ^Q gets things started again, but it doesn't... > > As has already been pointed out, using ^Q to restart paging is a terrible > mistake because it is increasingly necessary to reserve ^S^Q exclusively > for low-level flow control. Don't confuse this implementation mistake with > a general problem with the concept. Actually I rather like pagenators, I was just objecting to the use of ^Q to start them up again. I also object to people's suggestion that a space be used and then vanish; I have a strong believe that non-control characters should hang around (control characters are designed to control things, other characters are designed as text). Not even the bsd terminal driver uses all the control chars, there are still plenty left. Of course the best thing to do is to have the magic character that restarts output to be set by an ioctl, but its default should be neither ^Q nor space. I also don't understand why some people have their paginators turned off by input; I like typeahead but I don't always want it to turn off my output control. It seems to me that having yet another magic character to turn off pagenation would be preferable. Since I seem to be on the subject of magic characters, I have always liked dec's ^T that generates a line with some status info on it. I have seen this implemented on one unix system (cithep) rather well; where ^T (setable with an ioctl of course) generated a signal that was normally ignored, but if a program wanted to, it could be used. This character did not flush either the input or output buffer.
peter@graffiti.UUCP (Peter da Silva) (09/16/85)
> While I'm at it, the terminal is also where history belongs...
And savehist as well? Naw... history does all sorts of things you can't do
in a terminal program... but you did just give me a great idea for mine...rartym@cybavax.UUCP (Richard Artym) (09/16/85)
[Munch.] Goodness! All this time you poor souls have been using tty handlers without built-in pagination? We've had a paginating handler on our PDP-11 since V6 days, and the current V7 also has it. Alas, our Codata's Uniplus V7 doesn't, nor of course does our VAX's BSD4.2, and as a result I find it quite exasperating to use these supposedly "better" machines rather than the old PDP. I strongly support henry@utzoo's words on this topic, and would add that paging utilities like 'more' should really be viewed as a terrible kludge. In the Unix way of working, nearly all the output arriving at the vdu is useful information meant for reading, in contrast to the old-fashioned methods which produced huge reams of output with very little content meant for human consumption. (If you don't recognize this, you haven't discovered pipes and filters!) To have correctly generated the desired output only to find that it scrolls off the page because the eye can't keep up with the computer is ridiculous in my opinion; since this is the normal state of affairs, the solution should be provided by default. Where and how it's implemented is a separate issue, although most will agree that for efficiency and simplicity the best place to put the code is in the tty handler. (In our handler, ^P allows you to toggle the pagination on and off on the fly, it's automatically reset on receiving a CR or NL as input, and it can be turned off altogether with "stty page 0".) I'm perplexed as to why AT&T and Berkeley never picked up on this approach, which was widely used here in Europe (EUUG V7 I think). A paginating tty handler improves overall ease of use dramatically, without any exaggeration. -- vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv > Rich Artym, Elec.Eng., Univ.College of Swansea, Swansea SA2 8PP, Wales, UK. < > UUCP : {UK}!ukc!reading!cybavax!rartym ; JANET : rartym@swxa/000060601800 < ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
tim@cithep.UucP (Tim Smith ) (09/21/85)
Actually, UNIX has a way of preventing text from scrolling by so fast that you can't read it ( or reach ^S before it goes by ). There is a scroll rate parameter setable vis stty. I am sure most UNIXs have it. Just do a stty followed by a number indicating the desired scroll rate. Higher numbers are faster ( note: not all numbers are available - check your manual ). For example, a "stty 300" will set the scroll rate to 1/32 of what most people have it set at. If you are real slow, try "stty 75". Oh, you may have to adjust some switches on your terminal. Good luck! -- Tim Smith ihnp4!cithep!tim
snoopy@ecrcvax.UUCP (Sebastian Schmitz) (09/23/85)
Summary: Expires: References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp> <5937@utzoo.UUCP> <cybavax.147> Sender: Reply-To: snoopy@ecrcvax.UUCP (Sebastian Schmitz) Followup-To: net.unix-wizards Distribution: Organization: European Computer-Industry Research Centre, Munchen, W. Germany Keywords: I hate to tell you all this, but the lads at Queen Mary College Computer Science have had a paginating tty driver for YEARS (and they also do same with 4.2). It works very nicely (no more 'more's and 'page's...) If you ask me nicely I will forward you their net address so that you can ask them for it. I don't have it handy at the moment. -- Love, Sebastian (Snoopy) "You haven't done it, till you've done it with pointers" \!mcvax\!unido\!ecrcvax\!snoopy /* N.B. valid csh address */
whb@vax135.UUCP (Wilson H. Bent) (09/25/85)
Ah, but if the terminal does the history, etc, does it store it when powered down? I use a tty5620dmd/blit (the longest-named terminal in the world!), which is very smart and has very smart software already written, but no memory other than baud rate, etc. There are several examples of history use which extend from one day to the next - I guess any complicated ones could be made into shell scripts, but that's not the point. UN*X remembers, so my terminal doesn't have to. And that's why I can also use an ADM-3A. Wilson H. Bent, Jr. ... ihnp4!vax135!hoh-2!whb AT&T - Bell Laboratories (201) 949-1277 Disclaimer: My company has not authorized me to issue a disclaimer.
putnam@steinmetz.UUCP (jefu) (09/26/85)
In article <147@cybavax.UUCP> rartym@cybavax.UUCP (Richard Artym) writes: > >Goodness! All this time you poor souls have been using tty handlers >without built-in pagination? ... > ...this is the normal state of affairs, >the solution should be provided by default. Where and how it's >implemented is a separate issue, although most will agree that for >efficiency and simplicity the best place to put the code is in the >tty handler... Most, perhaps. Historically, perhaps. Pagination should be implemented in the terminal. Silicon is cheap enough these days to put a lot of smarts in even an inexpensive terminal. But even there it should be programmable by the user. Lacking that, i think that the best place to but pagination and such is between the process and the terminal. It would be nice to be able to specify (somehow) a filter that all output went through on its way to /dev/tt???. Then i could make my own pagination (or lack thereof) sit in there and do what i want it to. It does not (!) belong in the low level driver. I think that there may well be too much going on there now. If you have a choice between putting the code in the driver and leaving it out for a user level program, opt for the latter. That way it can be more easily changed by someone who wants something different. My philosophy boils down to : "When in doubt, leave it out -- of the kernel at least" -- O -- jefu tell me all about -- UUCP: edison!steinmetz!putnam Anna Livia! I want to hear all.... -- ARPA: putnam@kbsvax.decnet@GE-CRD
seth@megad.UUCP (Seth H Zirin) (10/02/85)
> Actually, UNIX has a way of preventing text from scrolling by so fast that > you can't read it ( or reach ^S before it goes by ). There is a scroll rate > parameter setable vis stty. I am sure most UNIXs have it. Just do a stty > followed by a number indicating the desired scroll rate. Higher numbers are > faster ( note: not all numbers are available - check your manual ). For > example, a "stty 300" will set the scroll rate to 1/32 of what most people > have it set at. If you are real slow, try "stty 75". > Oh, you may have to adjust some switches on your terminal. Good luck! > ihnp4!cithep!tim Doing a "stty 300" or a "stty 75" does more than set the scroll rate, it sets the Baud rate! I suggest using a command like "more" or "pg" to paginate. -- ------------------------------------------------------------------------------- Name: Seth H Zirin UUCP: {decvax, ihnp4}!philabs!sbcs!megad!seth Keeper of the News for megad
trb@masscomp.UUCP (Andy Tannenbaum) (10/08/85)
In article tim@cithep and seth@megad write: > > Actually, UNIX has a way of preventing text from scrolling by so fast that > > you can't read it ( or reach ^S before it goes by ). There is a scroll rate > > parameter setable vis stty. I am sure most UNIXs have it. Just do a stty > > followed by a number indicating the desired scroll rate. Higher numbers are > > faster ( note: not all numbers are available - check your manual ). For > > example, a "stty 300" will set the scroll rate to 1/32 of what most people > > have it set at. If you are real slow, try "stty 75". > > Oh, you may have to adjust some switches on your terminal. Good luck! > > ihnp4!cithep!tim > > Doing a "stty 300" or a "stty 75" does more than set the scroll rate, it > sets the Baud rate! I suggest using a command like "more" or "pg" to > paginate. > Seth H Zirin cithep!tim is barking up a tree that's next to the right one. UNIX has, since the dawn of time, supported carriage return and newline delays in the terminal driver. If you want to control scroll rates, you can use these. These delay modes were originally in there because in old terminals there was actually a *carriage* to return, and it took time to return, and if you didn't give it time to return, your output would be spewed on the *paper* wherever the carriage happened to be flying on its flight home. This was in the days before XON/XOFF, RTS/CTS, 300 baud, and CRT's were features built into the tools of every hacker's trade. Anyway, if you want slower scroll rates, this is probably a better idea than changing the baud rate. A control key (or two!) could be made to switch the delay mode on and off and delays times could be hacked to taste. FYI, Masscomp's tty driver has a nice passive tty paging system that is quite smart, accounting for wrapped lines, different screen/window sizes, it does scroll or noscroll (clear screen or overwrite with erase EOL), and other goodies. It is compatible with 4.2BSD and SysVr2 at the ioctl(2) and stty(1), and user input levels, has ^T job/system status with more than 25 selectable info items, optional delayed echo, everything you ever wanted for Christmas. Of course, if you don't like this stuff or don't care about it, it doesn't get in your way. If I get enough requests, I'll post an annotated stty everything listing (if the net can handle the load). Andy Tannenbaum Masscomp Westford, MA (617) 692-6200 x2274
guy@sun.uucp (Guy Harris) (10/10/85)
> cithep!tim is barking up a tree that's next to the right one.
cithep!tim is pulling our collective leg. I guess his article needed a :-).
Good grief.
Guy Harris