Subject: Re: Shell behaviour regarding PATH
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Lucio De Re <email@example.com>
Date: 02/10/2000 08:19:23
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.