filepath

[Duncan Coutts]

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