duncan.coutts at worc.ox.ac.uk
Sun Dec 9 21:45:15 EST 2007
On Sun, 2007-12-09 at 23:35 +0000, Ian Lynagh wrote:
> > > > > but I'm not convinced that isn't a bug too.
> > > >
> > > > That is because it also uses the system path. See execvp vs execve.
> > >
> > > Right, but is that what it ought to do?
> > If not there's no way to execute a program that lives in the current
> > directory if there is also a program by that name earlier on the search
> > path, like in /bin.
> I'm not sure we're on the same wavelength. What I mean is, should
> rawSystem use execvp rather than execv? Or should both options be
We certainly need the standard rawSystem to use the path (ie execvp) or
everything will break (you'd not be able to run "sh" it'd have to be
"/bin/sh"). It's certainly reasonable to provide the alternative that
does no patch searching though I doubt it's terribly useful since people
can already specify absolute paths, or paths relative to the current
directory so the only difference is in this corner case. I don't think
it affects much else.
> > If exec "./true" and "true" have to run the same program.
> > So the point is when it comes to search paths, a ./ path is not really
> > relative at all.
> I don't understand that.
Ok, so for the purposes of path searching there are two kinds of paths:
They are relative to the root and current directory respectively. There
is no ambiguity there. We know the fs root and the current directory, so
that refers unambiguously to a specific file.
This is relative to each dir in the search path. So could refer to any
or whatever the system's search path is.
>From man 3 execvp
Special semantics for execlp() and execvp()
The functions execlp() and execvp() will duplicate the actions of the
shell in searching for an executable file if the specified filename
does not contain a slash (/) character. The search path is the path
specified in the environment by the PATH variable. If this variable
isn't specified, the default path ``:/bin:/usr/bin'' is used.
On some other systems the default path (used when the environment does
not contain the variable PATH) has the current working directory listed
after /bin and /usr/bin, as an anti-Trojan-horse measure. Linux uses
here the traditional "current directory first" default path.
So it's very clear that posix treats "./blah" differently from "blah"
for this function at least. It's true that the kernel does not and we do
not need to either. We can have a rawSystem version that does searching
and a version that does no searching. Then we could say that the version
that does searching will look for "./blah" the search path, which may
not contain ".". I don't know if that wouldn't be more confusing.
More information about the Libraries