From: "Nikolay Aleksandrovich Pavlov (ZyX)" <kp-pav@yandex.ru>
To: "linuxtechguy@gmail.com" <linuxtechguy@gmail.com>,
"zsh-users@zsh.org" <zsh-users@zsh.org>
Subject: Re: Does mandir get saved some place?
Date: Sun, 06 Aug 2017 04:00:03 +0300 [thread overview]
Message-ID: <76131501981203@web60g.yandex.ru> (raw)
In-Reply-To: <CA+rB6G+XTk5JvKQQ=8RTic4j+92UgvBpn6p6Q=P0hJBmz1uoaA@mail.gmail.com>
03.08.2017, 18:03, "Jim" <linux.tech.guy@gmail.com>:
> Hi,
>
> Sorry if I missed this in the documentation, but so far I have been unable
> to find what I'm looking for. Google doesn't always find things either.
>
> First, thanks for the fact that zsh is very version conscious. This makes
> it very easy to test a particular build of zsh. Not all distributions take
> advantage of this, but that's something to take up with the distribution.
> I just wish more applications would take this approach. I digress.
>
> With the fact that the configure script has the option "mandir=<some dir>"
> I assumed(bad thing to do) that there would be an easy way to discover
> where the man pages were saved. If there is, so far I haven't found it. My
> reasoning for this is, if I'm testing a particular build, I would like to
> have
> available the pages for that build if they exist. I assumed(I know)
> that is why "mandir" is there, to make this possible.
>
> Is there a variable of something else that can be accessed to tell
> someone where a particular zsh build saved the man pages? If not,
> would it be unreasonable to ask that a variable like "mandir" be set with
> the path to those man pages? This would make it so much easier to
> set MANPATH. For me it would even be better if zsh automatically
> added a path to them before the normal locations. I'm sure others
> would disagree. An option allowing such behaviour would allow a user
> to set this to meet there own needs.
>
> Again, if I missed this in the documentation, sorry for the noise.
>
> Sincerely,
>
> Jim
You can probably use `zsh -fc 'printf "%s" $module_path[1]:h:h:h/share/man'`. Should work fine as long as you are only setting single installation prefix based on which other locations are computed and not other installation locations explicitly. All versions I ever needed have `$module_path[1]` set to something like `{prefix}/lib(64)?/zsh/$ZSH_VERSION`, so three `:h` are there to get rid of `lib*`, `zsh` and `$ZSH_VERSION` components.
next prev parent reply other threads:[~2017-08-06 1:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-03 15:01 Jim
2017-08-06 1:00 ` Nikolay Aleksandrovich Pavlov (ZyX) [this message]
[not found] ` <CA+rB6GLYMUyzO=c5P=FLSyhS15JUQW8-naRWzfc73fovAJQ3hQ@mail.gmail.com>
2017-08-06 6:37 ` Fwd: " Jim
2017-08-06 9:48 ` Nikolay Aleksandrovich Pavlov (ZyX)
2017-08-06 17:55 ` Jim
2017-08-06 20:13 ` Nikolay Aleksandrovich Pavlov (ZyX)
2017-08-06 11:02 ` Bart Schaefer
2017-08-06 19:20 ` Jim
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=76131501981203@web60g.yandex.ru \
--to=kp-pav@yandex.ru \
--cc=linuxtechguy@gmail.com \
--cc=zsh-users@zsh.org \
/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.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
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).