Re: [PATCH] Allow qualified filename (bar/foo) PATH searching.

[<tlaronde%kergis.com@localhost>]

On Tue, Oct 01, 2024 at 01:34:04PM -0400, Mouse wrote:
> >> Well, I think my point was that _every_ pathname component is
> >> path-relative.  The "foo"s in /usr/bin/foo, /tmp/foo,
> >> /home/mouse/foo, and xyz/foo bear no relation to one another except
> >> similarity of spelling [...].  . and .. are no different in that
> >> regard.
> 
> > Since it is the key, I will concentrate on the explanation of my
> > point of view concerning this.
> 
> This is indeed key.
> 
> This distinction you are drawing between locators and identifiers is,
> as far as I can tell, entirely your own invention when it comes to
> locating executables (or indeed any other file(name) operation).
> 

Well, not really. There are already the difference between URI and URL.
And even in POSIX, there is a stub for it with the (fuzzy) distinction
between "path" and "file".

> This is not to say it's a bad thing.  But I _do_ think that it is very
> premature to try to put it into NetBSD in its present, highly
> experimental, form.  (Into the shared NetBSD tree, that is.  It is
> entirely appropriate to put it into _your_ NetBSD as an experiment.
> I've added various things to my NetBSD as experiments; I can go into
> them here if anyone's interseted, but I think that should be a separate
> thread if it happens at all.)

But it can be activated only by an environment variable and if it is
not set, it costs very few instructions in the shells binaries, or in
execvp(3) or posix_spawnp(3).

> 
> > The crucial point here is to allow "qualified" filenames that I name
> > identifiers.  gcc/cc is a not a path, even if it is implemented using
> > the Unix filesystem syntax; it is an identifier saying "I want the C
> > compiler provided by gcc".  [...]
> 
> This is a coherent point of view, though whether gcc/cc or cc/gcc makes
> more sense depends on whether you think of it as "I want a gcc thing,
> in particular its C compiler" or "I want a C compiler, in particular
> the one provided by gcc" (and indeed I would expect disagreement over
> which string goes with which mindset).
> 
> This is a sane UI feature.  Where I think your proposal goes off the
> rails is implementing it at a (new) common path-search level rather
> than as a shell-level UI feature in shells which want to provide it.
> 
> I think part of what's going on here is that you have chosen a
> qualification separator that happens to be the same as the pathname
> component delimiter, leading to confusing the feature with its
> implementation.

But there are already other choices. To take the example of G.R.A.S.S.
(KerGIS for me), all the utilities dealing with vector start by 'v',
then a dot and an action (or a direction 'in', 'out', a dot and an
action). So it is organized and there could be texlive.latex or
texlive-latex vs kertex.latex or kertex-latex. But this is qualifying
by changing the filename, while it is natural to have a hierarchy
using the filesystem syntax. It's natural.

The problem, when using such filenames, is that one has whether to
put everything flat in the same directory, or to add special
directories to the PATH with the obligation, if several "packages"
provide an utility with the same leaf name, to decide which one
should come first---and if one wants bar/acme more than foo/acme,
but foo/this instead of bar/this, how to do it?

It is easier to put a directory, regrouping all related utilities,
and to be able to use the qualified name instead of having everything
flat.

Everything allowed now (if I drop---as I will---my dot specification)
remains possible after (except "bar/foo" being executed in current
dir; this will have to be, explicitely, "./bar/foo", or it will be
searched, not executed in the current dir; but as I have written, I
consider this an improvement---I prefer strong typing against weak
typing, and if bar is searched and not executed in the cwd, even if it
exists there, why should bar/foo behave differently?).

And for the implementation, very little code is added because it is
added at the root of things. Implementing this in shells would be
adding spaghetti code everywhere, with ad hoc processing for utilities
taking the name of an utility as parameter.

Here, if one decides to use the feature with simply:

$ export PATH_SEARCH_OPT="Q"

in whatever shell:

$ bar/foo

will work as well as :

$ ls . | xargs bar/foo

and so on. And programming (for the exec[lv]p, posix_spawnp and hence
system(3) too) will work as well.

I see what it can possibly add; I fail to see, as it is absolutely up
to the user, what it hampers...

But there is no problem: the feature is implemented in:

https://github.com/tlaronde/BeSiDe

for the ones interested. Whether it ends in NetBSD sources is another
matter, not for me to decide :-)
-- 
        Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C