Re: Allow gzipped .so and search .so in manpath

[Ingo Schwarze <schwarze@usta.de>]

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