Mike Gerdts wrote:
> On Dec 13, 2007 1:43 PM, Joseph Kowalski <jek3 at sun.com> wrote:
>
>> We could just add a link "man -> ./share/man" as needed.
>>
>
> The /usr/man -> share/man link does exist today and is documented in
> filesystem(5). I'm not sure that I am ready to take on filesystem(5)
> today.
>
Opps. I was trying to *not* search "../share/man" based on the PATH
setting.
>
>> That's what I'd like.
>>
>> However, I'd accept wording on the man(1) (and related) pages that
>> highlighted
>> that the second set above is just a legacy/convenience thing. We don't
>> want to
>> validate the practice of sprinkling "share" directories around.
>>
I can't find a clear response here... :-)
>> Also, along this line, shouldn't the algorithm reverse the priority of
>> steps #2 and #3?
>>
>
> This working in filesystem(5) suggests it may be the right thing to
> do. Unfortunately, those that created /usr/gnu/{bin,share/man} didn't
> take it into consideration:
>
> /usr/share/man
>
> Platform-independent sharable manual pages. An approved
> installation location for bundled Solaris software. The
> analogous location for add-on system software or for
> applications is /opt/packagename/man.
>
> Given that there is now more focus on adding to /usr/bin rather than
> adding more directories like /usr/sfw and /usr/gnu, there should be
> relatively few *Solaris directories that subscribe to share/man.
> Since third parties should be installing software to /opt/packagename
> with /opt/packagename/man as the man directory, reversing the search
> order to prefer man over share/man seems appropriate.
>
Great! (Now lets resolve if ../share/man should even be in the algorithm.)
>> Finally, for this proposal to be complete, I think you need to enumerate
>> the cases
>> handled by #1 (the explicit translation rules). I doubt they are
>> controversial, but
>> they should be enumerated for completeness.
>>
>
> The mapping is...
>
> /sbin /usr/share/man,1m
> /usr/sbin /usr/share/man,1m
> /usr/ucb /usr/share/man,1b
> /usr/bin /usr/share/man,1,1m,1s,1t,1c,1f
> /usr/xpg4/bin /usr/share/man,1
> /usr/xpg6/bin /usr/share/man,1
>
I'm not sure I'm getting it. These are absolute paths. These
transforms don't apply to any random PATH/../man searches, right?
To make this clear, given the PATH:
/usr/bin:/usr/sbin:/usr/ucb
There would be no effective change due to this proposal.
/usr/sbin:/usr/bin:/usr/ucb
Would only change the priority of a page under (1M) over (1) (but
hopefully we try not to do that).
/usr/ucb:/usr/bin:/usr/sbin
Would display "ucb" pages with preference.
The PATH:
/opt/mumble/bin:/usr/bin
Would be effective:
/opt/mumble/bin/../man:/opt/mumble/bin/../share/man:/usr/share/man
(with the bin/../share/man entry still being discussed)
Right?
------- next topic ------
Is the explicit list of /usr/bin subsections a good idea? Everytime a
new subsection was added, it would require a change to the man command.
I also suspect that this limitation may be an incompatible change in
behavior - currently an empty MANPATH value doesn't restrict the
subsections.
- jek3
