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

[Paul Smith]

On Sun, 2019-09-08 at 13:38 +0200, Bruno Haible wrote:
> > the path search is done
> > on the _parent's_ PATH environment value not the one passed in to
> > posix_spawnp().  I don't want that, I need the search done in the
> > child's environment.  I can't decide if this behavior by
> > posix_spawnp() is correct or not, and the POSIX spec isn't clear,
> > but it's how it works (at least on GNU/Linux).
> 
> For me, the POSIX spec [1] is clear: envp "constitute[s] the
> environment for the new process image". It does not say that the
> search for the program is done through envp.

It doesn't make clear where the search is done, one way or the other. 
But I agree there's no portability problem here.

> If there were many libc functions that take a '[const] char**'
> environment as argument, I would agree that this was the way to go.
> But there are no getenv, setenv, putenv variants that take a 'char
> **' arguments; so it appears that POSIX and libc APIs don't recognize
> 'char **' as a valuable data type.

Well, none of those functions need a char**.  But char** appears in a
number of other POSIX functions (any function that takes an environment
for example!  Which is what this function would do.)  However either
way is fine with me.

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

> > rather than having to do something like:
> > 
> >     const char *path = lookup_path ();
> >     if (path)
> >       prog = find_in_path_str ("myprog", path);
> >     else
> >       prog = find_in_path ("myprog");
> 
> If the caller needs this logic, it should better be coded explicitly
> like this.
> 
> 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.  I don't see why we
should make the interface any different for the new function.  It
allows the returned value to always be usable, avoids memory allocation
if not needed, and provides a simple way to check whether the file was
found or not.

> 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").  You're
right, but if the user doesn't want the system to do the lookup she
simply won't use the posix_spawnp() method.  I wrote:

> > So what I want to do is run find_in_path_str() passing in the PATH
> > from the child's environment then pass the result to posix_spawn.

> This, in turn, means that we need to provide also an implementation
> for Windows, Cygwin, EMX, DOS.

Yes, clearly that would be ideal--it's not needed for my use-case since
I use it with posix_spawn() which obviously doesn't exist on these
other platforms, but additional portability would be a good thing.

The current implementation of find_prog_in_path() seems to use that
same reasoning to avoid implementing path search on these other
platforms: it apparently assumes that the calling code can just leave
it to the platform to resolve instead.

> 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.  Path lookup would use identical methods so if it's
useful to have find_prog_in_path_str() implemented for all these other
platforms, why wouldn't that same code be used to allow
find_prog_in_path() to work properly for all these other platforms as
well?