greg@isrnix.UUCP (Gregory R. Travis) (01/14/84)
What is all this about 'paging tty drivers?' That certainly doesn't go with
the UNIX philosophy of letting the kernel make as few real decisions of its
own. So what if 'more' is a bit slow? It handles different terminal types,
does underlining and shading on terminals that can handle it, manipulates
files, searches for patterns, etc. I see no reason to load down the kernel
with additional code that could be better implemented in user-level
software! As for an example of a 'filter' I can't think of a better
example of one than 'more.' Sheesh, first pipes weren't good enough, then
it was signals, now it's filters! Before you know it someone is going to
hardwire the shell into the kernel!
--
Gregory R. Travis
Institute for Social Research - Indiana University - Bloomington, In
ihnp4!inuxc!isrnix!greg
{pur-ee,allegra,qusavx}!isrnix!gregphil@amd70.UUCP (Phil Ngai) (01/15/84)
I realize this is akin to discussing religion, but using filters
is slow. People have been known to do some pretty strange and
disgusting things in the name of speed. I would cite the 4.2 BSD
filesystem as an example of trading off simplicity for speed.
(but not as an example of a strange or disgusting hack)
Anyway, this topic will probably not benefit from discussion, for
I basically agree with you. (but "more" is still slow)
--
Phil Ngai (408) 988-7777 {ucbvax,decwrl,ihnp4,allegra,intelca}!amd70!philbarmar@mit-eddie.UUCP (Barry Margolin) (01/16/84)
Regarding the need for a "paging tty driver". Is there any time that you WOULDN'T want serial terminal output paged? Why should the user have to remember to type "|more" after just about every line, just so that he can see all of a line that is longer than 80 columns, or so that he can get a chance to read what is being output before it scrolls off? This doesn't necessarily have to be done by modifying the tty driver. Another way to implement it is to make the default standard output be a filter that does some minimal paging; it can recognize when a control character is output and decide that the caller is doing raw output, or something like that. The point is that it doesn't matter how this is done, but the default behavior should be that output gets paged. -- Barry Margolin ARPA: barmar@MIT-Multics UUCP: ..!genrad!mit-eddie!barmar
ntt@dciem.UUCP (Mark Brader) (01/17/84)
"Is there any time that you WOULDN'T want serial terminal output paged?"
--mit-eddie!barmar (Barry Margolin)
There is a problem with automatic paging of all terminal output, which Barry,
utcsstat!geoff (Geoff Collyer), and others seem to find so desirable that
it should be in the kernel. Or at least, there is something important that
you trade off: you lose the ability to predict whether a command will
require any input from the terminal.
If I do a "who", for instance, and see the particular user I am looking for
in the first two lines, I may well start to type a "write" command ahead
immediately. I don't want that typing to be wasted because there turn out
to be 25 users on the machine and so the "who" output doesn't fit the screen.
Or there are only 20 users, as I knew, but my "ps|sort&" comes back just then.
I might run a command file that generates a lot of output, but I only want
to see the first and last part; do I have to filter it, instead of just
letting it scroll by at a high baud rate?
But when I am displaying a "man" file or when I am browsing what I know to
be a long text file, THEN I want pagination. In fact, I want more: I want
to be able to back up to an earlier point... in fact, I want "more".
So yes, there are some of us who feel that paging is something best obtained
by filtering the output from particular commands. This is not to say that
it should not be available automatically as well--as usual, it's a question
of demand, and I am speaking only for myself.
Barry also remarked that he has to use "more" to see the ends of lines that
exceed 80 characters. I would like to point out that terminals which fold
long lines automatically all by themselves are quite common; I don't think
I've used one that didn't have that ability since I stopped using IBM 2741's.
Mark BraderPucc-H:Physics:crl@CS-Mordred.UUCP (01/18/84)
Of course, a 'more' filter fails for programs that detect if their
stdout is a pipe ('ls' comes quickly to my mind).
On a totally different subject, has anyone ever thought of a
new method of setting tty modes? A few friends and I have discussed
the benefits of having (some) tty modes be process-dependent. For
example, if you are in some program that sets (or resets, I can never
remember which) CRMOD, or RAW, and then something else writes to you
(a background process, another user, network daemon), then \n's aren't
changed to \r\n's, and so it totally disrupts the message and your
screen. If the CRMOD (or a new equivalent mode) were process-dependent,
then the output would be ok. There is also the benefit of not having
to catch signals and reset modes just to do some simple things, such
as a "Type any character to continue" type behavior.
Comments?
Charles LaBrec
UUCP: pur-ee!Physics:crl, purdue!Physics:crl
INTERNET: crl @ pur-phy.UUCPgreg@isrnix.UUCP (Gregory R. Travis) (01/18/84)
Many people have written to the net and to me about my comment regarding
hacking the tty driver to do paging. I'm still not convinced that it is
at all kosher. It seems that a lot of anger is being directed at 'more'
itself - I'll agree that 'more' is a bit 'more' (hehee (*sorry*)) than it
needs to be. I do have several additional points:
1) More on our system (2.8BSD 11/44) isn't slow starting up. In
fact, I can't tell when readnews needs to fire more up and when
it doesn't. This may be our system though, we have 'more'
with the sticky bit on and some other kernel hacks
(not disgusting ones though!) to speed file I/O and execs.
2) I am biased, I worked on a 300 baud CDC Kronos system for
5 years before moving up to UNIX @ 9600 baud. Nothing that I can
think of even comes close to the thrill of seeing that little
'--More--' IN REVERSE VIDEO pop up on my Televideo 925. I
really don't want to lose it.
3) To make the kernel page nicely, you have to at least make it
give you a prompt when it pauses so that the new user won't
go home after 30 minutes thinking that the system died when
actually it wants him to hit return. That means that the KERNEL
has to send a TEXT message (like '--More--') to a users terminal.
The thought of the kernel sending messages to regular ttys (not the
console) makes me shudder. Again, this is a personal bias. I
hacked (a pretty hack, tho) a control-T into our kernel 2 years
ago and the thought of adding the code to print strings and check
for buffer overflows and the like still sends shivers up and
down my spine (I woke up feverish and screaming last night after
a nightmare where I was logged into our system with
a 'paging' tty driver and it started giving me a help menu!).
4) To add onto point #3 above. Once you get to the point where you
are saying "Ok, lets make the kernel talk to joe user" you start
saying "Wasn't 'more' neet when it would print in reverse video?
Let's add an ioctl to pass terminal attributes to the tty driver!"
"Yeah! And ioctl's to do cursor addressing!." That kind of
stuff is for giant monitors like TOPS-10. Not UNIX. If you don't
like 'more' write your own. At least as a user-level program you
can replace it. If it goes into the kernel, you're out of luck
bucko.
My fundamental argument is that if 'more' doesn't perform as you would like,
change it! Don't change the kernel. If you want a huge lumbering kernel,
get MVS! I could go on, but I think I've already gone on enough about a
fairly benign subject. Flames/comments/discussion are welcome.
Is my grammar ok?
--
Gregory R. Travis
Institute for Social Research - Indiana University - Bloomington, In
ihnp4!inuxc!isrnix!greg
{pur-ee,allegra,qusavx}!isrnix!gregguy@rlgvax.UUCP (Guy Harris) (01/18/84)
<has everybody fixed this yet?>
1) More on our system (2.8BSD 11/44) isn't slow starting up. In
fact, I can't tell when readnews needs to fire more up and when
it doesn't. This may be our system though, we have 'more'
with the sticky bit on and some other kernel hacks
(not disgusting ones though!) to speed file I/O and execs.
On our 11/780 running 4.1BSD and later 4.1cBSD you could definitely tell
when "more" was getting cranked up.
3) To make the kernel page nicely, you have to at least make it
give you a prompt when it pauses so that the new user won't
go home after 30 minutes thinking that the system died when
actually it wants him to hit return. That means that the KERNEL
has to send a TEXT message (like '--More--') to a users terminal.
The thought of the kernel sending messages to regular ttys (not the
console) makes me shudder. Again, this is a personal bias.
Watch out for 4.xBSD, then, it sends "mag tape not ready" and "out of space"
messages to the user's terminal.
I hacked (a pretty hack, tho) a control-T into our kernel 2 years
ago and the thought of adding the code to print strings and check
for buffer overflows and the like still sends shivers up and
down my spine...
Actually, I believe TENEX/TOPS-20 implemented ^T by making it cause a signal
which was ignored by almost everybody but caught by the shell, which did the
moral equivalent of a "ps" or "jobs" command when it got that signal. A lot
of people who propose or implement it do so by putting the entire facility
into the kernel, when all that's necessary may be hacking the TTY driver a bit
and hacking the shell(s) a bit.
4) To add onto point #3 above. Once you get to the point where you
are saying "Ok, lets make the kernel talk to joe user" you start
saying "Wasn't 'more' neet when it would print in reverse video?
Let's add an ioctl to pass terminal attributes to the tty driver!"
"Yeah! And ioctl's to do cursor addressing!." That kind of
stuff is for giant monitors like TOPS-10. Not UNIX. If you don't
like 'more' write your own. At least as a user-level program you
can replace it. If it goes into the kernel, you're out of luck
bucko.
Actually, there are two OSs smaller than TOPS-10 that have special functions
to do cursor addressing, although the kernel's repertoire of terminal models
is small; RSX-11M and UNIX System V (it originally came from Columbus UNIX,
I believe).
Guy Harris
{seismo,ihnp4,allegra}!rlgvax!guypreece@uicsl.UUCP (01/19/84)
#R:isrnix:-1800:uicsl:12500019:000:677 uicsl!preece Jan 18 08:43:00 1984 Well, there ARE some times I don't want my terminal output paged. One case is when I'm downloading files to my PC. Another is when I'm just watching a script run and I don't really want to be part of the process. In any case, it seems like this behavior might reasonably be made part of the shell, rather than the tty driver. In fact, what we really need is a shell oriented to CRT use rather than TTY use. Some of these have started appearing for micro Unices. I imagine that sometime in the next couple of years someone will produce a really good one and make it available via net.sources and it will be the new default for everyone. scott preece ihnp4!uiucdcs!uicsl!preece
brad@bradley.UUCP (01/20/84)
#R:isrnix:-1800:bradley:3900007:000:595 bradley!brad Jan 17 10:23:00 1984 I agree, why hack the kernel. Use 'more', I would also like to add one other thought. If you had a terminal paging mode, and the process you ran only put out lets say 15 lines, it wouldn't page, Right? Well what happens when the next process you run is also 15 lines, Does it stop at 8 lines into the program output? Or is it smart enough to do reset the counter. Also what about 'stderr'? What bit are you going to use to set this mode? And how standard will it be with other programs. Also you will have to turn it off for editors, like vi (but they do ioctl) but what about 'ed'? Brad Smith
laura@utcsstat.UUCP (Laura Creighton) (01/20/84)
Over at utzoo they have a wonderful trick that keeps naive users from thinking that the system died when using a kernel paginator. They don't give it to them. If you want it, you have to ask for it. If you know enough to ask, then you know enough to use it. How many people *don't* type break (or something) when they think that the system has crashed, anyway? Everybody I know does, for some reason. The usefulness of a kernel paginator is so that you will never have to say "drat -- should have run it through p" again, in your life, ever. The disadvantage is that you have to add code to your kernel and every so often you decide that you should have disabled pagination before you did something. So far, I have had that happen once since Christmas. On the other hand, I remember that I used to type "|p" onto everything by default. And when I didn't I regretted being forgetful -- at least 3 times a day. I think that it is incredibly useful. And I think that pagination is something that it is justifiable to put into the kernel, simply because the number of times you do not want something paginated is so rare that it is silly to have to run every command that has more output than you expected *twice* -- once to discover that it is long and once to pipe it through something so that you can get all the information. Living your life ready to type ^S all the time is not fun. this sort of menial task "if there is more than a screen length, then assume I typed ^S" is the sort of things that computer programs are wonderful at. The question is where to put it? Personally, I would rather hack the kernel (where it is easy) than the shell (where it is hard). Plus, even people silly enough to still be using the cshell (hi eric!) can get pagination this way. Hacking every shell seems as good evidence as any that this thing should have been in the kernel in the first place...but as an option. Laura Creighton utzoo!utcsstat!laura
barmar@mit-eddie.UUCP (Barry Margolin) (01/21/84)
bradley!brad Jan 17 10:23:00 1984
I agree, why hack the kernel. Use 'more',
I think Laura Creighton (sp?) answered this well enough.
I would also like to
add one other thought. If you had a terminal paging mode, and the
process you ran only put out lets say 15 lines, it wouldn't page,
Right? Well what happens when the next process you run is also 15
lines, Does it stop at 8 lines into the program output? Or is it
smart enough to do reset the counter.
The counter should be reset whenever you take input from the terminal,
and there should be an IOCTL to reset it, too. This is another reason
for putting it into the kernel; consider the disgusting ":" hack in
readnews that is an attempt to get around the fact that it is only
reasonable to put one article at a time through 'more'.
Also what about 'stderr'?
What about 'stderr'? The kernel doesn't know from this; it just sees
one terminal.
What bit are you going to use to set this mode? And how standard
will it be with other programs. Also you will have to turn it off
for editors, like vi (but they do ioctl) but what about
'ed'?
Certainly vi and emacs have to turn it off. What problem do you see
with ed? Is there something wrong with paging the output of '1,$p'?
--
Barry Margolin
ARPA: barmar@MIT-Multics
UUCP: ..!genrad!mit-eddie!barmardvk@mi-cec.UUCP (Dan Klein) (01/26/84)
Kernel Pagination? BLEAH!! I am sorry to inform you folks, but not all of us like page mode terminal output. Sure, sometimes I need it, and then I do a |more. And if I forget to do it, I use ^S/^Q. I admit, it would be very nice to be able to stop a job and redirect the output through "more" once stopped. I seem to remember some talk of that during Uniforum. But seriously, I *do* like having my output scream off the screen at 9600 baud, since if there is gobs of output, I can *visually* scan for what I want. The human pattern recognition system is a marvelous thing - I use it. (Often the patterns I want to find in a stream of output are too complex (i.e. multi line) to be recognized by a paginator. And when the output I am scanning is a pile of debug printf's, I don't want to sit there banging the space bar to bet a page at a time. It slows me down too much. So I vote against automatic pagination unless I can unequivocably disable it when I want to. -Dan Klein, Mellon Institute, Pittsburgh
boyd@basservax.SUN (Boyd Roberts) (01/31/84)
> I think that it is incredibly useful. And I think that > pagination is something that it is justifiable to put into > the kernel, simply because the number of times you do not > want something paginated is so rare that it is silly to have > to run every command that has more output than you expected > *twice* -- once to discover that it is long and once to pipe > it through something so that you can get all the > information. I seem to use the "shell" a *lot* too, in fact more often than not. Gee, I think I'll hack it into the kernel. > Hacking every shell seems as good evidence as any that this > thing should have been in the kernel in the first place...but > as an option. Well I can't think why the "shell" wasn't part of the kernel from the start (it could have even been an *option*). Maybe it's got something to do with providing a small, powerful set of primitives with which to build on. The trend now seems to be towards a interesting power set of high level, unusable pieces of gore typified by the "vhanghup" style of: "We couldn't think how to do it right, so we wrote a few more system calls." This crap about "well, we do it a lot, so lets do it all the time" makes me want to puke. What happens when you really don't want to do it? Invariably with that style you wind up not being able to do the simple things, when you really need to. UNIX gives a good base with which to build on. If you want the "power set" or the "interesting options" use VMS. The fact that UNIX's source code is available, small, simple and written in a portable high level language (the very things that make UNIX) may well spell it's downfall, courtesy of the people from Berkeley and their ilk. Just stick to elegance, simplicity and UNIX. If you want gore boot VMS, although "...| more" could be interesting. -- From the Schooner Glass of Boyd Roberts. decvax!mulga!boyd:basservax
dhb@rayssd.UUCP (01/31/84)
I can't quite decide wether the suggestion that paging be moved to the hardware was serious or not, but let me just note that this has already been done! I am typing this on a Z-29 terminal and it has what Zenith calls "hold-screen mode". When the terminal is about to scroll off the 24'th line it sends a control-S to the computer. I can then press "SCROLL" to see one more line, or shift-SCROLL to see another page. The Z-19 has a similar capabilty and I believe the VT-100 family has it too. -- Dave Brierley Raytheon Co.; Portsmouth RI; (401)-847-8000 x4073 ...!decvax!brunix!rayssd!dhb ...!allegra!rayssd!dhb ...!linus!rayssd!dhb
tjt@kobold.UUCP (02/01/84)
The problem with using a terminal-based pager (e.g. "hold-screen mode"
on VT52's and lookalikes) is that it halts every 24 lines, need it or
not. A typical pager built into the system will only pause if there has
been a screenful of output since the last input wait. This accomodates
Dennis Ritchie's interactive mode (the user types a line or two, the
computer types a line or two, the user types another line ...) without
forcing a pause every 24 lines.
Someone proposed a terminal "hold-screen mode" that is reset whenever
the user types a key. This is *not* the same since I don't want
typeahead to thaw my page mode, and only the OS knows when I'm in input
wait. Indeed, some care should be taken in a kernel pager to leave
typeahead undisturbed (at least for the simple case of pausing and
continueing -- aborting the output should probably flush the typeahead).
--
Tom Teixeira, Massachusetts Computer Corporation. Westford MA
...!{ihnp4,harpo,decvax}!masscomp!tjt (617) 692-6200 x275kre@mulga.SUN (Robert Elz) (02/07/84)
I too have been considering making stty be a per process change. (That is, after a TIOCSET[PN] (or TCSETA* for Sys III/V), the process would have its own set of tty modes, independant of those of its parent). Modes would be inherited from parent to child. There would need to be a new ioctl command, for processes like stty and tset to use, but there's nothing remarkable in that. (I would make the new commands the global ones, as there are only a few programs that wish to do global changes, but many whose changes are intended to be for this process only) The definition of a "global" change, would be one that would affect the process's parent's tty settings (and back up the tree, to the point where some process did a "local" change). I would make the entire set of terminal settable characteristics act on a per-process basis, not just an isolated one or two. That would be very hard to explain, etc, not at all "nice". I too would appreciate comments, preferably by mail. Robert Elz decvax!mulga!kre (kre@Berkeley works too)
cfh@cca.UUCP (Christopher Herot) (02/08/84)
Most versions of terminal paging that I have seen will go ahead and scroll all remaining output if you type ^Q.
donn@sdchema.UUCP (02/29/84)
Nigel Horne (ukc!root44!njh) says, with some degree of sarcasm: But I don't always want to have to type Return all the time, and I also think that the kernel recognising \b as a special character is a disgusting hack. If we are supposed to use |more rather than leaving the 60's idea of a teletype driver(!!!!!) then why not also have some PROGRAM which recognises ^H,^C,^Z,^S,^Q etc. Actually this is not as bad an idea as it sounds. Nigel intends that it should appear ridiculous, but in fact I think this is close to what is meant by 'stackable line disciplines' or 'stream (coroutine) I/O'. The basic interface to the system might be a simple byte stream, sufficient for networking programs; on top of that a user could put a module that interpreted special characters a la V7, and on top of that a module that worked like the Berkeley new tty driver, and on top of that a module that did CRT paging. You could go even further and put a virtual terminal on top; rip out all the user code dealing with terminal idiosyncracies and have programs communicate with a module which knows all there is to know about a particular terminal and does screen (bitmap?) manipulation just the way you want it. Instead of pasting a '|more' onto commands, you push another I/O module onto your stack. Pseudo-ttys would be easy -- attach a module that attaches to an IPC port. The main issue with this approach is probably speed. What might be a good way to put the elements together so that the overhead is low? More issues: these I/O processing units could live either inside or outside the kernel; inside the kernel means no paging and fast access to needed kernel privileges, but sometimes one might want the code to be paged and moreover it might be nice to let users write their own modules and attach them without needing kernel privileges. Dream on, Donn Seeley UCSD Chemistry Dept. ucbvax!sdcsvax!sdchema!donn 32 52' 30"N 117 14' 25"W (619) 452-4016 sdcsvax!sdchema!donn@noscvax
ebk@iedl02.UUCP (03/01/84)
References: root44.4353 > But I don't always want to have to type Return all the time, and > I also think that the kernel recognising \b as a special character is > a disgusting hack. If we are supposed to use |more rather than leaving > the 60's idea of a teletype driver(!!!!!) then why not also have some > PROGRAM which recognises ^H,^C,^Z,^S,^Q etc. Because then the kernel would have to switch contexts every time anyone hit a character. (Unless you want to have a PROGRAM to switch contexts!) Although I totally agree philosophically with the people who object to putting something not necessary in the kernel, I think one function that it is in the nature of the kernel to provide is the i/o interface. I like Berkeley's ntty driver, with ^W, etc. The original source for ^W and ^O was TOPS-10, the DEC-10 OS. TOPS-10 also had a setting 'SET TTY PAGE nn', and whenever nn lines were sent to the terminal *without a keypress during that time*, it would stop, and wait for a key to resume. (It might wait only for ^Q, I don't remember.) So why not 'stty page 24' to turn it on, 'stty -page' to turn it off, and if you don't want it, you never see it. Less than a page of code in the driver, a few lines in stty, and you have a simple, clean, UNIX-LIKE pager. (I don't think more is very Unix-like at all!) John Owens ...!duke!mcnc!ncsu!uvacs!icase!oducs1!owens_j
njh@root44.UUCP (Nigel Horne) (03/05/84)
/**/ But I don't always want to have to type Return all the time, and I also think that the kernel recognising \b as a special character is a disgusting hack. If we are supposed to use |more rather than leaving the 60's idea of a teletype driver(!!!!!) then why not also have some PROGRAM which recognises ^H,^C,^Z,^S,^Q etc. No silly flames about "You can always say stty raw", because on a resonable tty driver you can say "stty length 0 width 0", or just ^P. Nigel Horne Root Computers Ltd. ukc!root44!njh edai!root44!rootis!njh
ebk@iedl02.UUCP (03/08/84)
# From: brian beattie <decvax!ucbvax!beattie@mitre-gateway.ARPA> What about lines longer than the terminal width. "stty line 80" may not work due to control chars. unless you want "more" in the kernel with the reading of /etc/termcap and all you will always end up with either a partial solution or will be able to handle only one type of terminal. beattie@mitre And what about whether a terminal wraps or not? I'll stick with the traditional Unix definition of a line - a sequence of characters terminated by a \n. Much more elegant. (And much better than systems like VMS or TOPS-10 with their commands like SET TERM/VT100 !!!) John Owens
henry@utzoo.UUCP (Henry Spencer) (03/11/84)
Brian Beattie observes:
What about lines longer than the terminal width.
"stty line 80" may not work due to control chars.
unless you want "more" in the kernel with the reading
of /etc/termcap and all you will always end up with
either a partial solution or will be able to handle
only one type of terminal.
beattie@mitre
I hate to tell you folks this, but the kernel is *already* keeping
track of what column you're at, so that it can do software-interpreted
tab stops properly. I agree that there is a potential problem with
the handling of control characters, since the kernel's interpretation
of whether a particular character causes a column motion or not is
quite simplistic, but in practice this does not get in the way very
much. Programs that deliberately emit control characters generally
are controlling the terminal directly, in CBREAK or RAW mode, and thus
bypass tty-driver pagination altogether. Control characters spilled out
onto the terminal by doing something silly like catting a binary file
make a horrid mess anyway, and hence are not really an issue. It
really isn't a problem, folks.
And John Owens follows it up with:
And what about whether a terminal wraps or not? I'll stick with the
traditional Unix definition of a line - a sequence of characters
terminated by a \n. Much more elegant. (And much better than systems
like VMS or TOPS-10 with their commands like SET TERM/VT100 !!!)
If the terminal doesn't wrap, you simply set the line length to 0 (i.e.,
"ignore issues of line length"). If it wraps in some strange way, you
just give the line length as one character less than it really is, so
the terminal's oddities are ignored completely. I know of at least two
screen-oriented programs that do this, and few people have ever noticed.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henrythomas@utah-gr.UUCP (Spencer W. Thomas) (03/12/84)
Have you ever noticed how more doesn't work very well if you specify -c and you have said stty -tabs? This is because the kernel has in it code which counts characters to determine how to simulate tabs. When running with more -c, more puts out a "line clear" sequence at the beginning of each line. This generally doesn't cause the cursor to move, but the kernel counts those characters anyway. So, the tab emulation is all screwed up. So, would you suggest that we take tab emulation out of the kernel and put it into every single program which wants to do output? =S