Subject: Re: Shell PATH interpretation
To: None <email@example.com>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 11/27/1998 09:25:59
> To: firstname.lastname@example.org, email@example.com
I'm not sending to tech-kern, since this has nothing to do with the
> 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
> 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
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....
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B