>> 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 mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
