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

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

>> This distinction you are drawing between locators and identifiers
>> is, as far as I can tell, entirely your own invention when it comes
>> to ocating executables (or indeed any other file(name) operation).
> Well, not really.  There are already the difference between URI and
> URL.

That's why I added the "when it comes to..." part.  I'm not clear on
the distinction between a URI and a URL either, but I didn't want to
get sidetracked down that rabbit-hole.  Maybe this one would make more
sense to me if I understood that one, but I don't see any reason I
should have to grok Web naming in order to understand PATH searching.

> And even in POSIX, there is a stub for it with the (fuzzy)
> distinction between "path" and "file".

Perhaps.  My impression is that, when there is a distinction, "file"
refers to what in NetBSD is a kernel struct file, that is, an open file
table entry, whereas "path" refers to a string representation of a way
to locate a file relative to a current working directory.  If true,
then what we are discussing here is entirely on the path side of it;
files in that sense are irrelevant, as far as I can see, to this
discussion.

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

It costs few instructions in the sense of instructions executed; it
costs a good deal more in terms of instructions present in the memory
space.

As for it being premature...how long have you been running with it?  If
it's less than a year, I would call it premature.

>> 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.
> The problem, when using such filenames, is that one has whether to
> put everything flat in the same directory, or [...]

Only if you insist on implementing it entirely in the filesystem.  If
the shell recognizes your syntax, whichever syntax you choose, and
translates it into whatever you have in the filesystem, this issue
evaporates.

> 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 don't.  You're breaking an existing facility even for people who
choose (whether from ignorance of its existence or from not finding it
suitable for them) to not use the new facility that came along with it.

I strongly believe that you should preserve the existing semantics in
the absence of your magic enable.

> I prefer strong typing against weak typing,

You prefer.  This implies that reasonable disagreement is possible.

Imposing your preferences on everyone else, especially when doing so
breaks existing code (shellscripts, here), strikes me as a bad idea.

> and if bar is searched and not executed in the cwd, even if it exists
> there, why should bar/foo behave differently?).

The answer, of course, is "because it contains a slash".  As for why
that makes a difference, by this point, I think "because it's always
been that way" is answer enough.  Thousands-to-millions of shell
scripts, I estimate, depend on the existing semantics.  (This may even
be mandated by POSIX; I don't know enough to say.)

I just looked at a NetBSD build log.  In it I find, among numerous
others,

build/genmodes -h > tmp-modes.h
build/genmodes -m > tmp-min-modes.c

It _was_ for relatively old NetBSD, but it still is an example in the
wild of an automated procedure depending on this syntax working.

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

It hampers bar/foo working the way it always did in tbe absence of
opting in to the new feature.

It introduces a distinction between some paths and other paths that, as
far as I can tell, is completely new as far as executable file location
goes.  It also, to me, appears (a) rather ill-defined and (b)
completely pointless except for its use as justification for the
executable location semantics you're trying to introduce.

/~\ 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