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: Fri, 29 Jan 2021 01:38:57 -0300	[thread overview]
Message-ID: <11479a40-b540-ddf5-bbb7-8cffe0420217@disroot.org> (raw)
In-Reply-To: <C8EB8G8G5811.QTD2NQRMGVUR@mussels>

This confusion appears to have been mostly a distro issue in how man 
pages were indexed in the scripts and instructions we provided. 
makewhatis(8) was being used with the -a flag, which made it index more 
than only man pages under man* (and cat*) directories. With the scripts 
fixed, only the expected man pages are indexed into mandoc.db and `man 
<program>` works perfectly.

However, I still think it would be interesting to teach the mandoc suite 
how to access localized man pages without requiring one to change 
man.conf(5) or set MANPATH explicitly. I'm not sure how the UX would 
work when a mandoc.db exists (does man(1) sift through mandoc.db instead 
of choosing the first match? does makewhatis(8) index everything? ...), 
but I think the initial implementation, as a proof of concept, could be 
pretty simple if done without taking mandoc.db into account. I will try 
my hand at it.

Em 09/01/2021 00:34, Érico Nogueira escreveu:
> 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
 To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv

      reply	other threads:[~2021-01-29  4:39 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
2021-01-29  4:38   ` Érico Nogueira [this message]

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=11479a40-b540-ddf5-bbb7-8cffe0420217@disroot.org \
    --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).