From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 24852 invoked from network); 29 Jan 2021 04:39:09 -0000 Received: from bsd.lv (HELO mandoc.bsd.lv) (66.111.2.12) by inbox.vuxu.org with ESMTPUTF8; 29 Jan 2021 04:39:09 -0000 Received: from fantadrom.bsd.lv (localhost [127.0.0.1]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id f9654b4a for ; Thu, 28 Jan 2021 23:39:05 -0500 (EST) Received: from knopi.disroot.org (knopi.disroot.org [178.21.23.139]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 61aa2882 for ; Thu, 28 Jan 2021 23:39:04 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by disroot.org (Postfix) with ESMTP id AEB5650E05 for ; Fri, 29 Jan 2021 05:39:02 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at disroot.org Received: from knopi.disroot.org ([127.0.0.1]) by localhost (disroot.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gog_hDzK-M0H for ; Fri, 29 Jan 2021 05:39:01 +0100 (CET) From: =?UTF-8?Q?=c3=89rico_Nogueira?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1611895140; bh=Jm6dgsmmpRVOSdXZFBzo9XqcA53eQJHZTcT6H8eo1dA=; h=From:To:Reply-To:References:Subject:Date:In-Reply-To; b=HtIDRN03jNn/3bvzQJsoQmwWtg94hy832NekbAClFtJCTDgCrKvfrJbJGANUHrzHl BXsTDmYflfGcPnvicHZik5eePAGC48Rvp0HZF/GfV6luPRcQytBNoo13ANvqnXh3+s wb0qsDCOSYmaimEvh16WC6CvZx67fdGMV5AHZCE1D7XH4YYh7/prU500g/hB43TyZx r66dAjWdNy0+ElTQC8NApHkpJ23gF3EMq7Ydjuntg7E+mx70GzxJ5qls5fuY0/zhD3 QZv7QfCezwUACM1C5RG+OzFsIRa5Ltl7m3ZdNqKqDKj4uvnv+6cIqofBB1LQhzaXsP w7MS304KziTEw== To: discuss@mandoc.bsd.lv Reply-To: discuss@mandoc.bsd.lv References: Subject: Re: Inconsistent behavior when localized man pages exist Message-ID: <11479a40-b540-ddf5-bbb7-8cffe0420217@disroot.org> Date: Fri, 29 Jan 2021 01:38:57 -0300 X-Mailinglist: mandoc-discuss Reply-To: discuss@mandoc.bsd.lv Mime-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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 ` 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