evan@telly.on.ca (Evan Leibovitch) (06/19/89)
I've always semi-understood the layout of Unix man pages. But going through
some of the sources I've installed, I've seen some ambiguous (to me)
arrangements that will cause confusion under the present scheme.
Specifically, I'm talking about the fact that some source distributions
describe their executables under section 1 (elm, compress, cnews, conf,
kermit, etc...). Yet others choose to put similar information in section 8
(Bnews, smail) and a straggler or two likes yet something else such as
cookie(6).
Frustrating my obvious workaround (just mixing sections 1 and 8) is the
odd file-format description in section 8 (aliases, paths, etc.).
Using 'man' online is no problem. But for printed pages I'm
tempted to just forget sections and sort them all alphabetically.
Is there a right or wrong to all this?
--
Evan Leibovitch, SA, Telly Online, located in beautiful Brampton, Ontario
evan@telly.on.ca / {uunet!attcan,utzoo}!telly!evan / (416) 452-0504
Computer salesman's credo: There's an end-user born every minutehenry@utzoo.uucp (Henry Spencer) (06/20/89)
In article <1989Jun19.021419.1512@telly.on.ca> evan@telly.on.ca (Evan Leibovitch) writes: >Specifically, I'm talking about the fact that some source distributions >describe their executables under section 1 (elm, compress, cnews, conf, >kermit, etc...). Yet others choose to put similar information in section 8 >(Bnews, smail) and a straggler or two likes yet something else such as >cookie(6). Historically, 1 was for commands that users might run, 6 was for games, 8 was for administration. The boundaries here were kind of fuzzy -- what about programs that users might run for administrative purposes? C News puts programs never intended to be run by humans (daemons and such) in 8, and human-run programs in 1. -- You *can* understand sendmail, | Henry Spencer at U of Toronto Zoology but it's not worth it. -Collyer| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
root@cca.ucsf.edu (Systems Staff) (06/20/89)
In article <1989Jun19.021419.1512@telly.on.ca>, evan@telly.on.ca (Evan Leibovitch) writes: > I've always semi-understood the layout of Unix man pages. But going through > ... > Specifically, I'm talking about the fact that some source distributions > describe their executables under section 1 (elm, compress, cnews, conf, > kermit, etc...). Yet others choose to put similar information in section 8 > (Bnews, smail) and a straggler or two likes yet something else such as > cookie(6). Section 1 is for the ordinary use programs; section 8 is for programs used only by system administrators. The following relates to the on-line manual files normally found in the filesystem subtree rooted at /usr/man. Some of the _man_ programs around have problems dealing with local additions to the system. Putting their documentation into a separate section has both advantages and disadvantages. The obvious disadvantages are that you then have two places to look instead of of one and there isn't a standard section defined for local additions. The advantage is that you can readily distinguish which programs are local additions and may not be found on other systems even though they have the full complement of facilities for the system in use. The natural way to handle this would be to place them in the same section but flag the local additions with a distinctive suffix (as, for example, BSD systems do for the libraries in section 3). Unfortunately, some of the _man_ commands around can't handle this in the file naming and you have to look inside the files to see their classification. This can be circumvented by, for example, having command man pages appear not only in the man1 directory used by man but have links to separate directories, say man1.local and man1.std. Thos Sumner (thos@cca.ucsf.edu) BITNET: thos@ucsfcca (The I.G.) (...ucbvax!ucsfcgl!cca.ucsf!thos) U.S. Mail: Thos Sumner, Computer Center, Rm U-76, UCSF San Francisco, CA 94143-0704 USA OS|2 -- an Operating System for puppets. #include <disclaimer.std>
bet@orion.mc.duke.edu (Bennett Todd) (06/22/89)
If you are fortunate enough to be using a system whose man(1) command
knows about the environment variable MANPATH, then you can just put
MANPATH='/usr/man:/usr/local/man'
(for Bourne style shells) or
setenv MANPATH '/usr/man:/usr/local/man'
(for C shells) in the same place you add /usr/local/bin to the PATH,
then have a complete heirarchy of /usr/local/man/{man,cat}[1-8]. We do
this, and as as result /usr/local stands independant of the rest of the
system (we also have /usr/local/lib, /usr/local/etc, /usr/local/include,
and /usr/local/src). It sure is nice being able to mount up one
filesystem for everybody, being able to upgrade the OS and leave the
local stuff virtually completely installed, being able to take
/usr/local/src and put it in a new filesystem on a new machine and
rebuild a complete standalone /usr/local tree for that system, and like
that.
-Bennett
bet@orion.mc.duke.edubet@orion.mc.duke.edu (Bennett Todd) (06/22/89)
In article <14818@duke.cs.duke.edu>, I wrote: > MANPATH='/usr/man:/usr/local/man' *WHY* can't I see these things before the danged articles are out? Obviously, I meant to say: MANPATH='/usr/man:/usr/local/man' export MANPATH Sorry. -Bennett bet@orion.mc.duke.edu
gordon@prls.UUCP (Gordon Vickers) (06/22/89)
In article <14818@duke.cs.duke.edu> bet@orion.mc.duke.edu (Bennett Todd) writes:
->If you are fortunate enough to be using a system whose man(1) command
->knows about the environment variable MANPATH, then you can just put
-> MANPATH='/usr/man:/usr/local/man'
->(for Bourne style shells) or
-> setenv MANPATH '/usr/man:/usr/local/man'
[ and don't forget to export MANPATH - gpv]
->(for C shells) in the same place you add /usr/local/bin to the PATH,
->then have a complete heirarchy of /usr/local/man/{man,cat}[1-8]. We do
->this, and as as result /usr/local stands independant of the rest of the
->system (we also have /usr/local/lib, /usr/local/etc, /usr/local/include,
->and /usr/local/src). It sure is nice being able to mount up one
->filesystem for everybody, being able to upgrade the OS and leave the
->local stuff virtually completely installed, being able to take
->/usr/local/src and put it in a new filesystem on a new machine and
->rebuild a complete standalone /usr/local tree for that system, and like
->that.
I accomplish the same thing by just using soft links and adding
a suitable uppercase letter to the directory name (i.e. locally
produced man pages are in manL).
Example: ln -s /a/man/manL /usr/man/manL (local stuf)
ln -s /a/man/manP /usr/man/manP (public i.e. USENET stuf)
ln -s /a/man/manG /usr/man/manG (games)
etc.
This method doesn't require every user to change thier start up script.
When I install an O.S. upgrade, I unmount the /a filesystem first (just
in case the new distribution adds a man directory with one of these names).
Gordon Vickers 408/991-5370 (Sunnyvale,Ca); {mips|pyramid|philabs}!prls!gordon
------------------------------------------------------------------------------
Every extinction, whether animal, mineral, or vegetable, hastens our own demise.render@m.cs.uiuc.edu (06/24/89)
There is a PD version of man called 'rman' that supports both MANPATH and distributed man pages. It's available from uunet.uu.net by using anonymous ftp. It should be under either the comp.sources.misc or comp.sources.unix directories. Hal Render render@cs.uiu.edu