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.0 required=5.0 tests=T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 6044 invoked from network); 8 Apr 2022 15:49:27 -0000 Received: from bsd.lv (HELO mandoc.bsd.lv) (66.111.2.12) by inbox.vuxu.org with ESMTPUTF8; 8 Apr 2022 15:49:27 -0000 Received: from fantadrom.bsd.lv (localhost [127.0.0.1]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 8c0c8ae6 for ; Fri, 8 Apr 2022 10:49:24 -0500 (EST) Received: from scc-mailout-kit-02.scc.kit.edu (scc-mailout-kit-02.scc.kit.edu [129.13.231.82]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 366c0c47 for ; Fri, 8 Apr 2022 10:49:23 -0500 (EST) Received: from hekate.asta.kit.edu ([2a00:1398:5:f401::77]) by scc-mailout-kit-02.scc.kit.edu with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (envelope-from ) id 1ncqrR-00FgHo-OA; Fri, 08 Apr 2022 17:49:22 +0200 Received: from login-1.asta.kit.edu ([2a00:1398:5:f400::72]) by hekate.asta.kit.edu with esmtp (Exim 4.94.2) (envelope-from ) id 1ncqrP-004H7l-Ib; Fri, 08 Apr 2022 17:49:19 +0200 Received: from schwarze by login-1.asta.kit.edu with local (Exim 4.92) (envelope-from ) id 1ncqrP-0006qq-V1; Fri, 08 Apr 2022 17:49:19 +0200 Date: Fri, 8 Apr 2022 17:49:19 +0200 From: Ingo Schwarze To: Abigail G Cc: discuss@mandoc.bsd.lv Subject: Re: man.cgi doesn't find symlinked manpages Message-ID: References: X-Mailinglist: mandoc-discuss Reply-To: discuss@mandoc.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Hello Abigail, so far, i did not manage to reproduce. So we have to inspect more closely what is going on on that particular machine. 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 /var/www/vhosts/man.bsd.lv/man/Test/man1/xlocate.1 $ man -M . -w xlocate /var/www/vhosts/man.bsd.lv/man/Test/man1/xlocate.1 $ 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 https://man.bsd.lv/Test/xlocate works for me whereas https://man.voidlinux.org/xlocate https://man.voidlinux.org/xlocate.1 https://man.voidlinux.org/man1/xlocate.1 https://man.voidlinux.org/?query=xlocate 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. Yours, Ingo -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv