Subject: Shell PATH interpretation
To: None <firstname.lastname@example.org, email@example.com>
From: Lucio de Re <firstname.lastname@example.org>
Date: 11/27/1998 09:45:32
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
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