On Thu, Feb 10, 2000 at 10:25:02AM +0100, Ignatios Souvatzis wrote:
> 
> On Thu, Feb 10, 2000 at 08:19:23AM +0200, Lucio De Re wrote:
> > 
> > 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 "".
> 
> huh?
> 
> This might be the case for parsing the text... but at the kernel level,
> "." is definitely different from what parsing "~" produced (~ is not parsed
> by the kernel!)
> 
Bad analogy, I suppose.  What I'm trying to put across is the similarity
of behaviour, even though I appreciate that the actual implementation is
distinct, and that ~/ is expanded by the shell.

> And, if you equated "." with "~", where's the point of having a chdir()?
> 
Oh dear.  I was trying to say "analogous", not "equivalent".  My point - and
it's a small philosophical one - is that all of the prefixes "./", "../"
and "~/" (and "/", to be pedantic) produce "absolute" pathnames in at
least the sense I perceive.  The mechanism by which this is achieved is
incidental, as well as the location of the expansion (filesystem or
shell) and it would not be hard - but I appreciate the undesirability -
to change to such new semantics, scoring a few bonus points on the way,
as you have pointed out.

> Of course, just to mention it: we could adotp OS-9s method; OS-9 has a 
> current execution directory, different from the current working directory.
> 
That's pretty logical, in my book.  In fact, to a large extent, I assumed
that was the case with Unix, in that "foo" will not be excuted in the
current directory, unless "." or "" is included in the PATH variable.  In
that respect, Unix has an empty executables working directory, until a "/"
is included in the pathname to the executable.  There are two ways to
perceive this exceptional behaviour: (a) only single pathname components
are subject to PATH restrictions, the present case, or (b) all "relative"
pathnames are subject to it (the case I deem preferable, if only
because I can force "absoluteness" by prefixing my pathname with "./"
whereas I cannot force the PATH restriction on a relative address at all
without changing the standard).

I guess I can summarise my position by suggesting that it would be
preferable (in a theoretical sense) for Unix not to apply the cwd to
executables at all, but allow qualification of executable pathnames
with a locating prefix as an alternative to a PATH search.

++L