doug@hcr.UUCP (Doug Moen) (12/26/83)
The choice of whether to use a command language or a menu
system, long or short command names, what kind of automatic
command completion (if any) to implement, etc, evidently
depends on a number of factors, such as the type of terminal
hardware you are supporting, the size and stability of the
command set, and the background of the user population.
On the Unix systems I am familiar with, most terminals
are 24x80 crts running at 9600 baud, with a handful of slower
dialup ports, and some hardcopy terminals. There are
hundreds of commands available from the shell, and the
command set changes at a perceptible rate as new commands
get added, and old commands become obsolete.
With all of those commands, even experienced users can have
trouble remembering the name or syntax of a command,
and I can remember being completely overwhelmed when I first
started learning Unix.
What's the solution? Menu systems tend to be slow and
awkward given the available terminal hardware. A consistent,
orthagonal system of command names and options (as proposed
by Ian! Allen) would help, but that is certainly not the
whole solution, because often you know what you want to do
without knowing what commands are available to do it.
What I would most like to see is a better system of
organizing, presenting, and accessing online documentation.
The 'man' command is far too slow, and it's far too difficult
to find the information you want, even if you have the
Berkeley 'apropos' command. I can remember trying in vain
to retrieve the documentation for strcmp(3), until a guru
told me that the information I wanted was in 'man 3 strings'.
And I remember helping a fellow who wanted to know how
background jobs worked. He had tried 'apropos background',
'apropos jobs', even 'apropos "&"', all without success,
and I had to tell him that the information was buried deep
within 'man 1 csh', mixed in with mountains of other stuff.
Here are my thoughts for reforming the man command:
- Documentation should be organized as a tree.
In particular, large documents such as csh(1) should
be split into trees, with separate entries for each
built in command, and for discussion of topics like
shell variable expansion, background jobs, etc.
- Each document should have a list of keywords associated
with it. A command similar to apropos is provided to
search for documentation by keyword. This could be
implemented by adding a .KW macro to the Nroff -man
macro package.
- The man command ought to be *fast*. Under Berkeley
Unix, there is an option for storing preformatted
copies of all the documentation, but you can't really
do that on systems with small disks. My solution is
to write a special-purpose C program that formats manual
pages into crt-viewable copy without the overhead of
invoking 'nroff -man'.
Does anyone know of a better way of providing online
documentation and help facilities than this?
Doug Moen