On Wed, Feb 09, 2000 at 10:46:13AM -0500, Greg A. Woods wrote:
> 
> Read again the part that says "if the specified file name does not
> contain a ``/'' character."  I.e. the searching feature is not available
> at all for your example, and for good reason!
>  
Agreed.  Perhaps I presented my case poorly.

> Huh?  If you type a '/' in the pathname then presumably you know that
> you're using the current working directory if you type a relative path.
> 
Do I?  I think that's an artifice, and an ugly one, at that.

> If your scheme were used instead suddenly there'd be a major discrepancy
> between the way relative paths worked when they were used as command
> names and when they were used as arguments.  This would be very bad.
> 
Exactly the case where argv(0) is involved.  Why is that an acceptable
exception only if there is no "/" in the name?

> There are no surprises here.  A relative path is a relative path,
> whether it starts with "./" or not.
> 
Wrong.  "./abc" is an absolute path, "./" and "../" and their composites
are abbreviations.

> Although the plan-9 approach has its advantages it simply cannot work
> with the PATH scheme of Unix shells, nor in plan-9 shells for that
> matter.  You need kernel support in the form of the plan-9 bind() call
> in order to make your view of the filesystem look the way you want it
> to.  (see the rc(1) and bind(1) plan-9 manual pages and note that the
> use of $path in rc is "discouraged")
> 
But typing "kfs/diskcmd" is not discouraged, it is in fact used extensively
in commands.  And it means that to run "netscape" once when I log on, I
don't have to either clutter the system directories or to put
/usr/local/netscape in the PATH.  The traditional
</usr/local/<applic>/{bin,sbin,etc,lib}> structure is a proverbial PITA
and does horrendous things to the shell environment, including making it
unreadable.

> In fact Plan-9 doesn't have execlp() because 'bind' is used to construct
> one single directory that contains a view of all programs you might want
> to run in a given session.  Plan-9 tries very hard to totally abolish
> the idea of a "path" in which executables are searched for.
> 
A great idea, indeed.  It's just that it does not have to extend to put
_all_ applications in "/bin", otherwise they could have been placed there
to start with, not nicely arranged one layer further down, as they are
presently.

> > 4. I don't think that treating "bin/prog" as identical to "./bin/prog"
> >    is semantically valid.
> 
> Huh?  *Every* filesystem access works the same way in this regard with
> relative pathnames and always has.  See answer to #2 above.
> 
As I stated, "./" is an abbreviation, and in my book, it makes "./file"
an absolute, not a relative name.  Just like "~/file", only somewhat more
transparent (or is that opaque?  sometimes English defeats me totally).

++L