Re: General complaint about GNU's preference for "info" versus "man"

[Eli Zaretskii]

> From: address@hidden
> Date: Fri, 21 Apr 2006 13:56:26 -0700
> 
> Man pages should be complete and should also be the primary source of 
> online documentation, not "info".

This assertion needs to be backed up by some arguments; it's not an
axiom.  I could postulate with the same degree of success that ``Info
manuals should be the primary source of on-line information, not
"man"''.  I will now try to show _my_ arguments for that.

My arguments are that Info manuals are a superset of man pages, in the
sense that they include the man-style description of how to invoke the
programs and what are their command-line options.  This man-style
description is easily reached by the command bound to the `I' and `O'
keys inside the Info reader, and by the --usage command-line option
from the outside.  In addition to this description, which should
satisfy what a man-accustomed user is looking for, an Info manual
includes much more documentation that is important for first-time
users (and for large and complex packages, such as Make and Emacs,
even for second- and third-time users).  Such documentation cannot be
added to a man page, because a man page is a linear document devoid of
any structure and cross-referencing facilities, and doesn't support
any efficient search features (such as the index search).

These are the reasons I think the Info system is superior to man
pages; what are your reasons for the opposite opinion, remains to be
seen.

> Only when I started using Linux did I come across the reference (from 
> within the manpages) to "info" for more complete information.  I don't 
> know who originally decided to encourage this dichotomy, but whoever it 
> was should have known better (and perhaps should be beaten...).  It is 
> counterproductive to have two distinct and seperate sets of information 
> for the same command

Yes, it goes without saying that it's is counterproductive to have two
separate sets of information.  However, whoever decided to supersede
man pages with the Texinfo system (I think that was RMS, but I might
be mistaken) did not intend to have two sets, they meant to have only
one set--the Info manuals.  The fact that the dichotomy exists is not
because it was planned, but because some of the developers and
sysadmins voted with their feet.  (At least in the GNU Project, the
original plan is still alive and kicking, and the man pages are
nothing else but lip service; the real and the _only_ decent source of
user information are the Info manuals.)

> The fact is that almost everyone, even the proponents of "info", at
> times refers to the ubiquitous manpages.

For some value of ``refer to'', yes.  It is not a good idea to be in
denial of the facts of reality, which is that some (actually, quite a
few) packages don't have Texinfo documentation.  To be useful with
such packages, the Info reader was taught to display the man page, if
that's the only available documentation.  In fact, even when it
displays the man page, the Info reader does better than your
garden-variety man-page browser by creating cross-references out of
the "SEE ALSO" sections--you can TAB to them and press RET on them,
and read the referenced man page.  I wonder how many Info bashers even
know about this feature.

Anyone who uses man pages for a package that _does_ have an Info
manual cannot pass as a ``proponent of "info"'' in my book.

> Their everpresence is comforting, and in fact required, for us Unix
> users.

Again, it would be good to have some rational arguments for this.

> Please, GNU guys, come to your senses and just put *all* of the "info" 
> back into the manpages.

That would create humongous monolith man pages, which are impractical
as efficient documentation, because the only feature I have in a man
page browser to find specific piece of information is the browser's
search command.  For example, even for a medium-size program such as
Make, the manual is 520KB; try reading that with a pager such as
`more' or Less.

So, at least for me, thanks, but no, thanks.