tech@mandoc.bsd.lv
 help / color / mirror / Atom feed
From: Ingo Schwarze <schwarze@usta.de>
To: sternenseemann@systemli.org
Cc: tech@mandoc.bsd.lv
Subject: Re: [PATCH makewhatis] add NIXSTOREDIR configuration variable to support NixOS
Date: Wed, 31 Mar 2021 19:34:34 +0200	[thread overview]
Message-ID: <20210331173434.GA57338@athene.usta.de> (raw)
In-Reply-To: <060f9222-a388-a9fa-dc34-8f1981f8bf65@systemli.org>

Hi Lukas,

Earendil wrote on Tue, Mar 30, 2021 at 11:03:53PM +0200:
> On 3/30/21 10:30 PM, Ingo Schwarze wrote:

>> We could of course rename the variable to something more generic,
>> *if* a generic name for this concepts exists or can be invented
>> in a reasonable way.

> That would of course be nice. Mayeb something along the lines of
> EXTRA_BASEDIR

I don't like that.  The word "basedir" is jargon only used in the source
code in the file mandocdb.c (admittedly, it also appears in an error
message there, so the user may see it, which is probably not good).
The documentation calls more or less the same thing "manpath", see
the manual page man.conf(5), and the related environment variable
MANPATH, see the manual pages man(1) and apropos(1).

But the configuration variable we are trying to name does not point
to a manpath, so its name should not contain the words "manpath"
or "basedir".  A manpath contains man[1-9] and optionally cat[1-9]
subdirecties and nothing else, which is not the case for a homebrew
cellar nor for /nix/store/.  Yes, there may be some manual pages
inside /nix/store/, among many other things, but not in a manpath
structure.

> or SYMLINK_TARGET_EXCEPTION?

A bit better, yes.  But even though already long, it doesn't say
which rule is being flouted, nor what the exception is, and that
symlinks are involved is, in my opinion, not the most relevant part
of this makewhatis(8) feature, even though symlinks certainly are
relevant for the way it is used in Homebrew and NixOS.

> Seems hard to name in a concise way though.

I had one other idea while considering the naming.
Why not allow

  FOO_PATH="/Homebrew/Cellar:/nix/store"

and parse it like so (untested):

	const char	*pb;
	size_t		 len;

	*pb = FOO_PATH;
	while (*pb != '\0') {
		len = strcspn(pb, ":");
		if (strncmp(buf, pb, len) == 0)
			break;
		pb += len;
		pb += strspn(pb, ":");
	}
	if (*pb == '\0' && strncmp(buf, basedir, basedir_len) != 0) {
		say(...);
		continue;
	}

Now, how should that variable be called?

 * The name should end with "_PATH".
 * The makewhatis(8) program is allowed to read any files below
   this path, so the name should include "READ" and some word
   indicating permission.
 * Mentioning makewhatis in the name does not seem important.
   It is more or less clear anyway that man(1) itself can read
   anything given on the command line or found in the database,
   subject to file system permissions, of course.

So, maybe:

  READ_ALLOWED_PATH

What do you think?

> It's no matter and nothing really too interesting happens there, just
> wanted to link it for reference.

That's good.  I should also update the NixOS entries on

  https://mandoc.bsd.lv/ports.html

but maybe wait for the dust to settle first.

Yours,
  Ingo
--
 To unsubscribe send an email to tech+unsubscribe@mandoc.bsd.lv


  reply	other threads:[~2021-03-31 17:34 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-30 19:49 sternenseemann
2021-03-30 20:30 ` Ingo Schwarze
2021-03-30 21:03   ` sternenseemann
2021-03-31 17:34     ` Ingo Schwarze [this message]
2021-03-31 19:33       ` sternenseemann
2021-04-10 15:57       ` [PATCH v2 makewhatis] refactor HOMEBREWDIR into READ_ALLOWED_PATH sternenseemann
2021-04-10 16:15         ` sternenseemann
2021-08-03 16:42           ` sternenseemann
2021-08-05 12:35             ` Ingo Schwarze
2021-08-07  0:29               ` sternenseemann
2021-08-07 13:17                 ` 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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20210331173434.GA57338@athene.usta.de \
    --to=schwarze@usta.de \
    --cc=sternenseemann@systemli.org \
    --cc=tech@mandoc.bsd.lv \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).