From: "Érico Nogueira" <ericonr@disroot.org>
To: <discuss@mandoc.bsd.lv>
Subject: Inconsistent behavior when localized man pages exist
Date: Sun, 03 Jan 2021 17:28:22 -0300 [thread overview]
Message-ID: <C89T1R73NIXC.8UY5BOMY3J8F@mussels> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 2219 bytes --]
Hi!
On Void Linux, we recently re-enabled installation of localized man
pages. However, man(1) (version 1.14.5) behaves rather strangely on
such occasions. I have attached a tarball with the file structure I'm
currently diagnosing this issue in. The file list inside it is as such:
usr/share/man/ca/man1/kate.1
usr/share/man/pt_BR/man1/kate.1
usr/share/man/man1/kate.1
For starters, the default /etc/man.conf is as seen below:
manpath /usr/share/local/man
manpath /usr/share/man
In this initial case, `man kate` will open
/usr/share/man/ca/man1/kate.1, after, according to strace(1), calling
access(2) on the other files as well:
chdir("/usr/share/man") = 0
[...]
access("ca/man1/kate.1", R_OK) = 0
access("pt_BR/man1/kate.1", R_OK) = 0
access("man1/kate.1", R_OK) = 0
In my opinion, this isn't intended behavior, since I don't have anything
(such as a LANG environment variable) that would indicate any preference
for the ca man page. If I add a `manpath /usr/share/man/pt_BR` entry to
the tail of man.conf, the same thing still happens; it's only if I add
it somewhere before the `manpath /usr/share/man` entry that I get the
pt_BR man page.
Interestingly, applying the patches discussed in [1] was enough for this
issue not to present itself. However, given that the problems discussed
there didn't seem at all related to my current issue, I don't know for
sure that the fix wasn't accidental; if it was, I would be interested in
getting a proper fix, and if it wasn't, I'd like to be sure of it.
[1] https://github.com/void-linux/void-packages/issues/9868
Furthermore, as a feature request (that I would be willing to work on),
I believe it might be interesting to make man(1) smart enough to use man
pages from $manpath/$locale, where $locale could be $LANG itself and/or
$LANG stripped of the '.UTF-8' suffix (or even turned from 'll_CC' to
'll').
Finally, I would like to ask about the possibility of a mandoc release;
we are already carrying some patches for essential fixes, including the
ones from [1]. If there's anything that I could help with for that,
please let me know.
Happy new year,
Érico
[-- Attachment #2: usr-share-man.tar.gz --]
[-- Type: application/octet-stream, Size: 20992 bytes --]
next reply other threads:[~2021-01-03 20:35 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-03 20:28 Érico Nogueira [this message]
2021-01-09 3:34 ` Érico Nogueira
2021-01-29 4:38 ` Érico Nogueira
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=C89T1R73NIXC.8UY5BOMY3J8F@mussels \
--to=ericonr@disroot.org \
--cc=discuss@mandoc.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).