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 available?
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: absolute: /bin/sh ./sh 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. relative: sh This is relative to each dir in the search path. So could refer to any of: /bin/sh /usr/bin/sh ./sh 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. NOTES 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. Duncan