From: Paul Smith <psmith@gnu.org>
To: Bruno Haible <bruno@clisp.org>
Cc: bug-gnulib@gnu.org
Subject: Re: [PATCH] findprog: Support searching in a specified path string
Date: Sun, 08 Sep 2019 10:03:38 -0400 [thread overview]
Message-ID: <377844c9fe46960a77d6e0ef0076a386bfa52a3a.camel@gnu.org> (raw)
In-Reply-To: <1668770.Rs7XutRyhN@omega>
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?
next prev parent reply other threads:[~2019-09-08 14:03 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-06 23:10 [PATCH] findprog: Support searching in a specified path string Paul Smith
2019-09-06 23:21 ` Paul Smith
2019-09-07 10:42 ` Bruno Haible
2019-09-07 13:17 ` Paul Smith
2019-09-08 11:38 ` Bruno Haible
2019-09-08 14:03 ` Paul Smith [this message]
2019-09-08 14:59 ` Bruno Haible
2019-09-08 16:25 ` Bruno Haible
2019-09-08 17:34 ` Paul Smith
2019-09-08 17:48 ` Bruno Haible
2019-09-08 17:59 ` Paul Smith
2019-09-09 18:54 ` Bruno Haible
2019-09-10 13:18 ` Paul Smith
2019-09-14 11:20 ` Bruno Haible
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=377844c9fe46960a77d6e0ef0076a386bfa52a3a.camel@gnu.org \
--to=psmith@gnu.org \
--cc=bruno@clisp.org \
--cc=bug-gnulib@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).