ARaman@massey.ac.nz (A.V. Raman) (09/27/89)
How does man know? ------------------ (This article is not cross posted to talk.philosophy.misc) Synopsis: ~~~~~~~~~ What is the difference between $ man sh and $ man sh | grep -i chdir as far as man is concerned When I do a man sh, I have to page down a few times or /search to get to the page where chdir, for example, is discussed. However when I pipe the output of man into another command or redirect it into a file, man seems to somehow sense that it is now writing into a pipe rather than into a terminal because it does not pause after each screenful asking for keyboard input. This is quite perplexing because it goes against the basic philosophy of transparency in UNIX, as it is the shell that is supposed to handle such things as pipes and redirections. Theoretically and ideally, man, more, or other such things should never get to know where their output is physically going. My guess is that when shell forks and execs man, it passes down the file descriptor of stdin and stdout, which however, are now different from the actual stdin and stdout and man uses (stdout->_file == 1)? to determine whether the output is a tty or not (yuck). But it does seem to be very convenient though. Am I right? Morals of the story: ~~~~~~~~~~~~~~~~~~~~ 1. Man may not always know everything that one asks for; but he sure knows somethings that sometimes none asks for. 2. Man does learn from dad sometimes -- /*----------------------------------------------------------------------*/ Anand Venkataraman - Systems group, Computer Center, Massey University, Palmerston North, New Zealand INTERNET: A.Raman@massey.ac.nz Ph: +64-63-69099 x7943 NZ = GMT + 12
cpcahil@virtech.UUCP (Conor P. Cahill) (09/28/89)
In article <319@massey.ac.nz>, ARaman@massey.ac.nz (A.V. Raman) writes: > When I do a man sh, I have to page down a few times or /search > to get to the page where chdir, for example, is discussed. > However when I pipe the output of man into another command or > redirect it into a file, man seems to somehow sense that it is now > writing into a pipe rather than into a terminal because it does > not pause after each screenful asking for keyboard input. This is because man uses isatty() to determine if the file descriptor associated with stdout is a tty filedes or not. If it is, the output gets processed through a pager, otherwise it just dumps the output. > My guess is that when shell forks and execs man, it passes down the > file descriptor of stdin and stdout, which however, are now different > from the actual stdin and stdout and man uses (stdout->_file == 1)? > to determine whether the output is a tty or not (yuck). But it does > seem to be very convenient though. Nope. stdout->_file is still equal to 1. The FILE pointer std* is not passed to the child program, the file descriptors are. The stdio library always attatches stdout to file descriptor 1. You should note that this does not violate the "basic philosophy of transparancy in UNIX" because it is transparent. The program does have the ability to break through the transparancy, but the transparancy is there. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/28/89)
In article <319@massey.ac.nz> ARaman@massey.ac.nz (A.V. Raman) writes: >However when I pipe the output of man into another command or >redirect it into a file, man seems to somehow sense that it is now >writing into a pipe rather than into a terminal because it does >not pause after each screenful asking for keyboard input. That's the Berkeleyized version of "man". It tells the difference by doing an isatty() test on its stdout. (That's a check to see whether terminal ioctls work; if they do, it assumes the output is going to a terminal with a human operator attached.) >This is quite perplexing because it goes against the basic philosophy >of transparency in UNIX, as it is the shell that is supposed to handle >such things as pipes and redirections. Theoretically and ideally, >man, more, or other such things should never get to know where their >output is physically going. You're right, of course. Somebody thought it would be "convenient" for the command to alter its behavior based on what the implementor thought the usage would be. Thereby demonstrating once again that Earth people are stupid, stupid, stupid.
aryeh@eddie.MIT.EDU (Aryeh M. Weiss) (09/28/89)
In article <11170@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >In article <319@massey.ac.nz> ARaman@massey.ac.nz (A.V. Raman) writes: >>However when I pipe the output of man into another command or > >That's the Berkeleyized version of "man". >It tells the difference by doing an isatty() test on its stdout. > >>This is quite perplexing because it goes against the basic philosophy >>of transparency in UNIX, as it is the shell that is supposed to handle > >Somebody thought it would be "convenient" for the command to alter >its behavior based on what the implementor thought the usage would be. >Thereby demonstrating once again that Earth people are stupid, stupid, >stupid. In System V ( or Xenix at least ) man forks and runs MORE (or pg or less, depending on the configuration). So it is MORE that has the SMARTS. It makes NO sense for a paging program to page its output if that output is not going to a tty! There are cases when you may want a usually interactive program to run in batch mode or backround disconnected from the terminal and behave slightly differently. I wrote a data input routine that wrote a prompt but ECHOED data input to stdout if stdin was not a tty (if stdin is a tty the data input is already being echoed). This way I could see that the input BATCH file was in the correct format. Isatty is in the library for very good reasons. -- eliot%lees-rif@eddie.mit.edu
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (09/28/89)
In article <11170@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: | You're right, of course. | Somebody thought it would be "convenient" for the command to alter | its behavior based on what the implementor thought the usage would be. | Thereby demonstrating once again that Earth people are stupid, stupid, | stupid. And guess what? It *is* convenient to have it work that way. If I need a copy of the man page in a file I can say "man foo >file" and not have to guess when it's waiting for me to hit return. If I want to use my own pager for some reason I can "man foo | mypage" and it works. Without this man would not work right in shell scripts or any of the above convenient uses. The object of writing a command for any o/s is to make it useful, and if that's stupid I hope a few more stupid people get working on UNIX. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
deke@ee.rochester.edu (Dikran Kassabian) (09/29/89)
In article <592@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes: >In article <11170@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: > >| You're right, of course. >| Somebody thought it would be "convenient" for the command to alter >| its behavior based on what the implementor thought the usage would be. >| Thereby demonstrating once again that Earth people are stupid, stupid, >| stupid. > > And guess what? It *is* convenient to have it work that way. If I >need a copy of the man page in a file I can say "man foo >file" and not >have to guess when it's waiting for me to hit return. If I want to use >my own pager for some reason I can "man foo | mypage" and it works. Well, yes, it is convenient. But I can imagine other convenient methods that would work *and* be consistant with the (sometimes elusive) UNIX philosophy. Think of man(1) as being a simple interface to a database, namely /usr/man. When using this interface, it might be understood that a screen pager will be used. In places where any sort of indirection is required, one might use another interface to the database. If you have preformatted pages in /usr/man/cat[1-8], then cat(1) is certainly an option. If not, then the proper selection and combination of the formatter (probably [nt]roff) and other utilities like grep or sed could be used. I'm not disagreeing with bill davidsen. I like the way man(1) works, day to day. But I do admit that its probably 'wrong'. ^Deke Kassabian, deke@ee.rochester.edu or ur-valhalla!deke Univ of Rochester, Dept of EE, Rochester, NY 14627 (+1 716-275-3106)
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/29/89)
In article <592@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes: > And guess what? It *is* convenient to have it work that way. No, it isn't. One can easily add pagination in those cases where it is desired, but it's much more difficult to defeat wired-in pagination in those cases where it isn't desired. Consider "man whatever > /dev/tty_printer". Why should that try to paginate?
richard@aiai.ed.ac.uk (Richard Tobin) (09/29/89)
In article <11182@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >No, it isn't. One can easily add pagination in those cases where it >is desired, but it's much more difficult to defeat wired-in pagination >in those cases where it isn't desired. In what way more difficult? If pagination is done when the output is a tty, then pagination can be defeated by piping through cat. This is just as easy as adding pagination by piping through more, and for man the paginating version is much the most common. However, I would advise people writing such "context sensitive" programs to provide a flag that ensures uniform behaviour. -- Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (09/29/89)
In article <11182@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: | In article <592@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes: | > And guess what? It *is* convenient to have it work that way. | | No, it isn't. One can easily add pagination in those cases where it | is desired, but it's much more difficult to defeat wired-in pagination | in those cases where it isn't desired. | | Consider "man whatever > /dev/tty_printer". Why should that try to | paginate? That's exactly what I said. The original poster said it was stupid to disable pagination when not going to a tty. I said it was very convenient to have it work that way and showed examples similar to yours of why. Please understand what I said before disagreeing. To say "No, it isn't" and then paraphrase what I said as a rebuttal doesn't show your best mental capabilities. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
barnett@crdgw1.crd.ge.com (Bruce Barnett) (09/29/89)
In article <11182@smoke.BRL.MIL>, gwyn@smoke (Doug Gywn) writes: >Consider "man whatever > /dev/tty_printer". Why should that try to >paginate? Good point. But I've never had that problem. I would either use man whatever|lpr man -t whatever Much easier to type. If you insist on sending it to a serial port without pagination, type man - whatever >/dev/tty_printer (Works on SunOS 4.0) In fact, Doug, I haven't noticed any inconvenience in man automatically calling PAGER if the output device is a tty. The opposite case causes problems also. Imagine the beginner typing man more because they don't know what more(1) is. At the next prompt, they still don't know! :-) IMHO the BSD solution was right. It favors the beginner and lets the advanced user work around the default behavior. Forcing the beginner to work around the default behavior is wrong. Especially with the manual pages! -- Bruce G. Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
frank@rsoft.bc.ca (Frank I. Reiter) (09/30/89)
In article <592@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes: > And guess what? It *is* convenient to have it work that way. In article <11182@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: > >No, it isn't. One can easily add pagination in those cases where it >is desired, but it's much more difficult to defeat wired-in pagination >in those cases where it isn't desired. > >Consider "man whatever > /dev/tty_printer". Why should that try to >paginate? man is optimized for the usual case. The authors obviously expected that the usual case would be interactive use on a terminal but allowed for non- paginated (non-interactive) use if output was not going to a terminal. It is TRIVIAL "to defeat wired-in pagination [etc.]" I don't consider myself any sort of wizard but it took me only a moment to think of: man whatever | cat >/dev/tty_printer for the problem you pose. -- _____________________________________________________________________________ Frank I. Reiter UUCP: {uunet,ubc-cs}!van-bc!rsoft!frank Reiter Software Inc. frank@rsoft.bc.ca, a2@mindlink.UUCP Langley, British Columbia BBS: Mind Link @ (604)533-2312, login as Guest
gregg@cbnewsc.ATT.COM (gregg.g.wonderly) (09/30/89)
From article <11182@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn): > In article <592@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes: >> And guess what? It *is* convenient to have it work that way. > > No, it isn't. One can easily add pagination in those cases where it > is desired, but it's much more difficult to defeat wired-in pagination > in those cases where it isn't desired. There are many arguments both ways. In a newer version of the man(1) program that I posted to comp.sources years ago, I decided to adopt the following strategy. It provides alternatives for all the choices. if (isatty (1)) { If $MANPAGER is defined { if ($MANPAGER == "") pager = "cat"; else pager = $MANPAGER } else if $PAGER is defined pager = $PAGER else pager = "pg"; } I admit that all of the contortions and exceptions bend the mind a bit. The obvious question is why choose pg(1) by default over cat(1). Especially since a user without PAGER set is probably too naive to know how to use pg(1) anyway. IMHO that a pager should always be available. Naive users probably also don't know how to use noscroll or ^S/^Q either. I prefer to have the pager on by default because I almost always want to use it. I don't know of anything other than the current pagers, such as pg(1) and less(1), that accept a file on standard input and then allow you to page up and down searching (as the original article discussed the need for). > Consider "man whatever > /dev/tty_printer". Why should that try to > paginate? That is precisely where isatty(3) comes in handy. It should not and because you can not possibly program in all the possibilities, the easiest (but not the best) solution is to cover the common cases and let the user who knows more about their environment write frontend and/or backend programs/scripts to take care of that stuff. The best example is printing manual pages. My manual program does NOT provide a printing feature. Instead it provides the capability to return the path to the manual pages so that nroff/troff/whatever can be used to format it. -- ----- gregg.g.wonderly@att.com (AT&T bell laboratories)
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/30/89)
In article <630@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes: -In article <11182@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: -| Consider "man whatever > /dev/tty_printer". Why should that try to -| paginate? - That's exactly what I said. The original poster said it was stupid to -disable pagination when not going to a tty. I said it was very -convenient to have it work that way and showed examples similar to yours -of why. Except I show output GOING to a tty. Also, I don't recall anyone saying that it was stupid to disable pagination when not going to a tty, although several of us have said that it is stupid to automatically paginate when going to a tty. - Please understand what I said before disagreeing. You might take your own advice.
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/30/89)
In article <2674@crdgw1.crd.ge.com> barnett@crdgw1.crd.ge.com (Bruce Barnett) writes: >In fact, Doug, I haven't noticed any inconvenience in man automatically >calling PAGER if the output device is a tty. I certainly have. But then I normally have pagination, scrolling, etc. handled by my terminal where it belongs instead of requiring every outputting utility to have it built in. >IMHO the BSD solution was right. It favors the beginner and lets >the advanced user work around the default behavior. I think it is counterproductive to try to target novices and programming professionals in the same user interface. UNIX's shell environment was designed for the latter, and requires adherence to the toolkit design philosophy for best effect. Interfaces for naive users should be considerably different from the normal UNIX shell command environment!
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/30/89)
In article <53@rsoft.bc.ca> frank@rsoft.UUCP (Frank I. Reiter) writes: >The authors obviously expected that the usual case would be ... Right, and instead of allowing users to decide how to configure their own environment, they decided to force a particular usage model on everybody. The addition of an option to turn off the inappropriate assumption is no excuse make making it in the first place. People who are having trouble understanding my viewpoint should read the initial portion of Kernighan & Pike's "The UNIX Programming Environment". UNIX is not just any old operating system, it embodies a point of view on how computing should be done. I believe that its early acquisition of enthusiastic proponents was largely due to their appreciation of these ideas, which have not lost their power when appropriately exploited.
ok@cs.mu.oz.au (Richard O'Keefe) (09/30/89)
In article <2674@crdgw1.crd.ge.com>, barnett@crdgw1.crd.ge.com (Bruce Barnett) writes: > In fact, Doug, I haven't noticed any inconvenience in man automatically > calling PAGER if the output device is a tty. The opposite case causes problems > also. > IMHO the BSD solution was right. It favors the beginner and lets > the advanced user work around the default behavior. Shortly after I started using UNIX, we upgraded from V6+ to EUUG V7. The terminal driver in EUUG V7 knew how many rows and how many columns and the default behaviour was that after a screenful of output it would wait for you to press a key to continue. If you didn't want that, you just did "stty rows 0". Why was that the ``UNIX'' way of doing things? Because pausing every so often is a function of *terminal* output, not a function of output in general, so it belongs ``near'' the terminal. This obeys the ``one feature one place'' principle. Instead of building ``duh, it's a terminal, maybe I ought to pipe through $PAGER'' into every command (read, building it into an unpredictable subset of the commands) the feature is automatically available to every program: ls, cat, ed, ... Oh the freedom, the joy, the utter pleasure of being able to pick from a random subset of never-quite-the-same versions of more, less, and pg when all I want is `cat'. Oh the excitement: does this program check $PAGER, does it always call pg, or do I need a pipeline? And then you have those delightful moments when an interactive program dumps several screensful on you at once and you can't use $PAGER. No, $PAGER should never have been in man(1). Simple paging should have been in the terminal driver (it's a form of flow control, after all) and any other paging should have been done with explicit pipelines.
barnett@crdgw1.crd.ge.com (Bruce Barnett) (09/30/89)
In article <11194@smoke.BRL.MIL>, gwyn@smoke (Doug Gywn) writes: >>In fact, Doug, I haven't noticed any inconvenience in man automatically >>calling PAGER if the output device is a tty. > >I certainly have. Why is it an inconvenence to set your PAGER environment variable? It just takes a few seconds. Or alias 'man' to man -'? Sure it's nice to have a system that does automatic paging. Sure it's nice to have a windowing system for every user of every Unix system. But there are a lot of users learning Unix without that advantage. > >>IMHO the BSD solution was right. It favors the beginner and lets >>the advanced user work around the default behavior. > >I think it is counterproductive to try to target novices and >programming professionals in the same user interface. Professional know how to read the manuals. Novices haven't done that yet. Doug, I usually understand (and respect) your opinions. But I really don't understand why you think the default behavior of man should be optimized for your particular case. You of all people certainly know how to change the default behavior. >But then I normally have pagination, scrolling, >etc. handled by my terminal where it belongs instead of requiring >every outputting utility to have it built in. >UNIX's >shell environment was designed for the latter, and requires >adherence to the toolkit design philosophy for best effect. >Interfaces for naive users should be considerably different >from the normal UNIX shell command environment! Well, I really meant the first time user of the normal UNIX shell environment. And I am only talking about the behaviour of ONE program. Sure there should be a better help system on line, one that will work with any user interface, including yours, Doug. Maybe the terminal driver for all terminals should have a built-in pager. Every unix system I have used does not have this feature. If every UNIX system had this, I might have a different opinion. But neither exists. The closest thing is man(1). Let's look at the bottom line - How can the beginner learn to change the default environment when they CANNOT READ the manual pages? You certainly don't expect someone just learning shell to write a shell script just so they can read the manuals? Of course they can use Control-S/Control-Q, if they know about it. But that isn't the point. (Also - some people have slow reflexes and can't manage Control-S at 19K baud). I believe that man(1) on V7, Sys III, and Sys V was poorly implemented. The BSD changes were an improvement. Sure it's not perfect, but it certainly make like easier on all those people using it. Does ANYONE else feel the way Doug does? Perhaps they will do a better job of enlightening me. :-) -- Bruce G. Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
jmsellens@watdragon.waterloo.edu (John M. Sellens) (10/01/89)
>No, $PAGER should never have been in man(1). Simple paging should have >been in the terminal driver (it's a form of flow control, after all) >and any other paging should have been done with explicit pipelines. It's all very well and good to say that paging should be in the terminal or the terminal driver, but the simple fact of the matter is that in most cases it isn't. And since it is pretty much a given that terminals and terminal drivers don't do paging, it's silly to argue what man should do under those circumstances. Better we should discuss what man should do under the conditions we live under. (Me? I think paging by default is a good thing and that if someone doesn't want paging then MANPAGER=/bin/cat would seem to me to suffice.)
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/01/89)
In article <3559@cbnewsc.ATT.COM> gregg@cbnewsc.ATT.COM (gregg.g.wonderly) writes: >The best example is printing manual pages. My manual program does >NOT provide a printing feature. Instead it provides the capability >to return the path to the manual pages so that nroff/troff/whatever >can be used to format it. Jesus, what's the difference between formatting a manual page to a terminal and to a printer? You can't even tell whether I'm using my terminal window as a port to access an attached printer or not. I may also be using a Braille terminal, and would disappreciate pagination. There are far more possible environments than you can anticipate, which is why you should not hard-wire in limiting environmental assumptions. By catering to obsolete technology as your assumed "common case" and insisting that better uses of the software will have to be accommodated by additional programming effort, you're providing a powerful disincentive to improve the computing environment!
ARaman@massey.ac.nz (A.V. Raman) (10/02/89)
Thanks for the overwhelming response for my question - How does man know? Thanks goes to the following persons and also to those whose mail I haven't yet received. Tim Olson, Advanced Micro Devices Barry Margolin, Thinking Machines Corp bill davidsen, GE Jeff Beadles, Utek Engineering, Tektronix Inc. Eduardo Krell, AT&T Bell Laboratories, Murray Hill, NJ Frank W. Peters, Mississippi State University Michael A. Thompson, Iotek Inc bob, Omni David Goodenough, +---+ keenan royle, Indiana University, Bloomington guy@auspex.com bill, FPS Computing Inc. The answer is that man uses the isatty (fd) call to find out whether output is going to a tty or not. Special thanks goes to Barry Margolin of Thinking Machines Corp. who points out also, that the Unix philosophy is not so much transparency as simplicity and convenience, and programs should rather be easier to use than 'chaste'. I'm taking the liberty of quoting him: > Personally, I like it when programs > "do the right thing" without requiring everyone to write aliases and > shell scripts. Would you ever NOT want to page the output of "man" > when you're reading it on your terminal? If everyone would have to > write an alias that looked like "man !* | more", it makes good sense > for "man" to do it automatically. -- I guess this is the opinion of BWK himself (The Unix programming environment, ch3.2: > A digression on echo: ... > Since a program should by default execute its most comonly used > function, the real echo appends the final newline automatically.) - anand, Massey Univ., NZ. -- /*----------------------------------------------------------------------*/ Anand Venkataraman - Systems group, Computer Center, Massey University, Palmerston North, New Zealand INTERNET: A.Raman@massey.ac.nz Ph: +64-63-69099 x7943 NZ = GMT + 12
gregg@cbnewsc.ATT.COM (gregg.g.wonderly) (10/02/89)
From article <11204@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn): > In article <3559@cbnewsc.ATT.COM> gregg@cbnewsc.ATT.COM (gregg.g.wonderly) writes: >>The best example is printing manual pages. My manual program does >>NOT provide a printing feature. Instead it provides the capability >>to return the path to the manual pages so that nroff/troff/whatever >>can be used to format it. > > Jesus, what's the difference between formatting a manual page to a > terminal and to a printer? Simple, the ".I" (or \fI) font change directive causes underlining in nroff, but italics in troff. If I prefer the italized version, I can get it. My point was that it is rediculous to wire in a printing environment or hook of some sort because it would probably be wrong or not provide all of the information that one needs (like I tried to point out above). UN*X has yet to become the proud owner of a standard printer interface/spooler. > You can't even tell whether I'm using > my terminal window as a port to access an attached printer or not. > I may also be using a Braille terminal, and would disappreciate > pagination. There are far more possible environments than you > can anticipate, which is why you should not hard-wire in limiting > environmental assumptions. Which is precisely why the printing feature is not there... Okay, maybe you don't see where I am comming from. The fact that the program returns you the place where the manual page resides means that you can have a tool (if not your own nroff macro package) format the manual to be compatible with your output device. I thought that the idea that you were pushing earliar was tools should do one thing and then each user can build their own conglomerates to go with the enviroment in which they work. > By catering to obsolete technology as your assumed "common case" > and insisting that better uses of the software will have to be > accommodated by additional programming effort, you're providing a > powerful disincentive to improve the computing environment! I was hoping that someone would say that! Is it not obvious that always relying on the users to build conglomerates (because the original tool was incomplete for the most used case) that are useful is what most people hate most about UN*X. You seem to be saying two things here. First you say use the tool idiology then you say put in the features that promote new technology. Can you clarify where you stand on this, I am confused. How many SYSV users are actually happy that ls(1) does not use -C by default? Does't most everyone that you know have an alias/script/own-version-of-ls.c that does make -C the default (or even like man, add -C when fd-1 is a terminal)? Everyone that I know does! By the time we get through inventing all of our own little customizations to incomplete tools, we can not make use of another UN*X machine without taking timeout to bring our toolkit with us. Frankly I don't like doing that, it wastes my time and disk space. # # Sigh, another solution to a tool that isn't... # # lf.sh # if [ -t 1 ]; then exec /bin/ls -CF "$@" else exec /bin/ls "$@" fi -- ----- gregg.g.wonderly@att.com (AT&T bell laboratories)
barnett@crdgw1.crd.ge.com (Bruce Barnett) (10/02/89)
I wrote:
>>IMHO the BSD solution was right.
Good thing I put the 'H' in there. Doug does make some good points. :-)
I must apologize for not really understanding Doug's initial argument.
I know he has a programmable bit-mapped terminal, so of course
his terminal driver can do paging.
But if Doug says that the pager should be a part of the generic
terminal driver, so that every terminal connected to a Unix system
can have paging built in the driver....
Yes I agree. That is the right way. I was not aware of any UNIX that
had this feature.
I still think BSD made the right choice at the time.
But I am a practical type, and would rather have a partial solution
instead of waiting 5 years for the correct solution.
I am ignorant of a generic tty driver (gad! that word is over-used a lot)
that supports the concept of paging for any terminal.
Richard O'Keefe mentions one (<2258@munnari.oz.au>) that is
enabled by typing "stty rows 0".
I consider that solution to be just as bad the the BSD solution,
because neither one is right.
Paging has nothing to do with the number of rows a terminal has.
For instance, I have on my frame buffer three virtual terminals (i.e. windows).
The first one has a scrollbar and the maximum number of lines saved
is 1000. The second is another one that I want an automatic pager.
The third one I do not want any paging.
The number of rows and columns for each terminal can be modified at
any time. I still want the pager and editor to react when I change
the window size. And this should work when the programs I am running
are on other machines on the network. If I executed man(1) on another
machine, and then changed the size of my window - man should
update the view of the manual page.
It seems to me there should be another flag in the iocty of the tty that
determines if paging should be done or not. Rows and columns
aren't the right choice.
I also don't understand how the paging should be handled.
I assume you are talking about a user down-loading into the STREAMS
tty driver the pager characteristics that the user wants.
You can't just download pg(1), more(1) or less(1) into the tty driver.
I am having trouble visualizing this pager in operation.
I log onto the system from home, and I am using an old VT100
terminal that I got for a very good price.
I type
man whatever
and the built-in pager comes in. What does it do? Does it give me
any feedback when it pauses? Does it beep? Or just hang?
Suppose I run a program that generates thousands of lines of data.
I read the first 30 lines and then want to quit. Does the terminal driver
tell the program it cannot write any more? I don't want it to crunch away
for another 15 minutes. But I want the shell to know it can write to the
terminal.
Suppose I typed
cat /etc/termcap
and while looking at the file, I wanted to examine another file,
or perhaps do a shell escape. Which process would spawn off a shell?
I cannot conceive of a single pager model that will work in all cases.
Maybe I still don't understand Doug's point. I apologize.
If Doug's pager won't work with an ANSII terminal,
then I DO NOT agree with Doug's model.
Sure, everyone should have a workstation on their desk.
But that's not the real world. If Unix is going to be successful,
it has to support the commercial market.
--
Bruce G. Barnett <barnett@crd.ge.com> uunet!crdgw1!barnettrichard@aiai.ed.ac.uk (Richard Tobin) (10/03/89)
In article <2258@munnari.oz.au> ok@cs.mu.oz.au (Richard O'Keefe) writes: >Because pausing every so often is a function of *terminal* output, >not a function of output in general, so it belongs ``near'' the terminal. Generally, I agree with this. To do it right, however, requires a little care. The terminal driver has to know, for example, what the terminal's clear-screen character is and what its line-wrapping characteristics are, otherwise it will lose track. General cursor addressing will have the same problem, but presumably a program doing that will disable the automatic paging. -- Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/03/89)
In article <2772@crdgw1.crd.ge.com> barnett@crdgw1.crd.ge.com (Bruce Barnett) writes: >Sure, everyone should have a workstation on their desk. >But that's not the real world. If Unix is going to be successful, >it has to support the commercial market. (a) I didn't suggest that one has to have a fancy workstation before pagination can be done right. However, if one does have one, then pagination done wrong definitely gets in the way. (b) I have never thought that the UNIX Bourne shell environment is one that should be pushed commercially as a naive-user interface. But it should be available for what are now known as "power users", and for them it is important to design on the toolkit (orthogonal, modular function) principle.
barnett@crdgw1.crd.ge.com (Bruce Barnett) (10/03/89)
In article <11209@smoke.BRL.MIL>, gwyn@smoke (Doug Gywn) writes: >(a) I didn't suggest that one has to have a fancy workstation before >pagination can be done right. However, if one does have one, then >pagination done wrong definitely gets in the way. Fine, but this doesn't answer the real question. You have stated that paging should be done in the device driver. You have not said how this would be implemented. Can you clarify this? -- Bruce G. Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/03/89)
In article <2786@crdgw1.crd.ge.com> barnett@crdgw1.crd.ge.com (Bruce Barnett) writes: >You have stated that paging should be done in the device driver. >You have not said how this would be implemented. >Can you clarify this? Actually, *I* said it should be done in the terminal; somebody else said it should be done in the terminal handler (loosely called the device driver) and explained how theirs worked. What we agreed on was that pagination rightfully should be dealt with considerably closer to the viewer, who has pagination needs, not in the applications that should perform orthogonal functions.
ok@cs.mu.oz.au (Richard O'Keefe) (10/03/89)
In article <2772@crdgw1.crd.ge.com>, barnett@crdgw1.crd.ge.com (Bruce Barnett) writes: > I wrote: >>IMHO the BSD solution was right. > I still think BSD made the right choice at the time. But versions of UNIX with paging in the terminal driver PRECEDED BSD 4.1. Nor was paging in the terminal driver a UNIX invention; it is a rather old technique. > Richard O'Keefe mentions one (<2258@munnari.oz.au>) that is > enabled by typing "stty rows 0". No, I mentioned on which was **DIS**abled by doing that. > Paging has nothing to do with the number of rows a terminal has. Yes it does. The pager needs to know how many lines of text it can display before it is time to stop and wait for the user to say s/he is ready for the next screenful. That number of lines is precisely the relevant number of "rows". The figure given to stty is not the number of rows the TERMINAL HAS but the number of rows the USER WANTS in a screenful. This is why you can set "rows" to a number other than the size of the terminal declared in the termcap or terminfo data base. > I also don't understand how the paging should be handled. > I assume you are talking about a user down-loading into the STREAMS > tty driver the pager characteristics that the user wants. What has STREAMS to say to anything? In the V.3 system I used, terminals weren't STREAMS things anyway. Paging in the terminal driver predates STREAMS by decades! I used EUUG V7 on an old "Bantam" terminal, about as simple a 24-by-80 terminal as ever had cursor addressing. > Suppose I run a program that generates thousands of lines of data. > I read the first 30 lines and then want to quit. Does the terminal driver > tell the program it cannot write any more? You type your interrupt character, just like always. THAT'S THE POINT. You don't have to wire special stuff into every single program to make it drop dead when the user wants to kill it. You can, if you wish, put special stuff in to prevent this. Similarly, there is nothing special about 'man'. Ok, so it generates a modest amount of output. So do thousands of other programs. The point is that if paging is built into the terminal driver (thank you whoever put the feature into European Unix User Group V7 Unix, thank you whoever put it into SunOS), then it is *automatically* available to *every* program and they all look the same to users. You don't get confused by one program picking using $PAGER, another program looking in ~/.foorc, another always using more, yet another one having its own pager built in which isn't quite the same, and fifty thousand others not using any pager at all. > I cannot conceive of a single pager model that will work in all cases. What do you mean, work? I can conceive of a simple pager model which meant that unless I deliberately ask for it to be switched off, I never have to re-run a program because the information I want scrolled off the top of the display before I was ready for it. I can conceive of it because I was using it in UNIX nearly ten years ago. The old BSD & System V scheme where normal behaviour was for information to always fall off the top of your terminal can't really be said to work in ANY case. And the EUUG V7 scheme would get out of the way if you asked it to, and a program like 'more' could run on it without even knowing that the terminal driver could page too. And if you never wanted terminal paging, you could just put the command to disable it in your .profile. > Sure, everyone should have a workstation on their desk. > But that's not the real world. If Unix is going to be successful, > it has to support the commercial market. The real world is that paging worked in a reasonably popular variant of V7 UNIX on plain ASCII terminals ten years ago; for *every* program.
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (10/03/89)
man works in a way which is convenient most of the time. I would rather type man | cat >/dev/tty309 on the very rare occasion when I might send output to an unspooled device, but I surely don't want to type man | more three or four times a day to get paged output. I don't want to have to fool with an alias or shell scipt or macro or program or anything else which people suggest as a way to get around it. One of the things I've learned over the years about human interface design is to "let the computer count the beans." In the case of man it makes good human engineering sense the way it works now. Maybe if a few more things worked that way people wouldn't have the false idea that UNIX is unfriendly. Anyone who would like to have to pipe everytime they run man must be really upset that ls eliminated the need to pipe through sort to get a listing of files in order. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
jhood@biar.UUCP (John Hood) (10/04/89)
In article <11211@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: [following up on this considerable thread] >Actually, *I* said it should be done in the terminal; >somebody else said it should be done in the terminal handler >(loosely called the device driver) and explained how theirs worked. >What we agreed on was that pagination rightfully should be dealt >with considerably closer to the viewer, who has pagination needs, >not in the applications that should perform orthogonal functions. (playing devil's advocate here) I can respect Doug's position; it has validity. But this argument is beginning to sound a bit like the question of "where do we put command-line editing/history?" If we put it in the kernel, a la the BSD tty driver, then you get the feature everywhere, but you may not be able to implement it well or properly for all cases, and the user will find it difficult to replace the feature with one they like. If you make it a user-level process, then it is much easier to change or enhance or remove. Look at the features of 'less', which would be impossible for a terminal driver or intelligent terminals. Of course, a user-level pager will not work right in all cases either. Consider these two situations: 1) more's output being fed to a printer /dev/lp0 2) A smart terminal or driver monitoring the considerable, but slow, output of tail watching some process or sar or vmstat in a background window Another facet to this issue is that man is one of the few programs that automatically pipes output through a pager. --jh-- John Hood, Biar Games snail: 10 Spruce Lane, Ithaca NY 14850 domain: jhood@biar.uu.net bang: anywhere!uunet!biar!jhood Looking for a OS hacking programming job in the Ithaca area...
les@chinet.chi.il.us (Leslie Mikesell) (10/04/89)
In article <11211@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >Actually, *I* said it should be done in the terminal; >somebody else said it should be done in the terminal handler >(loosely called the device driver) and explained how theirs worked. >What we agreed on was that pagination rightfully should be dealt >with considerably closer to the viewer, who has pagination needs, >not in the applications that should perform orthogonal functions. But the sole function of pg/more/etc. is to act as a handy interface for the user based on a certain amount of knowledge about the viewing device. Thus the appropriate thing to do is to modify the pagination filters to know about your device (or device driver) and output accordingly. Then everything remains orthogonal. Les Mikesell
dhesi@sun505.UUCP (Rahul Dhesi) (10/04/89)
In article <2281@munnari.oz.au> ok@cs.mu.oz.au (Richard O'Keefe) writes: >Similarly, there is >nothing special about 'man'. Ok, so it generates a modest amount of output. >So do thousands of other programs. The point is that if paging is built >into the terminal driver (thank you whoever put the feature into European >Unix User Group V7 Unix, thank you whoever put it into SunOS), then it is >*automatically* available to *every* program and they all look the same >to users. Are you suggesting that the pager built into the tty driver be able to (a) translate control sequences into highlighting/reverse video/underlining, (b) save the last n screens of output to allow backward paging, (c) invoke your editor on the file being viewed when you type "v", (d) give you a help screen when you type "h", (e) change the tab expansion setting while viewing a file (and remember to change it back when you are done), etc.? That would be an awfully complex tty driver. But if you want to keep the tty driver simple, you need a separate pager anyway. And "man", wanting at least (a) and (b) above, will probably still want to use that. I think the best solution is for the people who don't want man to do paging is to do something like: alias man 'man \!* | cat' or man() { man $* | cat; } Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com> UUCP: oliveb!cirrusl!dhesi
ok@cs.mu.oz.au (Richard O'Keefe) (10/04/89)
In article <926@cirrusl.UUCP>, dhesi@sun505.UUCP (Rahul Dhesi) writes: > In article <2281@munnari.oz.au> ok@cs.mu.oz.au (Richard O'Keefe) writes: > >Similarly, there is nothing special about 'man'. > Are you suggesting that the pager built into the tty driver be able to > (a) translate control sequences into highlighting/reverse > video/underlining, Translate *what* control sequences? There is no UNIX standard for terminal control sequences in text files. "more" will turn underlining (the documentation is really very bad here, is "_^Hx" supposed to be a "UNIX standard" for underlined/highlighted text that I am entitled to rely on, or is it an Nroff/Man-specific HACK)? As a matter of fact, I often examine manual pages with a text editor and it is a major pain that "man" uses this "feature"; I alway have to delete the wretched "_^H" sequences before I can read the file. If a program is supposed to use standin/standout, it should probably be using 'curses' (or possibly generating Display Postscript (:-)). In strict point of fact, more(1) has an option "-f", and the manual page says that this option "is useful when lines contain nonprinting characters or escape sequences, such as those generated when nroff(1) output is piped through ul(1)." That is to say, more(1) DOES NOT translate control sequences properly! It appears that it only understands "_^H" and "^L". > (b) save the last n screens of output to allow backward paging, The 4.3BSD more(1) program has the "b" and "^B" commands which do this. But ONLY when it is are reading from a file. (In V7, when I wanted this facility, which was almost never, I used a command called "p" which also did spelling correction on the file name. Now "p" would let you back up in a pipe.) Try "ls | more", and the ^B command just beeps at you. The 4.1BSD more(1) didn't have the "b" or "^B" commands at all, and if memory serves me correctly, neither did the 4.2BSD one. If it was acceptable for more(1) not to provide backing up, and if it remains acceptable for more(1) to back up only some of the time, then I don't see why a simple pager in the terminal driver should do so. BEWARE: the printed copy of the 4.3BSD more(1) manual page that I checked has the "^" characters missing, e.g. the "^D" command looks as though it is "D". Another edition of that page says b Same as ^B (CTRL-D) which I found confusing ^ (sic). If you are going to view a file, rather than read the output of a program, why not just look at it with an editor? That way you get to use one search notation instead of having to remember two (the patterns in more(1) are not exactly like the ones in VI). (c) invoke your editor on the file being viewed when you type "v", WHAT file? I am talking about a form of flow control (it might be in the terminal, as Doug Gwyn suggested, or in the terminal driver, as it was in EUUG V7). I'm talking about something that will let me use an interactive program like Lisp and type a Lisp command which generates a couple of hundred lines of output and read the output before it flashes off the top of the screen. "more" and "less" and "pg" are utterly useless in that context. There IS no file. (d) give you a help screen when you type "h", What help do I need? If I need a help screen just to read the output from something like (pp generated-function) then I have a seriously unusable system. Do you normally use a terminal driver that gives you a help screen when you type "h" so that it can remind you that ^S is cancelled by ^Q? Why is it so hard to remember that ^Q will resume output paused by screen filling just as ^Q will resume output paused by ^S? (e) change > the tab expansion setting while viewing a file (and remember to change > it back when you are done), etc.? more(1) doesn't do that either. > But if you want to keep the tty driver simple, you need a separate > pager anyway. And "man", wanting at least (a) and (b) above, will > probably still want to use that. I think it's fair to confine my remarks to more(1) rather than less(1) or pg(1), because the original claim was that Berkely did a great thing by making man(1) -- but not other programs -- pipe its output into a pager. Let's summarise: (a) more(1) does not handle standard escape sequences. There is a program which translates nroff's underlining into terminal escape sequences, namely ul(1). (b) more(1) used not to let you back up a screenful in a file. It still doesn't let you back up in a pipe, and that case is relevant to man(1) because manual pages from sections 4--8 are not cached in /usr/man/cat?. In fact, man(1) goes to the trouble of putting other manual pages in a /tmp file, just so that more(1) can back up in them. (c) more(1) can't do it unless you are reading a file; in that case you might as well use an editor. (d) No help screen is *needed* for a pager in the terminal or terminal driver. It is always there, so you remember ^Q or or whatever in just the same way you remember ^W for deleting words. (e) Is something more(1) does not do. My point is not that paging ought to be DISabled for man(1). My point is that it should be possible for someone who wants it to ENable paging for EVERY program that writes to the terminal. Example: I have a program which will print several screens of help, on request. In EUUG V7, that was simple, I just wrote myself a little function to copy a file to the screen, and paging was automatic and painless. No forks required. In 4.1BSD, I had to change it to sprintf(command, "/usr/ucb/more %s", filename); system(command); Then to make it portable to System V, I had to do static char *pager = #ifdef SYS5 "/usr/bin/pg"; #else #ifdef BSD "/usr/ucb/more"; #else "/bin/cat"; #endif #endif sprintf(command, "%s %s", filename); system(command); -- of course, I had to hope that the file name as installed would not contain layout characters or shell meta-characters. Then I learned about the newly developing PAGER convention, and had to change it to sprintf(command, "${PAGER-%s} '%s'", filename); This level of complexity did not enchant me. Still less was I enchanted when people started moving pg and more around in the file system. (They have to be absolute to be sure of getting the right program even when the program's caller uses a different $PATH. Still, it was feasible for me to write this function once and use it whenever I wanted to display a file at the terminal. And it does provide more functionality than straight cat(1), no question. That's not the problem. The problem is that I am interested in INTERACTIVE programs which can generate lots of output. It is not feasible to set up a "more" pipe because they input and output have to be synchronised. What is the choice? The choice is (a) run such a program under an editor like Emacs (hope you have lots of memory) (b) run such a program under a program like ILE, suitably hacked to control output flow, or (c) let the end user watch his output flow off the top of the screen and frantically type ^S in the vain hope of catching some. Note carefully what the tradeoff is here: a small increase in the complexity of the terminal driver (basically, keep track of how many lines have been written to the screen since the last input, and when it equals a certain number, pretend a ^S was received) is one choice; the other is a LARGE increase in the cost of every program that knows it is writing to a terminal ('more' is enormously larger than the tty driver, and 'emacs' is much larger than 'more'). Having *simple* paging built into the terminal or terminal driver doesn't stop anyone using a pager program if they want to. It doesn't even stop people building $PAGER into selected programs if they want to, not even man(1). But it *would* give everyone a chance to read the output of every program, even interactive ones, without requiring extra processes.
barnett@crdgw1.crd.ge.com (Bruce Barnett) (10/06/89)
In article <2281@munnari.oz.au>, ok@cs (Richard O'Keefe) writes: >> Richard O'Keefe mentions one (<2258@munnari.oz.au>) that is >> enabled by typing "stty rows 0". > >No, I mentioned on which was **DIS**abled by doing that. Darn! Sorry for the typo. >> Paging has nothing to do with the number of rows a terminal has. >Yes it does. Darn! Darn! I ment to say that you should be able to change the state of the paging without changing the size of the window. See below. >The pager needs to know how many lines of text it can >display before it is time to stop and wait for the user to say s/he >is ready for the next screenful. That number of lines is precisely >the relevant number of "rows". But how can I resize a window, changing the rows and columns, but still retain the flag that I do or do not want paging? The rows and columns information should not specify if paging should or should not be done. Perhaps a 'stty page' is needed. Or else rows should not be used to determine the current size of a window. (It doesn't on Sun's. It merely reflects the current state.) >What has STREAMS to say to anything? In the V.3 system I used, terminals >weren't STREAMS things anyway. Paging in the terminal driver predates >STREAMS by decades! I used EUUG V7 on an old "Bantam" terminal, about >as simple a 24-by-80 terminal as ever had cursor addressing. Guilty of ignorance. Perhaps another solution in a future version of Unix is to attach a process to your /dev/stdout and /dev/stdin. Something like a pseudo TTY in that it appears to be the stdin and stdout to all programs doing terminal I/O to the default device. This would allow a user to customize his/her handling of the "default stdout" and do so in a way that does not require special hardware. If such a mechanism exists, then the pager could have all of the abilities of the current programs, and even support new ideas. I don't know if I would like it of not, but you could have your pager automatically pop up a new window everytime the data being displayed was more than a certain size. >The real world is that paging worked in a reasonably popular variant of >V7 UNIX on plain ASCII terminals ten years ago; for *every* program. What every happened to this feature? Why did it disappear from the two main strains? -- Bruce G. Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
perry@ccssrv.UUCP (Perry Hutchison) (10/06/89)
In article <2281@munnari.oz.au> ok@cs.mu.oz.au (Richard O'Keefe) writes: > The point is that if paging is built into the terminal driver (thank you > whoever put the feature into European Unix User Group V7 Unix, thank you > whoever put it into SunOS), then it is *automatically* available to > *every* program and they all look the same to users. I think this actually refers to the "Page Mode" of a "tty" window. Strictly speaking, that is in Suntools rather than in SunOS itself, although there may be some kernel support involved. It certainly works well, and I see no reason why such a scheme couldn't be much more widely adopted. Unfortunately, the Suntools implementation is incomplete. It works fine as long as the window is connected to a local process, but if I rlogin to another node it acts as if I had disabled page mode and I have to fall back on "more" or ^S/^Q (which do still work).
ok@cs.mu.oz.au (Richard O'Keefe) (10/06/89)
In article <2909@crdgw1.crd.ge.com>, barnett@crdgw1.crd.ge.com (Bruce Barnett) writes: > But how can I resize a window, changing the rows and columns, > but still retain the flag that I do or do not want paging? > Perhaps a 'stty page' is needed. Well, you _couldn't_ change the size of the window on a terminal, so this problem never occurred to anyone. A separate "page" option would appear to be the right approach. > Perhaps another solution in a future version of Unix is to > attach a process to your /dev/stdout and /dev/stdin. Something like a > pseudo TTY in that it appears to be the stdin and stdout to all > programs doing terminal I/O to the default device. It has been pointed out to me that paging in SunOS is a function of "shelltool", which works in much that fashion. It has also been explained to me that in the X systems I've seen (where I thought paging was a function of "window managers") it is in fact a function of "terminal emulators", which I believe work in much that fashion. > I don't know if I would like it of not, but you could have your pager > automatically pop up a new window everytime the data being displayed > was more than a certain size. Some Apollo commands do pop up windows; I think man(1) does this. > What every happened to this feature? Why did it disappear from the two > main strains? The "E" in "EUUG V7" stands for "European". The feature was not present in the USA original. Where the feature was first invented I don't know; VM/CMS does something similar so it _must_ be an old idea.
wsmith@mdbs.UUCP (Bill Smith) (10/06/89)
What exactly is meant by "putting the paginator in the kernal or terminal"? To me that brings up visions of an IBM mainframe and 3270 terminals where one is *forced* to use the pager, even when you only want to scan the output and do not need to examine every line in glorious detail. I don't want the cure to be worse than the disease. Bill Smith pur-ee!mdbs!wsmith
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/07/89)
In article <1456@mdbs.UUCP> wsmith@mdbs.UUCP (Bill Smith) writes:
-What exactly is meant by "putting the paginator in the kernal or terminal"?
-To me that brings up visions of an IBM mainframe and 3270 terminals where
-one is *forced* to use the pager, even when you only want to scan the
-output and do not need to examine every line in glorious detail.
-I don't want the cure to be worse than the disease.
Nobody suggested implementing pagination stupidly. (Except those who
think random applications should have pagination built in.)
For example, you could pop up the window control menu and toggle between
scroll/page mode for any window, at any time.ok@cs.mu.oz.au (Richard O'Keefe) (10/07/89)
In article <1456@mdbs.UUCP>, wsmith@mdbs.UUCP (Bill Smith) writes: > What exactly is meant by "putting the paginator in the kernel or terminal"? Precisely that. If you want to skip all around a document, you can use a screen editor, and there is no problem. The problem is that you can send a stream of bytes to a terminal (and the terminal can display them) faster than a human being can read them, so the output rate needs to be controlled by the individual human being doing the reading. This is not specific to any one program, it is a problem that applies to every single program. (It even applies to programs that can generate only one line of output; run such a program in a shell loop and you're watching information flash off the top of the screen in no time.) One method of controlling the output rate is explicit XON/XOFF keystrokes from the user. The snag is that even when I type fast enough, the computer at the end doesn't _listen_ soon enough. VT100s had a "slow scroll" feature toggled by a key on the keyboard where the text would slowly and smoothly scroll up the screen, XON/XOFF being sent automatically by the terminal. I hated it, because I don't like reading moving text, but it works, and it's a paging-type feature in the terminal. Another flow control method is for the terminal to send ^S as soon as it has a screenful and then wait for the human being to type ^Q. Or the terminal driver can do it if the terminal can't. Or the terminal emulator can do it if the driver can't. > To me that brings up visions of an IBM mainframe and 3270 terminals where > one is *forced* to use the pager, even when you only want to scan the > output and do not need to examine every line in glorious detail. It has been repeatedly stated that the feature as present in EUUG V7 UNIX (the Heriot-Watt terminal driver) and SunOS (the SunView terminal emulator) is very easy to disable. > I don't want the cure to be worse than the disease. The feature was demonstrably cheap: EUUG V7 ran on PDP-11s without separate I/D, and didn't cause kernel bloat. It could be disabled so that you never knew about it. How is that worse than the disease?
guy@auspex.auspex.com (Guy Harris) (10/08/89)
>I think this actually refers to the "Page Mode" of a "tty" window. As he noted, it was. >Strictly speaking, that is in Suntools rather than in SunOS itself, Well, it depends on what you mean by "SunOS itself"; SunView is shipped with SunOS, so it could conceivably be considered a part of SunOS. >although there may be some kernel support involved. None, other than the pseudo-ttys that make (user-mode) terminal emulators like "shelltool" and "xterm" and the like possible. >Unfortunately, the Suntools implementation is incomplete. It works fine as >long as the window is connected to a local process, but if I rlogin to >another node it acts as if I had disabled page mode and I have to fall back >on "more" or ^S/^Q (which do still work). It turns Page Mode off when the tty driver goes into uncooked mode, which "rlogin" does, as well as other programs like "vi". I think the intent is to avoid confusing programs that go into uncooked mode....
ado@elsie.UUCP (Arthur David Olson) (10/08/89)
> Well, you _couldn't_ change the size of the window on a terminal, so > this problem never occurred to anyone. Actually, you could (and still can) change the number of columns on a VT100, which has "80 column mode" and "132 column mode." -- To understand Sun's corporate culture look at the vi source code. Arthur David Olson ado@alw.nih.gov ADO is a trademark of Ampex.
richard@aiai.ed.ac.uk (Richard Tobin) (10/11/89)
In article <713@ccssrv.UUCP> perry@ccssrv.UUCP (Perry Hutchison) writes: >I think this actually refers to the "Page Mode" of a "tty" window. Strictly >speaking, that is in Suntools rather than in SunOS itself, although there >may be some kernel support involved. Providing it in suntools (actually shelltool) is essentially providing it in the terminal - the terminal emulator sits on the far side of a pseudo- terminal, and the program typically doesn't notice that it isn't talking to a real terminal. The terminal emulator does have some advantages over the real terminal, since it can detect whether the terminal is in raw mode (for example), and could change its behaviour accordingly. It would be perfectly possible to use a pseudo-terminal to construct a paging filter; indeed it could do a lot more (line-editing for example). -- Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin