[...]
> >That's pretty much what I did for my own version of
> this;
> >all the pathnames of commands that I knew had man
> pages in
> >/usr/[share]/man ( /usr/bin, /sbin, /usr/sbin,
> /usr/ucb) were
> >mapped to /usr/share/man; all others used a derived
> name
> >(with share/man tried first, then just man). May
> take a bit more
> >tweaking to get it as good as possible, but it
> pretty much works.
>
>
> Of course, depending on whether /usr/ucb is in your
> $PATH first, you
> also need to juggle with some of the MANEXT stuff (1b
> before 1, and such)
[...]
I don't find any reference in the man source to MANEXT; perhaps
you mean the MANSECTS setting in a man.cf file? AFAIK, there's no
comparable environment variable; I wish there were, it would allow
more intelligent setting of MANPATH and that additional environment
variable together, so that they would be most likely to find a man
page describing the version of a command found by a PATH search.
I think that's what we're really talking about trying to do, right?
And if that were done, I _think_ it would be possible to backwards-compatibly
fudge in the transparent addition of a --man option by getopt() to anything
that didn't already have one, since that wouldn't conflict with short-options
only, and could defer to any existing option that would match --man; thus,
it could be made to deduce the suitable man page and run man with
the appropriate environment variables and options to display it (and then
exit if it had done that). (another factor that makes that possible is that
since everything is dynamically linked now, getexecname() should
very rarely fail; so it should be possible to know the full command name
by which the command was invoked, provided that the name returned
by getexecname() doesn't have symlinks resolved - haven't tested that)
l
Adding a --man option to most commands in one fell swoop like that just
might be pretty cool (although I grant it sounds scary, too). If it were
in fact a sane thing to do, it would certainly make man pages more
easily discoverable.
If that's too crazy, then at least making man use more intelligent
defaults in the absence of MANPATH might be in order: having it
examine PATH, and generate its own internal MANPATH as we've
been discussing, perhaps have it internally reorder any MANSECTS setting to be
consistent with PATH (really applies only to /usr/share/man vs
/usr/{bin,xpg[46]/bin,ucb}), etc.
So it's either map exception list of directories to particular man
directory/ies with MANSECTS reordering, or if that doesn't apply,
derive share/man or man directory from the PATH element. Just
nail down the specifics, and it ought to be easy enough to code.
That way, rather than having to have various shells set MANPATH
intelligently, you just let the man command worry about it. And
nicely enough, the SUSv3 requirements for man are minimal, so there
shouldsn't be a standards issue in making it smarter. Nor should it be
much of a compatibility issue; if the environment variable setting took
precedence, those sites that were trying to be smart on their own by
pre-setting MANPATH would not see any change, while just about everyone
else would be getting more and more appropriate pages than they are
now.
This message posted from opensolaris.org
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
