discuss@mandoc.bsd.lv
 help / color / mirror / Atom feed
From: "Érico Nogueira" <ericonr@disroot.org>
To: <discuss@mandoc.bsd.lv>
Subject: Re: Inconsistent behavior when localized man pages exist
Date: Sat, 09 Jan 2021 00:34:07 -0300	[thread overview]
Message-ID: <C8EB8G8G5811.QTD2NQRMGVUR@mussels> (raw)
In-Reply-To: <C89T1R73NIXC.8UY5BOMY3J8F@mussels>


[-- Attachment #1.1: Type: text/plain, Size: 3168 bytes --]

On Sun Jan 3, 2021 at 5:28 PM -03, Érico Nogueira wrote:
> 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.

It seems those patches alone weren't enough. I just had the same issue
crop up again (though in a somewhat unorthodox setup).

From man.conf:

manpath /usr/share/man/pt_BR
manpath /usr/local/share/man
manpath /usr/share/man
manpath /home/ericonr/extern/i686-musl/usr/share/man

In the path from the last entry, I have:

/home/ericonr/extern/i686-musl/usr/share/man/pl.UTF-8/man1/wine.1
/home/ericonr/extern/i686-musl/usr/share/man/man1/wine.1
/home/ericonr/extern/i686-musl/usr/share/man/fr.UTF-8/man1/wine.1
/home/ericonr/extern/i686-musl/usr/share/man/de.UTF-8/man1/wine.1

These files are included as an attached tarball. None of the other paths
have a wine.X man page.

When I run `man wine`, I get the de.UTF-8 version of the man page, which
is the same situation I had with kate before.

>
> [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

Cheers,
Érico

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

  reply	other threads:[~2021-01-09  3:47 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-03 20:28 Érico Nogueira
2021-01-09  3:34 ` Érico Nogueira [this message]
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=C8EB8G8G5811.QTD2NQRMGVUR@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).