[PATCH 7/9] add a gpg_path value for notmuch_database_t

David Bremner david at tethera.net
Sat Dec 12 17:20:11 PST 2015


Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:

> On Fri 2015-12-11 17:02:33 -0500, Tomi Ollila wrote:
>> The above code finds gpg/gpg2 (when called w/ these args) from
>> _CS_PATH (seems to be /bin:/usr/bin by default in linux (tried to
>> look how this set in *BSD -- initially it looks like /usr/local/bin
>> not included but... maybe we let them to complain if this is the case
>> ... :/)
>> ... anyway, the full found path is not set anywhere -- how is it found
>> when used (exec*p() using $PATH? :O)
>
> Hm, according to exec(3):
>
>    Special semantics for execlp() and execvp()
>        The execlp(), execvp(), and execvpe() functions duplicate the
>        actions of the shell in searching for an executable file if the
>        specified filename does not contain a slash (/) character.  The
>        file is sought in the colon-separated list of directory pathnames
>        specified in the PATH environment variable.  If this variable
>        isn't defined, the path list defaults to the current directory
>        followed by the list of directories returned by
>        confstr(_CS_PATH).  (This confstr(3) call typically returns the
>        value "/bin:/usr/bin".)
>
> So this code probably also ought to be searching $PATH as well.  yuck.
> You'd think there would be a commonly-available function for doing this
> specific check without having to actually try to exec() something.

Without weighing in on the advisibility of searching for gpg in $PATH,
there is a glib function g_find_program_in_path. We're already linking
to glib (because of gmime mainly, but it's used other places as well).

The other point that occurs to me is that libgpgme solves this same
problem in src/posix-util.c. It also seems to search path, at least
optionally, although only if it cannot find gpgconf.



More information about the notmuch mailing list