> To: tech-userlevel@netbsd.org, tech-kern@netbsd.org

I'm not sending to tech-kern, since this has nothing to do with the
kernel.

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

> [...a shell that still uses the path if a / is present...]

Yes, my shell does this too, if a particular flag is set (it's optional
and selectable at run-time) - though I still am of the opinion that the
path should be ignored if the specified filename begins "./".

When a manpage says "the shell" it should (almost?) always be read to
mean /bin/sh.  I'm not quite sure why execlp/execvp exist, since they
*are* tied to a specific interpretation of the path.  (Probably
historical reasons.)

> 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?"

Whether it's "counter-intuitive" or "inconvenient" for the path to be
ignored for names containing slashes depends on what you're used to and
what you're expecting.  (Personally, I agree with you, but I can also
see how someone used to the "standard" behavior would feel otherwise.)

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

IMO it does not.  What you actually want may vary, depending on the
coder who wrote the code and/or the user who's using it; I can't see
any good way of dealing with all the cases.  In any case, I suspect
exec[lv]p are more or less set in stone by history....

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B