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

[Paul Smith <psmith@gnu.org>]

On Sat, 2019-09-07 at 12:42 +0200, Bruno Haible wrote:
> Hi Paul, 
> > find_prog_in_path() always uses the PATH value in the current
> > environment.  It can be very useful to search for programs on
> > a path without having to modify the environment first.
> > 
> > Provide find_in_path_str() which takes a path string to search.
> > If the path passed in is NULL, fall back to searching in the
> > environment's PATH value.
> 
> I have nothing against extending the 'findprog' module in principle.
> 
> But the interface that you propose looks odd to me:
> 
>   * Why one function that always uses $PATH and one function that
>     uses a given set of directories _or_ $PATH?
>     Why not simpler: one function that always uses $PATH and one
>     function that uses a given set of directories?

It was simpler to implement that way: less duplication of code between
the two implementations, albeit only by a few lines.  Also it can be
handy for the user; they can use something like:

    prog = find_in_path_str ("myprog", lookup_path ());

and if lookup_path() returns NULL it defaults to the environment PATH,
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");

Of course it does mean you can't avoid looking in the user's
environment, if you wanted to, so that's a downside.

I don't have a strong preference myself.

>   * For the function that uses a given set of directories, isn't
>     it easier for the caller to provide a NULL-terminated array
>     of directories, rather than to glue them together with a
>     platform-dependent separator (':' or ';')?

Because that's not my use-case :).  I already have a PATH string, it's
just not in my current environment.  I don't want to have to break it
up myself; in fact if it was already broken up it would be
straightforward for me to use it directly without importing findprog. 
See below.

> Because of this oddity, I have to ask: What is the use-case that
> you have in mind? The use-case of the existing find_in_path function
> is when a program wants to optimize multiple invocations (spawn/exec)
> of one given program. What's yours?

I'm addressing https://savannah.gnu.org/bugs/?56834

I want to invoke a child process, and I need the program I'm going to
invoke to be searched for in a PATH which is (potentially) different
than the PATH which is active in the parent.

When you use execlp(), you can just assign the child's environment
before you invoke the exec.  Since you've already forked you're not
modifying the parent's environment.

However, with posix_spawnp() that doesn't work: 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).

At the same time, I don't want to be running putenv() to set then
reset the PATH environment variable in the parent every time I invoke
a command.

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.


I suppose an even simpler interface, for me, would be something like:

    find_in_path_envp (const char *prog, const char **envp);

where it would look up PATH in the environment passed in, so I don't
have to do the lookup of PATH, and use that instead of getenv().  But I
don't know if that's as generally useful an interface.