Subject: Re: Shell behaviour regarding PATH
To: None <email@example.com>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 02/09/2000 10:46:13
[ On Wednesday, February 9, 2000 at 13:09:17 (+0200), Lucio De Re wrote: ]
> Subject: Shell behaviour regarding PATH
> I've raised this before, but I somehow wasn't convinced last time.
> From the exec(2) man page:
> The functions execlp() and execvp() will duplicate the actions of the
> shell in searching for an executable file if the specified file name does
> not contain a slash ``/'' character. The search path is the path speci-
> fied in the environment by ``PATH'' variable. If this variable isn't
> specified, the default path ``/bin:/usr/bin:'' is used. ...
> I'm not sure (I haven't looked at the sources) whether /bin/sh uses
> exec(2) or viceversa, but the above behaviour has an unpleasant
> side effects reflected in all common shells under NetBSD: if I type
> "bin/prog", the assumed target is not one of the directories in
> the PATH, but rather the current directory. There are many aspects
> of this behaviour I dislike to the point that I consider them harmful:
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!
> 1. This defeats the protection afforded "root" by not including "." in the
> PATH. Even though it is a less likely weakness, this strikes me as
> inappropriate and inconsistent.
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.
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.
> 2. This behaviour is identical to typing "./bin/prog" and therefore the
> reverse is not available. In other words, I can override the PATH
> selection by typing "./prog", thus being offered two distinct alternatives,
> whereas the moment the name has a "/" in it, these options are merged
> into an alternative I find unappetising, with no access to the
> alternative. Even the law of least surprise is defeated by this.
There are no surprises here. A relative path is a relative path,
whether it starts with "./" or not.
> 3. I cannot adopt Plan 9's approach of using named subdirectories of
> /bin to hold executables for various packages, which I find a very
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")
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.
> 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.
Greg A. Woods
+1 416 218-0098 VE3TCP <email@example.com> <robohack!woods>
Planix, Inc. <firstname.lastname@example.org>; Secrets of the Weird <email@example.com>