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