public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: CaT <cat@zip.com.au>
To: rich-paul@rich-paul.net
Cc: jbuck@Synopsys.COM, schwab@issan.cs.uni-dortmund.de,
	pfeifer@dbai.tuwien.ac.at, psycho@albatross.co.nz,
	oliva@dcc.unicamp.br, cat@zip.com.au, egcs@egcs.cygnus.com
Subject: Re: (Getting rid of) man pages
Date: Sat, 24 Apr 1999 00:50:00 -0000	[thread overview]
Message-ID: <199904240743.RAA05169@zipper.zip.com.au> (raw)
In-Reply-To: <Pine.LNX.4.05.9904240317070.19454-100000@deepthought.rich-paul.net>

rich-paul@rich-paul.net wrote the following:
> 
> On Fri, 23 Apr 1999, Joe Buck wrote:
> 
> > > That's what info gcc 'invoking gcc' is for.  With the current texinfo
> > > snapshot you can even say info --show-options gcc.
> > 
> > This is why I think that the gcc man page should be obtained by coverting
> > invoke.texi.
> > 
> > The vast majority of software on any Unix, GNU/Linux, or BSD system has
> > documentation in the form of man pages.  Users expect to type "man".
> 
> Just to put in my two cents, 'invoking gcc' very nice for what it is, but
> it ain't no man page.  One of the great things about man pages is that
> they have a very specific set of sections, normally in the same order.
> 
> Near the top, they have a canonical list of flags, so that when you find
> some invocation you don't grok in some makefile somewhere, you have a hope
> of finding a clue.  It won't tell you all the whys and wherefores, but it
> will give you just a QUICK idea of what the damn thing does.
> 
> I'm not against, in principal, converting to man pages from texinfo, but
> I've never seen anything in a texinfo file anywhere as quick and useful
> as a man page.

I'm wondering. After the initial investment in converting the texinfo
stuff to proper manpages, how hard can it be to maintain incrementally
from say diffs? Initially this would suck SOOOO much butt but then it'd 
get easier as smaller changes are required, no?

> A better solution might be to use the perl pod format, since it's extremely
> simple, and converts to troff as well as sweetened and unsweetened ascii.
> It's easier to use ( read *MUCH* easier ) than troff, which is as ugly
> as postscript, and most importantly, the results will be paged through
> things that search with the / key, as they should.  <G>

I don't like perldoc either. I'm a sucker for man. :)

> Of course the man page maintainer would have to have perl, 
> but who doesn't? ( We can make this two ... two ... two flamewars in one! ;)

8)

-- 
CaT (cat@zip.net.au)                       URL: http://www.zip.com.au/dev/null

For a bad joke read:

        http://www2.hunterlink.net.au/~ddhrg/censorship_legislation.html

WARNING: multiple messages have this Message-ID
From: CaT <cat@zip.com.au>
To: rich-paul@rich-paul.net
Cc: jbuck@Synopsys.COM, schwab@issan.cs.uni-dortmund.de,
	pfeifer@dbai.tuwien.ac.at, psycho@albatross.co.nz,
	oliva@dcc.unicamp.br, cat@zip.com.au, egcs@egcs.cygnus.com
Subject: Re: (Getting rid of) man pages
Date: Fri, 30 Apr 1999 23:15:00 -0000	[thread overview]
Message-ID: <199904240743.RAA05169@zipper.zip.com.au> (raw)
Message-ID: <19990430231500.6bpa9StMjmcq60ede10uIk5ZQzeKDHnjE7B8ceKy7_g@z> (raw)
In-Reply-To: <Pine.LNX.4.05.9904240317070.19454-100000@deepthought.rich-paul.net>

