Re: [PATCH] findprog: Support searching in a specified path string

[Paul Smith]

On Sun, 2019-09-08 at 16:59 +0200, Bruno Haible wrote:
> 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")).

My suggestion was that BOTH these functions should not assume the CWD
if PATH is empty or missing, not that they should behave differently.

> 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.

Mm.  In my situation I invoked the exec/spawn function anyway, even if
the program was not found.  That ensures that the error handling etc.
is identical in all situations.  I'll need to consider whether the
optimization is sufficiently large, at least in my case, to warrant the
potential difference in behavior.

> > > 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...

That would be nice; posix_spawn is much closer to native Windows API
behavior than fork/exec (from what little I know of it).

> > > 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.

My personal opinion is that it's not difficult to come up with ways
findprog can be useful _in addition_ to simply being a precursor to
exec, and when used like that it would be beneficial to have the full
lookup.  However, I guess now that findprog-in exists that could be
used instead (with getenv ("PATH")) rather than findprog.

Thanks for working on this Bruno!