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

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

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

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

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

It occurs to me that there is something approaching prior art in the
form of commands, such as git and cvs, with subcommands.  "I want the
checkout provided by git" -> git checkout; "I want the checkout
provided by cvs" -> cvs checkout.

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

Agreed.  That should be considered separately.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B