Re: MANPATH and overriding/modifying default paths.

[Kristaps Dzonsons <kristaps@bsd.lv>]

>> A while back, I complained to Ingo that MANPATH is heavy-handed: it
>> doesn't allow us to modify the default search path (in, e.g.,
>> /etc/man.conf), but only override it.
>>
>> He mentioned that in manpath(1) used on systems, MANPATH can modify
>> instead of override by placemen to colons.  To wit:
>>
>> MANPATH
>>      If $MANPATH is set, manpath displays its value rather than
>> determining it on the fly. If $MANPATH is prefixed by a colon, then
>> the value of the variable is appended to the list determined from
>> the content of the configuration files. If the colon comes at the
>> end of the value in the variable, then the determined list is
>> appended to the content of the variable. If the value of the
>> variable contains a double colon (::), then the determined list is
>> inserted in the middle of the value, between the two colons.
>>
>> The enclosed patch does just this for apropos(1), whatis(1), and
>> catman(8) (which is also updated with -C like the others).  I
>> modified the explanation above to be (I hope) a little clearer as to
>> precedence.
>
> Yes, your wording is better, very clear and concise.
>
>> Objections?
>
> First, i misread your patch.  You changed the #else clause of
> the cpp(1) alternative, not the #ifdef clause.  Thanks for
> pointing that out once again.
>
> Then, i hesitated for some time whether we really want this,
> but came to the conclusion that we have MANPATH anyway, it does
> not change MANPATH semantics that much, the proposed use case
> makes sense, i could not come up with a better solution, and it
> improves compatibility a tiny bit.
>
> So i have tweaked it and committed it to OpenBSD.
> At the expense of three additional lines of code -
> actually, all of them closing braces - i got rid of two
> local variables, made the code flow much more obvious
> and got the oportunity of inserting eight comments.
>
> While here, i have also put back -m (which got lost)
> and copied Linux semantics of treating an empty MANPATH
> the same way as an undefined MANPATH, which obviously
> is more useful than returning empty results.
>
> Feel free to merge to bsd.lv, or tell me to do it;
> conflict resolution will be trivial.

Ingo,

I'm checking this in right now, applying the apropos(1) updates to 
whatis(1) and catman(8).

Thanks for looking this over!

Kristaps

--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv