9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Uriel <uriell@binarydream.org>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] Capitalization in man pages.
Date: Thu,  8 Dec 2005 04:55:48 +0000	[thread overview]
Message-ID: <20051208045548.GH6804@server4.lensbuddy.com> (raw)
In-Reply-To: <ee9e417a0512072010i32939f94k15d328225ab36af0@mail.gmail.com>

On Wed, Dec 07, 2005 at 11:10:22PM -0500, Russ Cox wrote:
> Please don't rewrite all the man pages unless you first establish the
> value in doing so.  Converting from one troff macro package to another
> does not on first glance seem to offer any benefit at all.  In fact,
> things like man2html would then have to be updated, and no doubt all
> the errors introduced would have to be tracked down, and so on.  It
> hardly seems worth it, especially considering that the outward
> appearance would remain the same.
I partially agree, I see no reason to change macro package, but I do
think the outward appearance has to be changed and made consistent.
 
> On the other hand, checking that the man pages reflect
> reality (command line arguments, function signatures,
> and so on) would be genuinely useful.  I encouraged some
> others to do this a few years ago and they formed a group
> called the Plan 9 Documentation Task Force and fixed a
> few man pages but then I think they lost interest.

We looked at this some time ago, it's a rather tedious and long task,
but I still think it's worth doing(and it's in my TODO, maybe for when I
retire...)

One of the issues we found was that while the quality of the man pages
in general was very good, the way they structured information was very
inconsistent, with for example at least four different ways of listing
command line flags.

When we asked about this russ considered it overambitious to reword
every man page to have the same format and that it might "unnecessarily
remove the original authors style".

The style certainly deserves preserving because it's clear and to the
point, hats off to Rob that did an excellent job.

But I think it would be very good to have a set of clear guidelines
blessed by the original(or current) authors, for how pages belonging to
each section should be structured, and then make sure that every page
follows them. Some macros that help enforce this wouldn't hurt either,
but IMHO are optional.

For details about this effort see:
http://plan9.bell-labs.com/wiki/plan9/Man_pages_review/

> I made a bunch of updates to the plan9port man pages
> when I did the "first fully documented release" a year ago.
> Diffing those against the Plan 9 ones would be a good start.

Oksel did quite a bit of work on this, but I think he found it rather
frustrating. It was my hope that further deviations would be avoided in
the future, but I don't know what is the current state of things.

My suggestion at the time was to have identical man pages for p9p and
Plan 9, having an extra section describing p9p-only components, and
having a "PLAN 9 FROM USER SPACE" header describing any other
differences in individual man pages. Russ didn't like this.

uriel

P.S.: Some relevant quotes from email russ sent when this was being
discussed(BTW, I just double checked cfs(4) and the dashes for the
options are still missing both with man and man -P):
---
> We have not started the man pages review because we are unsure how much
> we should change, it would be nice to make the formating and structure
> of all man page more clear, consistent and uniform, but maybe we should
> limit ourselves to only fix obvious errors and omisions instead?

what about the formatting and structure do you believe is not clear,
consistent, and uniform?  (i can think of things, but i'd like to hear what
you think they are.)

i think it doesn't make sense to rewrite the man pages.  instead i think the
effort is much better spent making sure that everything is documented and
that the docs are up to date.  one good start would be to diff the plan9port
and the plan 9 man pages.  where they differ, the plan9port ones are newer
and should probably be copied back to plan 9.

there are lots of conventions for the writing of man pages, about formatting
and structure.  checkman.awk checks some of these, in particular the ordering
of sections, making sure that cross-referenced pages actually exist, and so
on.  other conventions are harder to check, like which names are in which
fonts, but those are pretty consistent.  see man(6) for details.
---
> most obviously: options (or flags).  some pages list flags in orderly
> fashion such as ls(1).  others do it likewise, but have no dash in
> front of the flags (e.g. cfs(4)).  this might be related to
> authorship.

huh?  cfs(4) has all the appropriate dashes.  i think maybe you are
looking at some crappy html version of the pages that occasionally omits
dashes.  try using man -P instead.

> yet other pages have no list of options but mention their meaning
> somewhere in the text (and then some even without dashes like
> tail(1)).
> the cfs(4) case is mostly aesthetic, for the tail(1) case it is hard
> to see the option you're looking for at a glance.

i agree that in some egregious cases, the options should be made more
obvious.  the f and r flags in tail(1) are a good example of this.

all pages should explicitly list all the options in the SYNOPSIS section
or should at least say [ options ] if the list is too long.

> but, it is better to just concentrate on accurate man pages.  we'll
> also look into plan9ports man pages (have not really used plan9ports).

yes.  i'd definitely prefer to concentrate on getting the man pages
accurate, and then as a second thing maybe worry about things like how
the options are presented.
---


  reply	other threads:[~2005-12-08  4:55 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-05 12:07 [9fans] irc answers - man and memmove Russ Cox
2005-12-05 19:07 ` Sascha Retzki
2005-12-06  1:09 ` Paul Lalonde
2005-12-06  1:14   ` Rob Pike
2005-12-06  1:17     ` Paul Lalonde
2005-12-06  1:48       ` Russ Cox
2005-12-07  9:57         ` Gorka guardiola
2005-12-07 10:41           ` Lucio De Re
2005-12-06  1:22     ` erik quanstrom
2005-12-06  6:31     ` [9fans] Capitalization in man pages Lyndon Nerenberg
2005-12-06  7:01       ` Rob Pike
2005-12-06  9:44         ` Charles Forsyth
2005-12-06 11:01         ` Lyndon Nerenberg
2005-12-06 11:17           ` Charles Forsyth
2005-12-06 11:27             ` Lyndon Nerenberg
2005-12-06 11:12         ` Lyndon Nerenberg
2005-12-06 11:18           ` Lucio De Re
2005-12-06 12:22         ` Lyndon Nerenberg
2005-12-06 12:32           ` Charles Forsyth
2005-12-06 12:40             ` Lyndon Nerenberg
2005-12-06 13:02             ` Lyndon Nerenberg
2005-12-06 13:41               ` Charles Forsyth
2005-12-06 13:54                 ` Lyndon Nerenberg
2005-12-06 14:30                   ` John Stalker
2005-12-06 18:11                     ` Charles Forsyth
2005-12-06 18:31                       ` Rob Pike
2005-12-08  3:58                         ` Lyndon Nerenberg
2005-12-08  4:10                           ` Russ Cox
2005-12-08  4:55                             ` Uriel [this message]
2005-12-07  3:56                       ` Jeff Sickel
2005-12-06 15:57               ` jmk
2005-12-07  0:11                 ` geoff
2005-12-07  0:17                   ` Francisco J Ballesteros
2005-12-07  0:22                   ` Steve Simon
2005-12-08  3:55                 ` Lyndon Nerenberg
2005-12-06 12:46         ` erik quanstrom
2005-12-06 15:02           ` Brantley Coile

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20051208045548.GH6804@server4.lensbuddy.com \
    --to=uriell@binarydream.org \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).