How does man know?

[Richard O'Keefe]

In article <926 at cirrusl.UUCP>, dhesi at sun505.UUCP (Rahul Dhesi) writes:
> In article <2281 at munnari.oz.au> ok at 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.