Subject: Re: Shell behaviour regarding PATH
To: Greg A. Woods <>
From: Lucio De Re <>
List: tech-userlevel
Date: 02/09/2000 18:02:52
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

> 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

> > 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).