Re: [PATCH v6 12/11] run-command: don't try to execute directories
- From
Jeff King <peff@peff.net>
- Date
- Apr 25, 2017, 02:56 UTC
- Message-ID
- <20170425025634.q3n3umu3trhycigm@sigill.intra.peff.net>
- In-Reply-To
- <20170425001724.GG28740@aiede.svl.corp.google.com>
On Mon, Apr 24, 2017 at 05:17:24PM -0700, Jonathan Nieder wrote:
Show 24 quoted lines
> > 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@google.com> > > 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@peff.net> > 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