The man pages for exec(2) state:

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

Now, the "rc" shell - both under Plan 9 and the Unix clone - allows the 
a command such as "mh/comp" to be interpreted relative to the path, in 
my case this would cause "/usr/local/bin/mh/comp" to be executed.

On the one hand, I am very keen to use this mechanism to streamline the 
installation of binaries for the wide range of applications available 
(I find Windows' idea of dumping all executables into a single \WINDOWS 
directory particularly offensive, filling /usr/local/bin up similarly 
gives me a queasy feeling, and I have a vague idea that multiple 
architectures will be handled better this way, too), but on the other I 
can't really expect every application to be comfortable with "rc" as 
the shell, and certainly any other users of my system may be unhappy 
with the arrangement.

The question I am asking is "Is this historical behaviour, or is there 
a sound reason (security perhaps) for this somewhat counter-intuitive 
and inconvenient approach?"

The obvious follow up would be whether it makes sense to change this 
behaviour, if necessary controlled by a kernel toggle and/or a shell 
option.

I hope I'm not treading on any religious toes here.  I cut my teeth on 
Xenix on a 286, so I thought I had little left to learn about shells 
and their ilks and only recently discovered that something I never 
thought of questioning is in fact totally different from my 
expectations :-(

++L