help / color / mirror / Atom feed
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 --]


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:


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

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,

[-- Attachment #2: usr-share-man.tar.gz --]
[-- Type: application/octet-stream, Size: 20992 bytes --]

             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:

* 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 \


* 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).