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:

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.
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.
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
   sensible approach to organising a multi-platform environment. This
   need not appeal to everyone, but in my investigations has stood up
   best as a structure.  Plan 9 is documented at
      <http://plan9.bell-labs.com/plan9/>
   and despite some philosophical clashes with NetBSD, is also my
   favorite model on which to base platform independence in a Unix-like
   environment.
   (By way of llustration, I may have installed a seldom used copy of
   gmake: in Plan 9 I would type "gmake/make" to execute it, whereas
   under NetBSD I have to use /usr/bin/gmake/make to achieve the same
   result; if gmake/make becomes very popular, in Plan 9 I would union
   mount /usr/bin/gmake on /usr/bin to override the standard make.)
4. I don't think that treating "bin/prog" as identical to "./bin/prog"
   is semantically valid.  Besides removing an option as mentioned
   in 2.  above, it is also inconsistent with the otherwise clear
   distinction between "relative" and "absolute" pathnames.  It is
   my proposition that the exec(2) (and shell) implementation should
   use this distinction, rather than the arbitrary _presence_ of
   a "/" somewhere in the name to decide whether to search the PATH
   or not.

End of rant.  I am really curious to know whether most participants on
this list feel my arguments above are empty, and if so, why.  And, yes,
I'll happily apply myself to changing the behaviour, if I can be sure
that I don't have to repeat these changes every time an upgrade occurs.

As for borrowing the directory hierarchy from Plan 9 "lock, stock and
barrel", I'm waiting for the bugs to be ironed out of the "union"
filesystem (_that_ bit I haven't the skills and time for) before
embarking on an _alternative_ hierarchy campaign.  My hope is to be
able to choose at installation time which of two conventions to adopt
and to make sure they are both equally workable.  But not just yet :-)

++L