Return-Path: X-Original-To: notmuch@notmuchmail.org Delivered-To: notmuch@notmuchmail.org Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id 4F64F6DE0C3A for ; Sat, 12 Dec 2015 17:20:21 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -0.312 X-Spam-Level: X-Spam-Status: No, score=-0.312 tagged_above=-999 required=5 tests=[AWL=0.239, RP_MATCHES_RCVD=-0.55, SPF_PASS=-0.001] autolearn=disabled Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1xpn3UnaqHs for ; Sat, 12 Dec 2015 17:20:19 -0800 (PST) Received: from fethera.tethera.net (fethera.tethera.net [198.245.60.197]) by arlo.cworth.org (Postfix) with ESMTPS id 68C646DE0B4B for ; Sat, 12 Dec 2015 17:20:19 -0800 (PST) Received: from remotemail by fethera.tethera.net with local (Exim 4.84) (envelope-from ) id 1a7vKb-0008Mh-KL; Sat, 12 Dec 2015 20:20:09 -0500 Received: (nullmailer pid 18544 invoked by uid 1000); Sun, 13 Dec 2015 01:20:11 -0000 From: David Bremner To: Daniel Kahn Gillmor , Tomi Ollila , Notmuch Mail Subject: Re: [PATCH 7/9] add a gpg_path value for notmuch_database_t In-Reply-To: <87mvtgfws4.fsf@alice.fifthhorseman.net> References: <1449718786-28000-1-git-send-email-dkg@fifthhorseman.net> <1449718786-28000-8-git-send-email-dkg@fifthhorseman.net> <87mvtgfws4.fsf@alice.fifthhorseman.net> User-Agent: Notmuch/0.21+7~g55fb7da (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Sat, 12 Dec 2015 21:20:11 -0400 Message-ID: <87d1ubdu0k.fsf@zancas.localnet> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2015 01:20:21 -0000 Daniel Kahn Gillmor 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.