From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailout.scc.kit.edu (mailout.scc.kit.edu [129.13.185.202]); by fantadrom.bsd.lv (OpenSMTPD) with ESMTP id e1957d5b; for ; Sat, 29 Nov 2014 13:14:40 -0500 (EST) Received: from hekate.usta.de (asta-nat.asta.uni-karlsruhe.de [172.22.63.82]) by scc-mailout-02.scc.kit.edu with esmtp (Exim 4.72 #1) id 1XumXX-0007Od-Im; Sat, 29 Nov 2014 19:14:39 +0100 Received: from donnerwolke.usta.de ([172.24.96.3]) by hekate.usta.de with esmtp (Exim 4.77) (envelope-from ) id 1XumXX-0007hC-Gz; Sat, 29 Nov 2014 19:14:39 +0100 Received: from iris.usta.de ([172.24.96.5] helo=usta.de) by donnerwolke.usta.de with esmtp (Exim 4.72) (envelope-from ) id 1XumXX-0000sj-FB; Sat, 29 Nov 2014 19:14:39 +0100 Received: from schwarze by usta.de with local (Exim 4.77) (envelope-from ) id 1XumXX-0006zl-EO; Sat, 29 Nov 2014 19:14:39 +0100 Date: Sat, 29 Nov 2014 19:14:39 +0100 From: Ingo Schwarze To: Baptiste Daroussin Cc: tech@mdocml.bsd.lv Subject: Re: Allow gzipped .so and search .so in manpath Message-ID: <20141129181439.GD8575@iris.usta.de> References: <20141124143629.GB11567@ivaldir.etoilebsd.net> <20141126201033.GG26411@iris.usta.de> <20141126202413.GF82931@ivaldir.etoilebsd.net> <20141127001242.GH26411@iris.usta.de> <20141129175408.GD88765@ivaldir.etoilebsd.net> X-Mailinglist: mdocml-tech Reply-To: tech@mdocml.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141129175408.GD88765@ivaldir.etoilebsd.net> User-Agent: Mutt/1.5.21 (2010-09-15) Hi Baptiste, Baptiste Daroussin wrote on Sat, Nov 29, 2014 at 06:54:08PM +0100: > Shouldn't the look up for .so links be done in the manpath. No. That might end up including completely unrelated files that happen to be in the manpath before the intended file. It has to include the file in the *same* manpath directory. > For example I have the WindowMaker manpage (which should really > be a link in that case :D) installed here: > > /usr/local/man/man1/WindowMaker.1x.gz > > The content is the following: > .so man1/wmaker.1x.gz > > If I run: > ./mandoc /usr/local/man/man1/WindowMaker.1x.gz User error. > mandoc: man1/wmaker.1x: SYSERR: No such file or directory > mandoc: man1/wmaker.1x:1:19: FATAL: .so request failed: .so man1/wmaker.1x > > If I trace it it tries to open man1/wmaker.1x then man1/wmaker.1x.gz > but in the directory where I run the command. Yes. The man(1) command is responsible for changing the directory before running the formatter. If you run the formatter manually, you need to specify the directory manually, too: $ (cd /usr/local/man && mandoc man1/WindowMaker.1x.gz) That's one of the reasons .so links are so fragile. Oh. Now that i explain how it's supposed to work, i realize that i could do something about it. The makewhatis(8) utility already contains (relatively simple) code to split absolute filenames into a manpath (/usr/local/man) and a local file path (man1/WindowMaker.1x[.gz]). I might try to reuse that code in mandoc(1) = man -l to: * figure out the manpath for each absolute path given * try to chdir(2) there - if it fails, be silent about it - if it succeeds, remember the original working dir * open the file, run the parsers and formatters * return to the original working dir * proceed to the next file I'll think about it. Thanks for asking the question, Ingo -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv