Hi Paul,
> > > prog = find_in_path_str ("myprog", lookup_path ());
> > >
> > > and if lookup_path() returns NULL it defaults to the environment
> > > PATH,
> >
> > I don't think NULL should be interpreted as "look in the default
> > PATH". Rather, the convention is that an empty or null PATH means
> > the current directory.
>
> I find that VERY odd, and possibly a security risk. According to
> POSIX, the behavior if PATH is not present or is empty is
> implementation-defined and my preference/expectation would be to behave
> as if the program is not found. However, that's a different
> discussion.
Your preference does not match what systems do.
Things are most robust if - the other differences set aside -
find_in_path (prog)
is equivalent to
find_in_path_str (prog, getenv ("PATH")).
I wouldn't want the two to make different interpretations of the
empty or absent PATH.
> > Note also that what you need is not merely an *attempt* to determine
> > the filename of the executable, but you need it always - since you
> > _don't_ want the program to be looked up in the parent's PATH. Thus
> > you need also a return value that indicates that the program was not
> > found in PATH.
>
> There is already a return value to that effect in find_prog_in_path():
> it returns the same pointer that was passed in.
No, the returned pointer is the same as the argument not only in the
"not found" case, but also in the "already contains a slash" case.
> > Otherwise,
> > assume
> > parent PATH = "/bin:/usr/bin"
> > child PATH = "/tmp"
> > program = "cat"
> > the find_in_path_str search would do a lookup in the child PATH, not
> > find it, return "cat", and the posix_spawnp would then find "cat" in
> > the parent PATH and invoke /bin/cat.
>
> Sorry, I should have called it out more clearly, but in my email I said
> that after this lookup we would invoke posix_spawn() (no "p").
Makes sense.
On the other hand, if the function already determined that the program
cannot be found, there's no point in calling posix_spawn() or execl().
To allow the caller to do this optimization, a NULL return value is useful.
> > This, in turn, means that we need to provide also an implementation
> > for Windows, Cygwin, EMX, DOS.
>
> Yes, clearly that would be ideal
OK, I just spent 1 hour determining the suffixes that the different
platforms use in their search.
> it's not needed for my use-case since
> I use it with posix_spawn() which obviously doesn't exist on these
> other platforms
I still hope someone will write a posix_spawn for native Windows...
> > And this means that it can't really share much with the existing
> > findprog.c. So the implementation should go into a different .c
> > file.
>
> I don't see why.
The original findprog.c does not need platform-specific knowledge,
since by definition it's merely an optimization. The code with
platform-specific knowledge will be significantly different.
Bruno
