On Mon, Apr 24, 2017 at 05:17:24PM -0700, Jonathan Nieder wrote: > > This is due to only checking 'access()' when locating an executable in > > PATH, which doesn't distinguish between files and directories. Instead > > use 'stat()' and check that the path is to a regular file. Now > > run-command won't try to execute the directory 'git-remote-blah': > > > > $ git ls-remote blah://blah > > fatal: Unable to find remote helper for 'blah' > > > > Signed-off-by: Brandon Williams <bmwill@xxxxxxxxxx> > > For the interested, the context in which this was reported was trying > to execute a directory named 'ssh'. Thanks for a quick fix. > > Technically this bug has existed since > > commit 38f865c27d1f2560afb48efd2b7b105c1278c4b5 > Author: Jeff King <peff@xxxxxxxx> > Date: Fri Mar 30 03:52:18 2012 -0400 > > run-command: treat inaccessible directories as ENOENT > > Until we switched from using execvp to execve, the symptom was very > subtle: it only affected the error message when a program could not be > found, instead of affecting functionality more substantially. Yeah, I'm pretty sure I didn't think at all about access() matching directories when doing that commit. Using stat() does seem like the right solution. -Peff