[ 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      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>