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
next prev parent 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).