🚀 go-pugleaf

On 26 Feb 1996 08:00:34 -0600, Peter Seebach wrote:
>> The very latest GNU coding standard says:

>> >    It remains necessary to worry about differences among cpu types, such
>> >    as the difference in byte ordering and alignment restrictions.  It's
>> >    unlikely that 16-bit machines will ever be supported by GNU, so there
>> >    is no point in spending any time to consider the possibility that an
>> >    `int' will be less than 32 bits.
[snip]
>> Please take the time to let "gnu@prep.ai.mit.edu" know how clever and
>> informed they appear to be in the eyes of the C coding community.

And as I mentioned over in c.l.c., while their coding standards don't
explictly state that "void main" is preferred practice, much of the code
that is released under the GNU banner uses this ignorant construct.

Perhaps the campaign to educate the Stallmanites should make them aware
of the ANSI/ISO C Standard and the two conforming declarations of main.

-- 
=============================================================================
          Bob Nelson: Dallas, Texas, U.S.A.  -  bnelson@netcom.com
      Linux for fun, M$ for $$$...and the NFL for what really counts!
=============================================================================

In article <4gsee2$4r5@solutions.solon.com>,
Peter Seebach <seebs@solutions.solon.com> wrote:
:The very latest GNU coding standard says:

[arrogant quote snipped]

:Please take the time to let "gnu@prep.ai.mit.edu" know how clever and informed
:they appear to be in the eyes of the C coding community.
:
:Examples of programs and platforms they haven't worked well on because they
:made these assumptions would be great, especially if it's GNU software, and
:the porting effort is non-trivial.

I once thought I might like to make GNU's "diff" work on my 16-bit
PC compiler (wanting to modify it to deal with C tokens rather than
words/lines) but the code turned out to be so hopeless I gave up
quickly.  Somebody told me that that code is better now, but I've
never made another effort to get it.

What I wanted to do was make
	int main(void) {return 0;}
match
	int main(void)
	{
		return 0;
	}
for example, in order to locate "real" differences.

I had a 32-bit compiler at work and a 16-bit compiler at home, and
was unwilling to use work resources to do this.

:Similarly, you might mention to bug-bash@prep.ai.mit.edu that it is
:mind-numbingly dumb that libreadline uses varargs, but not stdarg.  What does
:it do when there is no varargs either?  It declares 3 arguments and just passes
:all three on to v*printf, figuring that this will probably work.
:
:The FSF is an influential source of code, and should be gently nudged away
:from the incomprehensibly stupid.
:
:So, any one else got favorite examples of incomprehensible bad ideas
:mysteriously cropping up in otherwise sane code?

This isn't code, but may be even worse.  It's from the gcc man page:

     If we find that the things in this man page that are out  of
     date cause significant confusion or complaints, we will stop
     distributing the man page.  The  alternative,  updating  the
     man page when we update the Info file, is impossible because
     the rest of the work of maintaining GNU CC leaves us no time
     for that.  The GNU project regards man pages as obsolete and
     should not let them take time away from other things.

     For complete and current documentation, refer  to  the  Info
     file  `gcc' or the manual Using and Porting GNU CC (for ver-
     sion 2.0).  Both are  made  from  the  Texinfo  source  file
     gcc.texinfo.

Of course, just try and find this "Info file" if you are a user of,
rather than the installer of, gcc.

Sounds to me like the "WHAT! You want me to TELL you how to use
my code?  That's YOUR problem!" syndrome.  "I'm too busy to
document it.  I need my time to write more undocumented code!"

Just what makes man pages "obsolete?"  This declaration?  What's the
replacement to be?  Every vendor coming up with a secretly named
documentation file that's hidden somewhere differently?

Seems that FSF wants to get rid of the consistency of "man foo" to find
out about "foo".

Sorry, perhaps off-topic, but you brought up the FSF.  :-)

Cheers,
Stan.
--
Stan Ryckman  (stanr@tiac.net) (new e-mail address)

stanr@tiac.net (Stan Ryckman) wrote:

[snip]

>This isn't code, but may be even worse.  It's from the gcc man page:

>     If we find that the things in this man page that are out  of
>     date cause significant confusion or complaints, we will stop
>     distributing the man page.  The  alternative,  updating  the
>     man page when we update the Info file, is impossible because
>     the rest of the work of maintaining GNU CC leaves us no time
>     for that.  The GNU project regards man pages as obsolete and
>     should not let them take time away from other things.
     [tongue in cheek] "You have no idea how busy we are and it isn't
because there's no documentation for any of us supporting code another
wrote.  Honest!" [tongue out of cheek]

>     For complete and current documentation, refer  to  the  Info
>     file  `gcc' or the manual Using and Porting GNU CC (for ver-
>     sion 2.0).  Both are  made  from  the  Texinfo  source  file
>     gcc.texinfo.

>Of course, just try and find this "Info file" if you are a user of,
>rather than the installer of, gcc.

     [TIC] "Peon!  You're lucky we even give you the code." [TOOC]

>Sounds to me like the "WHAT! You want me to TELL you how to use
>my code?  That's YOUR problem!" syndrome.  "I'm too busy to
>document it.  I need my time to write more undocumented code!"

[snip]

     Seems as if the "free" in FSF means "worth every penny".

[snip]

Sincerely,

Gene Wirchenko

C Pronunciation Guide:
     y=x++;     "wye equals ex plus plus semicolon"
     x=x++;     "ex equals ex doublecross semicolon"

{I know it's not about C but I felt a need to respond publicly. -Matthew}

In article <4hlala$4hn@solutions.solon.com>,
Stan Ryckman <stanr@tiac.net> wrote:

>This isn't code, but may be even worse.  It's from the gcc man page:
{blah blah.. gnu's moving to info pages away from man pages}

>Of course, just try and find this "Info file" if you are a user of,
>rather than the installer of, gcc.

'info gcc'. If your shell returns, "info: command not found" ask
a friend where it is on your system. If 'info' starts up but
not in the gcc node, ask the installer of gcc why they didn't install
the info pages for gcc. Personally I find the info system much better
than the man system for long complex documents. Can you imagine the
emacs lisp manual in man page format? eek.

Matthew

------------------------------------------------------------------------------
Matthew Sams                    | All this talk about everyone being connected
Systems Programmer              | to the Internet by the year xxxx ignores the
School of Computer Science      | simple fact that a large number of people in
McGill University               | the world are fighting for survival.
------------------------------------------------------------------------------

Stan Ryckman (stanr@tiac.net) wrote:
: I once thought I might like to make GNU's "diff" work on my 16-bit
: PC compiler (wanting to modify it to deal with C tokens rather than
: words/lines) but the code turned out to be so hopeless I gave up
: quickly.  Somebody told me that that code is better now, but I've
: never made another effort to get it.
: 
: What I wanted to do was make
: 	int main(void) {return 0;}
: match
: 	int main(void)
: 	{
: 		return 0;
: 	}
: for example, in order to locate "real" differences.

Have you ever heard of GNU indent?  
run the two c files through indent before you diff them and everything will
work out fine.

Wes
---
Wes Brown
ewb4@po.cwru.edu		wes@prozac.student.cwru.edu
http://prozac.cwru.edu/wes/About.me.html
KB8TGR

>    You can assume that all pointers have the same format, regardless of
>    the type they point to, and that this is really an integer.  There are
>    some weird machines where this isn't true, but they aren't important;
>    don't waste time catering to them.  Besides, eventually we will put
>    function prototypes into all GNU programs, and that will probably make
>    your program work even on weird machines.

Is this a joke?  And I suppose we can assume all machines are big-endian, too,
and it's okay to copy strings by casting them to ints and using assignments?

Thanks, GNU, for today's biggest laugh, from a bunch of people who have ported
tons of code to the DEC Alpha (obviously an unimportant machine).

[Update: This is no longer quite as bad, it now says only to assume pointers
 are integers in things like LISP interpreters.  The current standards have
 one offensively stupid suggestion I can detect, but are otherwise nearly
 sane, largely because of the ongoing debate, in gnu.misc.discuss. -mod]

--
Scott J. Tringali, tringali@ultranet.com
Raytheon Electronic Systems, International Air Traffic Control

Matthew Sams <maclean@CS.McGill.CA> writes:

[..]

> Personally I find the info system much better than the man system
> for long complex documents. Can you imagine the emacs lisp manual in
> man page format? eek.

Getting way off topic here, but such is Usenet.  If GNU wants to call
man pages obsolete, then they should trash Info too and switch to
HTML, which is a lot more powerful and easier to use.

-Jeff

In article <4hqec9$1kf@solutions.solon.com>,
Wes Brown <wes@prozac.student.cwru.edu> wrote:
>Stan Ryckman (stanr@tiac.net) wrote:
:: I once thought I might like to make GNU's "diff" work on my 16-bit
:: PC compiler (wanting to modify it to deal with C tokens rather than
:: words/lines) but the code turned out to be so hopeless I gave up
:: quickly.  Somebody told me that that code is better now, but I've
:: never made another effort to get it.
:: 
:: What I wanted to do was make
:: 	int main(void) {return 0;}
:: match
:: 	int main(void)
:: 	{
:: 		return 0;
:: 	}
:: for example, in order to locate "real" differences.
:
:Have you ever heard of GNU indent?  
:run the two c files through indent before you diff them and everything will
:work out fine.

Good idea... except what I had in mind would have identified the
line numbers in the original files when differences were found.  Also,
an option would have allowed comments to be equal to all white space.

As someone pointed out in email, I could also just put each token
on a line and diff the resulting mess...but again, I lose the line
number information.

Just curious, what would GNU indent do with:
	(a)	x+++y
	(b)	x++ +y
	(c)	x+ ++y
?
(Note that two of these need to match, and one mustn't!)

As I said, I gave up on it.

Cheers,
Stan.
--
Stan Ryckman  (stanr@tiac.net)
  (Apologies for non-responses or late responses to some posts;
  .newsrc was trashed and I'm trying to get it back to where it was.)

Stan Ryckman (stanr@tiac.net) wrote:
: :Have you ever heard of GNU indent?  
: :run the two c files through indent before you diff them and everything will
: :work out fine.

: Good idea... except what I had in mind would have identified the
: line numbers in the original files when differences were found.  Also,
: an option would have allowed comments to be equal to all white space.

Diff has no knowledge of C, which is why you have to grind them through
indent first.  It's a good idea to use it in general, eliminates squabbling
over brace and other style issues that some people get embroiled in.

: Just curious, what would GNU indent do with:
: 	(a)	x+++y
: 	(b)	x++ +y
: 	(c)	x+ ++y
: ?
: (Note that two of these need to match, and one mustn't!)

It's broken if it doesn't match (b) since the language states that the next
token is the longest string of characters that consitutes one.

-jack-

Documentation _is_ relevant to C, so

>Matthew Sams <maclean@CS.McGill.CA> writes:
>> Personally I find the info system much better than the man system
>> for long complex documents. Can you imagine the emacs lisp manual in
>> man page format? eek.

I am in full agreement with this, BUT it mistakes the purpose of UNIX
man pages.  A man page is supposed to be A PAGE, or at best only a few
pages.  In essence, they are supposed to be on-line quick reference
cards.  man pages and TeXinfo documents simply do different things.

When I want to find out how to use gcc to generate makefile dependencies,
all I want is the "quick reference" so that I can find out how to spell
-MM and whether it has one M or two.  I don't _want_ a long tutorial.

When I want to find out all about the gcc language extensions, I don't
want the quick reference.  THEN I want a long tutorial.

As an experienced AWK programmer, if I want to check on the functions
provided by gawk, I want the "quick reference" that lists their names
and *briefly* describes their functions, so that I can check if the
one I already know about and want is there.  If a student wants to
learn all about regular expression pattern matching and to see some
examples, then she wants to read the long tutorial.

In short, NEITHER kind of document can replace the other, because they
serve completely different needs.

jeffno@annapurna.ccs.neu.edu (Jeffrey Nowakowski) writes:

>Getting way off topic here, but such is Usenet.  If GNU wants to call
>man pages obsolete, then they should trash Info too and switch to
>HTML, which is a lot more powerful and easier to use.

The UNIX manuals use nroff instead of LaTeX and Emacs because they 
existed before LaTeX and Emacs did.
The GNU Info documents use LaTeX and Emacs instead of HTML because
they existed before HTML did.
TeXinfo files also do important things that HTML does not do, like
numbering sections, generating tables of contents, and indexes.


For C programmers, I note that there is a program called 'c2man'.
From the README file, c2man is 

    ... a program for generating Unix style manual pages in nroff/troff
    -man, TeXinfo, LaTeX or HTML format directly from ordinary comments
    embedded in C source code.  It should run on virtually any Unix-like
    system, OS/2, VMS, MSDOS or Amiga systems.

The current release is version 2 patchlevel 40.  With such a tool
around, if you are writing a library of functions, there is no longer
any good reason NOT to produce documentation.  The hardest part about
writing UNIX manual pages was learning how to use nroff, which is, um,
arcane.  c2man does that bit for you.  You just have to provide the
content.  And if you want both man pages and TeXinfo, you can get them
_automatically_; best of both worlds.

-- 
The election is over, and Australia lost; the idjits elected _politicians_!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

stanr@tiac.net (Stan Ryckman) [wants to identify matching chunks in C
source files]

Let me draw 'sim' to your attention.
This is a suite of programs that was written
 - to detect replicated code in a program
 - to detect plagiarism in student assignments
I think it does exactly what Stan Ryckman wants.

It was written by Dick Grune of the Vrije Universiteit, Amsterdam.
There are instances of sim for Lisp, Pascal, C, Modula 2, and plain text.

(By the way, if anyone can tell me where I got this I'll be grateful.
 I need to produce an Ada version, and I've lost the source code.
)
-- 
The election is over, and Australia lost; the idjits elected _politicians_!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

In article <4ieue0$ba5@solutions.solon.com>, ok@cs.rmit.edu.au (Richard A. O'Keefe) writes:

|> When I want to find out how to use gcc to generate makefile dependencies,
|> all I want is the "quick reference" so that I can find out how to spell
|> -MM and whether it has one M or two.  I don't _want_ a long tutorial.

A good TeXinfo manual has an `Invoking foo' or `foo Invocation' entry
in the toplevel menu, pointing to a node that should be written like a
quick reference, with cross references to the more complete
documentation.  This is far superior to man pages.
-- 
Andreas Schwab                                      "And now for something
schwab@issan.informatik.uni-dortmund.de              completely different"

In article <4ijp92$1d9@solutions.solon.com>,
Andreas Schwab <schwab@issan.informatik.uni-dortmund.de> wrote:
:In article <4ieue0$ba5@solutions.solon.com>, ok@cs.rmit.edu.au (Richard A. O'Keefe) writes:
:
:|> When I want to find out how to use gcc to generate makefile dependencies,
:|> all I want is the "quick reference" so that I can find out how to spell
:|> -MM and whether it has one M or two.  I don't _want_ a long tutorial.
:
:A good TeXinfo manual has an `Invoking foo' or `foo Invocation' entry
:in the toplevel menu, pointing to a node that should be written like a
:quick reference, with cross references to the more complete
:documentation.  This is far superior to man pages.

To briefly re-enter this fray:

I tried "info gcc" as someone suggested.  It's nice.  The man page
should point to it, however.  If it had, rather than just stating that
the authors consider man pages to be obsolete, I probably wouldn't
have made my previous post.  (No, I don't consider pointing to
"the Info file" to be equivalent to the fact that there might be
an "info" command installed.)

However, it (info) seems to lack any way to save to a file in ascii
for downloading & printing; unless it can do that, it's not a
replacement for man pages.  (Quite apart from the arguments regarding
needing both short and long descriptions.)

Hope the moderator isn't too sick of this branch of this thread yet :)

Cheers,
Stan.
--
Stan Ryckman  (stanr@tiac.net)
  (Apologies for non-responses or late responses to some posts;
  .newsrc was trashed and I'm trying to get it back to where it was.)

Stan Ryckman writes

|> However, it (info) seems to lack any way to save to a file in ascii
|> for downloading & printing; unless it can do that, it's not a
|> replacement for man pages.  (Quite apart from the arguments regarding
|> needing both short and long descriptions.)

(ROFL) How lucky that info files are created from texinfo files that tex formats
and dvips prints!  Try info texinfo.

Konrad Schwarz

schwab@lamothe.informatik.uni-dortmund.de (Andreas Schwab) writes:

>|> When I want to find out how to use gcc to generate makefile dependencies,
>|> all I want is the "quick reference" so that I can find out how to spell
>|> -MM and whether it has one M or two.  I don't _want_ a long tutorial.
>
>A good TeXinfo manual has an `Invoking foo' or `foo Invocation' entry
>in the toplevel menu, pointing to a node that should be written like a
>quick reference, with cross references to the more complete
>documentation.  This is far superior to man pages.

If all you ever use is Gnu software with info files, then fine. In a
RealWorld<tm> environment with a large heterogenous mass of software
users (me!) want to be able to obtain a quickref for any executable in
their standard PATH via a simple, consistent procedure. Whether the
procedure consists of infoking some info reader or just using man is
unimportant - but it has to be the *same* for all commands. I.e. man foo.

This is still offtopic but seems to keep being approved nonetheless.

-- 

Henning Makholm - math and CS student - University of Copenhagen
makholm@diku.dk - http://www.diku.dk/students/makholm - fido 2:235/224.92

In article <4io1ht$nn0@solutions.solon.com>,
Konrad Schwarz <schwarz@mips.complang.tuwien.ac.at> wrote:
>Stan Ryckman writes
>
>|> However, it (info) seems to lack any way to save to a file in ascii
>|> for downloading & printing; unless it can do that, it's not a
>|> replacement for man pages.  (Quite apart from the arguments regarding
>|> needing both short and long descriptions.)
>
>(ROFL) How lucky that info files are created from texinfo files that tex formats
>and dvips prints!  Try info texinfo.

Please get off of the floor and brush the dust off your body.

"No manual entry for texinfo."

(Oh, and doesn't this violate FSF's error message standards by
having a period at the end?  :-)

Is "texinfo" now part of the GCC installation?

(I presume that when the moderator gets sick of this, he'll let
us know, but he's probably ROFLASC.  Besides, I *did* mention
GCC in this post  :-)

[Issues of how to distribute and document software are not really topical,
 but they do apply to many C programmers, and one of the advantages of a
 low-traffic newsgroup is that we can have topic drift without losing
 completely. -mod]

Cheers,
Stan.
--
Stan Ryckman  (stanr@tiac.net)
  (Apologies for non-responses or late responses to some posts;
  .newsrc was trashed and I'm trying to get it back to where it was.)

In article <4io1l4$nrj@solutions.solon.com>, makholm@diku.dk (Henning Makholm) writes:

|> If all you ever use is Gnu software with info files, then fine. In a
|> RealWorld<tm> environment with a large heterogenous mass of software
|> users (me!) want to be able to obtain a quickref for any executable in
|> their standard PATH via a simple, consistent procedure. Whether the
|> procedure consists of infoking some info reader or just using man is
|> unimportant - but it has to be the *same* for all commands. I.e. man foo.

alias man=info

The latest version of info (as included in the texinfo-3.7 package)
can load manual pages as well.

\end{off-topic}
-- 
Andreas Schwab                                      "And now for something
schwab@issan.informatik.uni-dortmund.de              completely different"

In article <4io1l4$nrj@solutions.solon.com>,
Henning Makholm <makholm@diku.dk> wrote:
>schwab@lamothe.informatik.uni-dortmund.de (Andreas Schwab) writes:
>
>>|> When I want to find out how to use gcc to generate makefile dependencies,
>>|> all I want is the "quick reference" so that I can find out how to spell
>>|> -MM and whether it has one M or two.  I don't _want_ a long tutorial.

>>A good TeXinfo manual has an `Invoking foo' or `foo Invocation' entry
>>in the toplevel menu, pointing to a node that should be written like a
>>quick reference, with cross references to the more complete
>>documentation.  This is far superior to man pages.

>If all you ever use is Gnu software with info files, then fine. In a
>RealWorld<tm> environment with a large heterogenous mass of software
>users (me!) want to be able to obtain a quickref for any executable in
>their standard PATH via a simple, consistent procedure. Whether the
>procedure consists of infoking some info reader or just using man is
>unimportant - but it has to be the *same* for all commands. I.e. man foo.

It is trivial to replace man with a shell script or any equivalent which
will do the right thing. Speaking of state-of-the-art Unix, IMHO, many
man pages have outlived their usefulness. My pet peeves is the <string.h>
manpage. I mean, this gigantic thing which documents strcpy(), strlen(),
strdup() and more... and doesn't even state which ones are ANSI, which ones
are proprietary (sampling SunOS, Solaris, HpUx, linux, linux seems to be the
only one that has got it right). When you get to big commands like gcc, zsh,
perl, even a `quick reference card' will be too long to be useful, so some
modicum of hypertext is needed.

The main problem I've got is to keep everything properly cross-referenced.
Most existing formats---texinfo, pod, html---are fine, but cross-referencing
is poor at best. Not much better than what existed under the man page 
concept... building a seek-and-retrieve automated mechanisms that would
scan the whole system looking for every tidbit of information and 
cross-referencing would be VERY useful. As far as CS texts go, the only
ones I've found with proper cross-references are:
* the C reference manual of Harbison and Steele
* Knuth's work on litterate programming---definitely need to learn C-Web.
* the PostScript reference manual---but then the material is easy to organize.
-- 
[nosave]<http://www.eleves.ens.fr:8080/home/espie/index.html>
microsoft network is EXPLICITLY forbidden to redistribute this message.
`Moon purismu powa, make up.... Tsuki ni kawatte, oshiokiyo !'
	Marc Espie (Marc.Espie@ens.fr)

>[Issues of how to distribute and document software are not really topical,
> but they do apply to many C programmers, and one of the advantages of a
> low-traffic newsgroup is that we can have topic drift without losing
> completely. -mod]


Let me repeat a point I made earlier:

	[c2man is] a program [by Graham Stony of Canon Information Systems
	Research Australia] for generating Unix style manual pages in
	nroff/troff -man, TeXinfo, LaTeX or HTML format directly from
	ordinary comments embedded in C source code.  It should run on
	virtually any Unix-like system, OS/2, VMS, MSDOS or Amiga systems.

I find that I have three problems with UNIX manual pages:

    - the viewer won't let you move _back_ in a document

    - there is hypertext structure in the documents (SEE ALSO) but the
      viewer is unable to exploit it

    - the markup language used for the documents is so arcane that I have
      never yet found a UNIX on-line manual set without embarrassing
      formatting errors.

I find that there are several problems with TexInfo documents:

    - they are way too big and hard to navigate around; I can only use
      them effectively if I already have a printed copy

    - for most people, 'info', if they have heard of it at all, is a
      clunky brute that is useful for nothing else.  In fact, when I
      try to use it, something goes wrong, so obviously there was an
      installation problem and no-one has noticed because no-one uses it.

    - the markup language used for the documents is a TeX macro package,
      which is a bit easier to use than nroff, but not a whole lot, and
      worse still, the macros change from time to time...

To borrow a phrase from an H.P.Lovecraft story, "The way out is to go UP".

Is there a format for which viewers are available on many platforms, not
just UNIX?
Is there a format which is usable with character terminals, but can take
advantage of GUI screens?
Is there a format which supports hypertext simply and well?
Yes there is:  HTML.

Is there any way we can generate documentation for C code
_without_ learning some arcane markup language,
_without_ committing to any particular viewer,
_without_ sacrificing the possibility of nicely printed documents,
_without_ sacrificing backwards compatibility with existing 'man'
    or 'TexInfo' document collections?
Yes there is:  c2man.

The implementation of c2man is tied to C, and has its limitations,
but the _idea_ is general.

-- 
The election is over, and Australia lost; the idjits elected _politicians_!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Henning Makholm (makholm@diku.dk) wrote: 
: schwab@lamothe.informatik.uni-dortmund.de (Andreas Schwab) writes:

: If all you ever use is Gnu software with info files, then fine. In a
: RealWorld<tm> environment with a large heterogenous mass of software
: users (me!) want to be able to obtain a quickref for any executable in
: their standard PATH via a simple, consistent procedure. Whether the
: procedure consists of infoking some info reader or just using man is
: unimportant - but it has to be the *same* for all commands. I.e. man foo.

Uh, manpages *are* quick references, info isn't, so what's your gripe?

And, if you think that info's not consistent, take a look at Solaris and it's
Answerbooks.  They're based on Display Postscript, so you have to be *on* a
Solaris box in order to use them.  Totally brain-dead.

-jack-

 I got tired of trying to find things, converted everything to text,
 indexed with wais, and use that instead.
 If I know I have a good man page I use man xxx otherwise I start up
 wais and wait an extra 5 sec for a list of all the references.
 It works great for me although the initial setup took a little
 effort..
-- 
Simon Casady                                      Pace Health Management Systems
cap@hces.com                                      voice       (515)-222-1717
casady@acm.org                                    fax         (515)-222-1716

In article <4j06ja$7r4@solutions.solon.com>,
Richard A. O'Keefe <ok@cs.rmit.edu.au> wrote:

>I find that I have three problems with UNIX manual pages:
>
>    - the viewer won't let you move _back_ in a document
This is a problem with your pager. Standard 'more' can't go back on a pipe,
'less' can.
If you have less installed, try
export PAGER=less

Pascal
-- 
Pascal Haible, haible@IZFM.Uni-Stuttgart.DE