How does man know?

Richard O'Keefe ok at cs.mu.oz.au
Sat Sep 30 18:50:44 AEST 1989


In article <2674 at crdgw1.crd.ge.com>, barnett at 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.



More information about the Comp.unix.questions mailing list