tech@mandoc.bsd.lv
 help / color / mirror / Atom feed
From: Kristaps Dzonsons <kristaps@bsd.lv>
To: tech@mdocml.bsd.lv
Subject: Re: MANPATH and overriding/modifying default paths.
Date: Sun, 18 Dec 2011 20:50:58 +0100	[thread overview]
Message-ID: <4EEE4422.7060407@bsd.lv> (raw)
In-Reply-To: <20111218190950.GB28863@usta.de>

On 18/12/2011 20:09, Ingo Schwarze wrote:
> Hi Kristaps,
>
> Kristaps Dzonsons wrote on Sun, Dec 18, 2011 at 04:08:20PM +0100:
>> On 18/12/2011 15:52, Kristaps Dzonsons wrote:
>
>>> 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:
>
>> Ugh, I obviously shouldn't type so quickly... "the manpath(1)
>> utility (Mac OS X, FreeBSD, Linux) can modify the default list by
>> placement of colons".
>
> Heh, you are doing that for manpath(1)-based systems only.
> In that case, i have certainly no objection.
>
> Hum, how do we document that, if it is done for manpath(1),
> but not for man.conf(5)?  Not sure, but that's hardly a show
> stopper, that can certainly be solved.
>
> Maybe it might be useful for man.conf(5)-based systems as well.
> But i'm not really sure; i never needed it, and i'm a bit hesitant
> to change utilities to use environment variables for yet more
> functionality.  In any case, i'd rather not change the semantics
> related to man.conf(5) right now, to not interfere with getting
> apropos(1) ready.  We can return to it later, when we want to.

Saying man.conf(5)-based systems is a bit misleading, as manpath(1) 
systems generally use man.conf as well.  Ugh!  I think it's easier to 
say "manpath-systems" (FreeBSD, etc.) and "non-manpath-systems" 
(OpenBSD, etc.).

Right now, if USE_MANPATH is invoked, manpath_parse() simply routes 
directly into manpath(1), passing environment variables and using the 
`-M', `-m', and `-C' flags accepted by manpath(1).  So manpath(1) was 
already prepending/appending MANPATH.

The enclosed patch stretches this over non-manpath systems, as you can 
see.  This brings non-manpath in line with manpath vis-a-vis the MANPATH 
variable.

As mentioned, I really like it just because I've specifically been 
thwarted by this before.  Since few people use MANPATH anyway, and 
usually in the correct colon-separated way, I don't see how this will 
bother users, too.

Thoughts?

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

  reply	other threads:[~2011-12-18 19:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-18 14:52 Kristaps Dzonsons
2011-12-18 15:08 ` Kristaps Dzonsons
2011-12-18 19:09   ` Ingo Schwarze
2011-12-18 19:50     ` Kristaps Dzonsons [this message]
2011-12-24 22:14 ` Ingo Schwarze
2011-12-24 22:36   ` Kristaps Dzonsons

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EEE4422.7060407@bsd.lv \
    --to=kristaps@bsd.lv \
    --cc=tech@mdocml.bsd.lv \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).