[ On Thursday, February 10, 2000 at 13:28:49 (+0200), Lucio De Re wrote: ]
> Subject: Re: Shell behaviour regarding PATH
>
> 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 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?

My own personal introduction to hierarchical filesystems was Multics.
On Multics the pathname separator is '>' and relative pathnames are
explictly defined as those that never begin with '>'.  So far as I can
remember, and so far as my remaining manuals show, there is no concept
of having an alias for the current or parent directory in the Multics
filesystem.  Therefore you either have a relative pathname, or you
don't, and there's no possiblity of confusing an alias for your current
locality into being something that somehow makes a relative pathname
more absolute than it really is.  In Multics you have to use "pwd" and
string manipulations to find the name of your parent directory, for
example.

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.

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.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>