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

[<tlaronde%kergis.com@localhost>]

On Tue, Oct 01, 2024 at 11:54:02AM -0400, Mouse wrote:
> 
> >> [about the dot business]
> [...]
> 
> 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 (assuming of course that symlinks don't cause two of the
> apparently different directories to actually be identical); each one is
> interpreted relative to the path-so-far (with a starting point
> depending on whether there's a leading / or not).  . and .. are no
> different in that regard.  Indeed, you may note that (at least in the
> versions I have on hand) namei treats . and .. as special only when
> doing emulation-root things - it's the filesystems that handle them,
> and FFS, at least, implements them as ordinary directory entries in
> most respects.

Since it is the key, I will concentrate on the explanation of my point
of view concerning this.

LARONDE/Thierry is not a locator. It's an identifier. The location
where you will find this "resource" varies. The '/' in the identifier
is simply to fit in the way filesystem are organized in hierarchy.
It's "opportunistic".

When there is a '.' or a '..', you are not manipulating an identifier,
you are walking a path.

LARONDE/Thierry/.. (assuming there are other attributes and it's
implemented as a dir) is whether a stupid way of looking to the LARONDE
named people, or it is a path directive that could lead you somewhere
else than in the directory LARONDE/ if Thierry was a symlink.

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".  It's not an URI (because there are
different versions and for different hosts and different targets, so
it's not Universal) but a least it's an RI.

If one gives a program as ./this/prog, he is giving a path. The same
with this/../prog: he is walking a path. It's a locator, not an
identifier.

So---and on this I'm adamant---recognizing an identifier means a
hierarchical name (that happens to have the same syntax as a pathname)
without any path directive in it even not a "harmless" "/./".

My dot semantics is probably going too far (and in fact in the unknown,
even for me) or missing the present target by being aside.

I should simply make the test so that no leading or trailing '/', no
"^./", no "^../", no "/./", no "/../", no "/.$', no "/..$", beginning
being easy and since the macro requires the length of the string as
parameter, testing the end is lengthy but easy (after
verifying the size).

Since exec costs already much, I wanted to avoid a function call and
to have only macros, with the most limited number of tests (this is
the main motivation of the no "./" and no ".$").

And the good news is that only the definition in <pathsearch.h> has to
be changed.

Could we reach a kind of consensus about what is and what is not an
identifier?---but there has to be a difference: I can want gcc/cc or
texlive/latex, or kertex/latex on whatever system, not knowing where
it is, but still requiring this precise program wherever it is located
on the host, and allowing to have concurrently "texlive/latex" and
"kertex/latex" on the same system.
-- 
        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