help / color / mirror / Atom feed
From: Ingo Schwarze <schwarze@usta.de>
To: Abigail G <dev@kb6.ee>
Cc: discuss@mandoc.bsd.lv
Subject: Re: man.cgi doesn't find symlinked manpages
Date: Fri, 8 Apr 2022 17:49:19 +0200	[thread overview]
Message-ID: <YlBZfy2nWtvj6275@asta-kit.de> (raw)
In-Reply-To: <d30674560026e12b0ac779c289e7cd862cd3869d.camel@kb6.ee>

Hello Abigail,

so far, i did not manage to reproduce.

So we have to inspect more closely what is going on on that particular

Abigail G wrote on Mon, Apr 04, 2022 at 01:25:13PM -0400:

> I'm working on tracking down an issue with the Void Linux instance of
> man.cgi, man.voidlinux.org, which uses mandoc v1.14.6.
> Manpages that are symlinks of other manpages are not included in the
> results of a man.cgi search, returning 404, but are confirmed to exist
> in the mandoc.db the cgi uses. An example of this is xlocate(1), which
> is a symlink of xtools(1). `man xlocate`, `apropos xlocate`, and
> `whatis xlocate` work fine locally on that host,

Those commands are probably not using the particular database nor
the directory hierarchy used by the CGI script (both inside the
webserver chroot), but instead a system-wide directory hierarchy
outside the chroot, probably somewhere below /usr/.

To help narrow down the problem, could you please get a local shell
on that machine, use the "cd" shell builtin command to change
into the webserver chroot, then "cd" down further the directory
containing all the man1 man2 man3... subdirectories for the
manual page collection your man.cgi is using.  When you changed to
the correct directory, the command "less ../manpath.conf" should show
the configuration file man.cgi is using, and the command "ls mandoc.db"
should find the mandoc database that man.cgi is using.

In this directory, could you please run these commands and show
the results:

   $ man -M . -w xtools
   $ man -M . -w xlocate
   $ man -M . xtools | head -n 1
   $ man -M . xlocate | head -n 1
   $ ls -ald man1/xtools.1 man1/xlocate.1

> but the same query via cgi does not when using the 'man' button.
> Using the 'apropos' button does, however.

On my test server man.bsd.lv, i have just done this:

   $ cd /var/www/vhosts/man.bsd.lv/man/
   $ vi manpath.conf    # to add a line reading "Test"
   $ mkdir Test
   $ cd Test
   $ mkdir man1
   $ cp /usr/share/man/man1/true.1 man1/xtools.1
   $ ln -s xtools.1 man1/xlocate.1
   $ ls -al man1/x*
  lrwxr-xr-x 1 schwarze mdocml    8 Apr 8 10:32 man1/xlocate.1 -> xtools.1
  -r--r--r-- 1 schwarze mdocml 2283 Apr 8 10:30 man1/xtools.1
   $ makewhatis .
   $ man -M . -w xtools 
   $ man -M . -w xlocate
   $ man -M . xtools | head -n 1   
  TRUE(1)                General Commands Manual               TRUE(1)
   $ man -M . xlocate | head -n 1
  TRUE(1)                General Commands Manual               TRUE(1)

And now


works for me whereas


do not.

So i suspect that something more might be going on in addition to merely
having a symbolic link.  No idea yet what it could be, though.

Maybe if you answer the questions above that might provide a clue.

> I've narrowed it down to the following in pg_search() in cgi.c:
> 	if (req->isquery && req->q.equal && argc == 1)
> 		pg_redirect(req, argv[0]);
> 	else if (mansearch(&search, &paths, argc, argv, &res, &ressz)
> == 0)
> 		pg_noresult(req, 400, "Bad Request",
> 		    "You entered an invalid query.");
> 	else if (ressz == 0)
> 		pg_noresult(req, 404, "Not Found", "No results
> found.");
> 	else
> 		pg_searchres(req, res, ressz);
> and the search mode that man.cgi is using (req->q.equal), which seem to
> imply that mansearch() is not finding the symlink in its search because
> of the mode of search that it is in.

The request for https://man.voidlinux.org/xlocate returns

  "No results found."

which means we somehow get into the "ressz == 0" branch for some reason.
So the mansearch(3) internal API function did not produce the desired
result.  Very strange indeed.

> Is this the intended behaviour?

I don't think so, but i don't see just yet where exactly the problem is.

> If so, can it be changed to match man,
> apropos, and whatis? Not finding the page in one search method is a
> bit unintuitive to me, at least.

Right, we should figure this out.  It looks mysterious.

 To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv

  reply	other threads:[~2022-04-08 15:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-04 17:25 Abigail G
2022-04-08 15:49 ` Ingo Schwarze [this message]
2022-04-09 15:59   ` Abigail G
2022-04-09 18:18     ` Ingo Schwarze

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YlBZfy2nWtvj6275@asta-kit.de \
    --to=schwarze@usta.de \
    --cc=dev@kb6.ee \
    --cc=discuss@mandoc.bsd.lv \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).