From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: David Bremner <david@tethera.net>, Notmuch Mail <notmuch@notmuchmail.org>
Subject: Re: [PATCH v4 01/16] add util/search-path.{c,
 h} to test for executables in $PATH
In-Reply-To: <878tw2r0vf.fsf@maritornes.cs.unb.ca>
References: <1467970047-8013-1-git-send-email-dkg@fifthhorseman.net>
 <1467970047-8013-2-git-send-email-dkg@fifthhorseman.net>
 <878tw2r0vf.fsf@maritornes.cs.unb.ca>
User-Agent: Notmuch/0.22.1+88~g8d09e96 (https://notmuchmail.org) Emacs/24.5.1
 (x86_64-pc-linux-gnu)
Date: Fri, 12 Aug 2016 02:19:06 -0400
Message-ID: <87k2fmse5h.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha512; protocol="application/pgp-signature"
Precedence: list

--=-=-=
Content-Type: text/plain

On Fri 2016-08-12 01:51:16 -0400, David Bremner wrote:
> Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:
>
>> This is a utility function we can use to see whether an executa>
>> +    if (strchr (exename, '/')) {
>> +	if (0 == access (exename, X_OK))
>> +	    return TRUE;
>> +	else
>> +	    return FALSE;
>> +    }
>
> Should we distinguish between relative and absolute paths here?  I can't
> think of any security implications, but I'm wondering if a relative path
> is likely just a user error.

I don't think a relative path is necessarily a user error.  I certainly
use relative paths myself from time to time.

>> +	path = (char *) malloc (n);
>> +	if (! path)
>> +	    return FALSE;
>
> I kindof hate hiding the error here, although I agree it's
> unlikely. What about the unixy return 0 ok, 1 not found -1 error?
>
>> +	confstr (_CS_PATH, path, n);
>> +    }
>> +
>> +    tok = strtok_r (path, ":", &save);
>> +    while (tok) {
>
> I guess it's fine to modify path here, but another option is
> strtok_len (in string-util.h)

I'm ok with both of these changes -- do you want to propose a variant
for this patch?

thanks for going through and trying to get this stuff building again.

    --dkg

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJXrWpaXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFREIyRTc0RjU2RkNGMkI2NzI5N0I3MzUy
NEVDRkY1QUZGNjgzNzBBAAoJECTs/1r/aDcKtUMQAIupcnhxWxYyhOf28kjjIGKX
7Cf8KX5w40hfyhzipnILrKSl45TEea9E5ZNMKBiDs/vyQp1D9WLPR3shRfl+gWZC
jhJdiECyLfJ6nf1QnW+zNusRPYNdInDLSLB5AggoCgvOyXd34Cg8GiXynf/I6NdZ
kZqGjpdJAzV9MaDWOPjWJ2Sazwfu3CAjhLvRDCOLmtbPamHG16eOpno06uw5haPl
ZrHVt1PeZLErHS17eSCMKeHEe0sbHSaX88cbebTuunkzvLCRh/MUaUkZ7or7KDaZ
4ego7ZrVMMv6LbA1/h7Ao+TzFFO9GNKK7DeMHmRlHVSuKzD723Fzpd9hzHG+1MhU
/nsRcZHo8mZjPbyZzaVjgTslQeM1cIxX1Oo1AW7D/67PAc+cNey6p+H78m54oPqY
OUBqn5s1WqEdxLW6UvNaB5b8wYH1vMcBkkCeU/c95TIi6otR1wYKAWShMGTcjh1a
DsB802JqCl3+MHM0jMt2NeWSNgwrseHNHD+iaDC8Laogr8iy6m7geymoBhvSR+QU
l/Faxs0c5561yVuP2v/uFuY+SyT5OxpPCkNS/DN5bC5n5aObS6g3tnJvRagpcMDV
xzVmI1t4pDjGlS/uQESaj5VWEwtRzz/M9V3du5LBWh8heORWu1zfO/H2Zy/UKrSX
jf0kHVSo/66yizLiHwPJ
=CnBc
-----END PGP SIGNATURE-----
--=-=-=--