Inconsistent behavior when localized man pages exist

Inconsistent behavior when localized man pages exist

[Érico Nogueira]

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

Re: Inconsistent behavior when localized man pages exist

[Érico Nogueira]

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

Re: Inconsistent behavior when localized man pages exist

[Érico Nogueira]

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