On Thu, Feb 10, 2000 at 10:41:40AM -0500, Greg A. Woods wrote:
> 
> I think perhaps part of your perception is based on some special meaning
> of the directories "." and "..".  Most of the folks I know who's first
> hierarchical filesystem was not the Unix filesystem don't have this
> misconception that "." and ".." somehow can be used to make a pathanme
> "absolute" in any way.  They are in fact just simple aliases for the
> current and parent directory names.  Furthermore although "." and ".."
> are firmly entrenced in the Unix standards too, what would you think if
> someone proposed that they be renamed or even removed?  What if their
> names were not standardised even within one system?
> 
Well, the two outlooks you present above are not conflicting.  My
version is slightly more complex, but has a more general meaning which,
to my mind, makes it the more powerful concept, at the expense of
semantic equivalence of "./" as a prefix with "./" as an inner member
of a pathname.  But these are sufficiently uncoupled not to create a
problem.

> In reality the concept of "relative pathnames" is exactly the same in
> Unix -- just that you do have simple aliases for the current and parent
> directories thus alleviating the need to use "pwd" and string
> manipulations to figure these things out.
> 
My point is that we have some pragmatic shortcuts in the "./" and "../"
prefixes (and in "/", of necessity) and that obscures the philosophical
value of treating them as analogous to "~/".  Whether it was Bill Joy or
someone else who added "~/" and "~logname/" to the "C" shell, their
thinking must have been more similar to mine than to Stephen Bourne's.
And it is this type of lateral thinking I was keen to explore in my
posting.

> You're suggesting a change in the fundamental handling of $PATH for
> executable searching be made so that it won't be disabled unless the
> pathname given for argv[0] is either absolute or qualified by one of the
> aliases for the current or parent directory.  I'm saying that although
> there may be merit in your argument it is fruitless to even consider
> this idea for Unix without first considering that you will be breaking a
> fairly fundamental assumption built into the current Unix standards.
> 
I stopped proposing the change quite a while back.  I _am_ keen to
add an option (with some difficulty, but the "rc" shell has already
laid the foundations) to enable this behaviour and explore the
ramifications.  It will be different, but I don't think it needs to
lead to a schism.

++L