On Wed, Feb 09, 2000 at 02:11:49PM -0500, der Mouse wrote:
> 
> > 4. I don't think that treating "bin/prog" as identical to
> >    "./bin/prog" is semantically valid.  Besides [...], it is also
> >    inconsistent with the otherwise clear distinction between
> >    "relative" and "absolute" pathnames.
> 
> What are you on and where can I get some?  Both bin/prog and ./bin/prog
> are perfectly good relative paths, relative to the process's current
> directory.  That one begins with the somewhat special component "." has
> little to nothing to do with that.
> 
Stage fright?! :-)

Because "./foo" and "foo" can be differentiated, I see little reason for
not extending this to "./foo/bar" and "foo/bar".  To me, treating "./"
(as a prefix) as semantically analogous to "~/" is more consistent than
making it analogous to "".

Currently execvp() makes an exception on "/" within the pathname string.
My proposal is merely to use "/", "./" and "../" _as_prefixes_ (as all
security-aware programs already do) as the basis to apply the exception.

The difference, as I keep repeating, is subtle: the current behaviour
(no, I'm not suggesting we _change_ it) is inconsistent, as mentioned
above, and precludes PATH searches where they would be useful; and the
real change is in the philosophical issue of what is a "relative" and
what is an "absolute" pathname.  I see prefix "/", "./" and "../" as
forcing an "absolute" meaning to the pathname; others prefer to think
of the last two as "relative", but have no qualms considering "~/" as
"absolute" (if they ever think about it).

It is subtle and it is arbitrary, but I believe my version adds
flexibility and consistency.

++L