9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Ethan Grammatikidis <eekee57@fastmail.fm>
To: 9fans@9fans.net
Subject: Re: [9fans] Proposal*: A Cousin for man(1)
Date: Sun, 28 Jun 2009 14:16:50 +0100	[thread overview]
Message-ID: <20090628141650.955191cf.eekee57@fastmail.fm> (raw)
In-Reply-To: <9f8d13d5d9d4e5731836b25aed002bf1@mail.nanosouffle.net>

On Sun, 28 Jun 2009 03:31:15 -0700
Akshat Kumar <akumar@mail.nanosouffle.net> wrote:

> Plan 9 manuals are known to be concise, and most definitely the first
> source of information for many of us.  It is only after consulting the
> man pages that we go on to further references, which often happen to
> be more definite or at least in-depth sources of information, such as
> the papers found in /sys/doc.  Of course, this isn't always the case,
> as many Plan 9 experts cite section 5 as "the most authoritative
> 'specification' of the 9P protocol"[1].
>
> But this nature of intro-, or even rudiments-, first usage of man(1)
> can be further developed.  A companion, cousin, or - for the sake of
> this proposal - ese(1) can perhaps guide the user through only the
> most basic information regarding the point of inquiry.  It would show,
> for example, only sample usage cases of the basic Plan 9 tools, with
> appropriately labeled special cases where applicable, but not a word
> more.  Likewise, ese(1) could present, as a companion to the section 5
> manual pages, the outline of some 9P file server code, showing, e.g.
> places where proper datastructures are paramount and common mistakes
> abound.  Thus, man(1) would fall somewhere between ese(1) and the
> docs (/sys/doc), such that every ese(1) inquiry would point to some
> relevant man(1) page (with irrelevancies sprinkled about).
>
> For the many Plan 9 contributors spending away the better parts of
> their youthful days on creating new tools/applications, an ese(1)
> could prove to end the solitude of their work by providing a means
> with simpler standards than man(1) by which to officially convey, in
> the most basic sense, the purposes/usages/applications of their
> contributions.

This ese would be much more valuable on a Gnu/Linux box. As it is, those man pages which are overly long could have summary pages: venti-summary, etc. Shorter pages which seem to require time may just need to be reformatted more in the style of gnu pages, or possibly a slightly better style could be devised.

>
>
> Best,
> ak
>
> [1] http://9p.cat-v.org/documentation
>
> * A proposal because the general hierarchy need be amended: the
> introduction of /sys/ese. Alternatives welcome.
>
>


--
Ethan Grammatikidis
The lyf so short, the craft so long to lerne. -- Chaucer



      parent reply	other threads:[~2009-06-28 13:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-28 10:31 Akshat Kumar
2009-06-28 11:39 ` yy
2009-06-28 14:31   ` Lyle Bickley
2009-06-28 15:11     ` hiro
2009-06-28 17:29       ` Lyle Bickley
2009-06-28 13:16 ` Ethan Grammatikidis [this message]

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=20090628141650.955191cf.eekee57@fastmail.fm \
    --to=eekee57@fastmail.fm \
    --cc=9fans@9fans.net \
    /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).