rich-paul@rich-paul.net wrote the following:
> 
> On Fri, 23 Apr 1999, Joe Buck wrote:
> 
> > > That's what info gcc 'invoking gcc' is for.  With the current texinfo
> > > snapshot you can even say info --show-options gcc.
> > 
> > This is why I think that the gcc man page should be obtained by coverting
> > invoke.texi.
> > 
> > The vast majority of software on any Unix, GNU/Linux, or BSD system has
> > documentation in the form of man pages.  Users expect to type "man".
> 
> Just to put in my two cents, 'invoking gcc' very nice for what it is, but
> it ain't no man page.  One of the great things about man pages is that
> they have a very specific set of sections, normally in the same order.
> 
> Near the top, they have a canonical list of flags, so that when you find
> some invocation you don't grok in some makefile somewhere, you have a hope
> of finding a clue.  It won't tell you all the whys and wherefores, but it
> will give you just a QUICK idea of what the damn thing does.
> 
> I'm not against, in principal, converting to man pages from texinfo, but
> I've never seen anything in a texinfo file anywhere as quick and useful
> as a man page.

I'm wondering. After the initial investment in converting the texinfo
stuff to proper manpages, how hard can it be to maintain incrementally
from say diffs? Initially this would suck SOOOO much butt but then it'd 
get easier as smaller changes are required, no?

> A better solution might be to use the perl pod format, since it's extremely
> simple, and converts to troff as well as sweetened and unsweetened ascii.
> It's easier to use ( read *MUCH* easier ) than troff, which is as ugly
> as postscript, and most importantly, the results will be paged through
> things that search with the / key, as they should.  <G>

I don't like perldoc either. I'm a sucker for man. :)

> Of course the man page maintainer would have to have perl, 
> but who doesn't? ( We can make this two ... two ... two flamewars in one! ;)

8)

-- 
CaT (cat@zip.net.au)                       URL: http://www.zip.com.au/dev/null

For a bad joke read:

        http://www2.hunterlink.net.au/~ddhrg/censorship_legislation.html


  reply	other threads:[~1999-04-24  0:50 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-04-22  9:23 Gerald Pfeifer
1999-04-22  9:35 ` Alexandre Oliva
1999-04-30 23:15   ` Alexandre Oliva
1999-04-22  9:52 ` CaT
1999-04-22 10:08   ` Alexandre Oliva
1999-04-22 10:22     ` CaT
1999-04-30 23:15       ` CaT
1999-04-22 10:23     ` Keith Duthie
1999-04-22 10:26       ` CaT
1999-04-30 23:15         ` CaT
1999-04-22 10:31       ` Alexandre Oliva
1999-04-30 23:15         ` Alexandre Oliva
1999-04-22 16:10       ` Gerald Pfeifer
1999-04-22 16:44         ` Joe Buck
1999-04-22 22:19           ` Jeffrey A Law
1999-04-30 23:15             ` Jeffrey A Law
1999-04-23  1:52           ` Andreas Schwab
1999-04-23  9:12             ` Joe Buck
1999-04-24  0:31               ` rich-paul
1999-04-24  0:50                 ` CaT [this message]
1999-04-30 23:15                   ` CaT
1999-04-24  5:50                 ` craig
1999-04-30 23:15                   ` craig
1999-04-30 23:15                 ` rich-paul
1999-04-30 23:15               ` Joe Buck
1999-04-23 10:52             ` Marc Espie
1999-04-23 11:00               ` Joe Buck
1999-04-30 23:15                 ` Joe Buck
1999-04-30 23:15               ` Marc Espie
1999-04-30 23:15             ` Andreas Schwab
1999-04-30 23:15           ` Joe Buck
1999-04-30 23:15         ` Gerald Pfeifer
1999-04-30 23:15       ` Keith Duthie
1999-04-30 23:15     ` Alexandre Oliva
1999-04-30 23:15   ` CaT
1999-04-30 23:15 ` Gerald Pfeifer
1999-06-25  6:25 ` Alexandre Oliva
1999-06-30 15:43   ` Alexandre Oliva
1999-04-23 11:10 Josh Stern
1999-04-30 23:15 ` Josh Stern

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=199904240743.RAA05169@zipper.zip.com.au \
    --to=cat@zip.com.au \
    --cc=egcs@egcs.cygnus.com \
    --cc=jbuck@Synopsys.COM \
    --cc=oliva@dcc.unicamp.br \
    --cc=pfeifer@dbai.tuwien.ac.at \
    --cc=psycho@albatross.co.nz \
    --cc=rich-paul@rich-paul.net \
    --cc=schwab@issan.cs.uni-dortmund.de \
    /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 read-only IMAP folder(s) and NNTP newsgroup(s).