Disgusting kernel hack

[Mark Brader]

    "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 Brader