git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: "Carlos Martín Nieto" <cmn@elego.de>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH] run-command: don't try to execute directories
Date: Tue, 2 Oct 2012 17:26:45 -0400	[thread overview]
Message-ID: <20121002212645.GA26789@sigill.intra.peff.net> (raw)
In-Reply-To: <87bogkisas.fsf@centaur.cmartin.tk>

On Tue, Oct 02, 2012 at 09:32:11PM +0200, Carlos Martín Nieto wrote:

> >> @@ -101,8 +102,9 @@ static char *locate_in_PATH(const char *file)
> >>  		}
> >>  		strbuf_addstr(&buf, file);
> >>  
> >> -		if (!access(buf.buf, F_OK))
> >> +		if (!stat(buf.buf, &st) && !S_ISDIR(st.st_mode)) {
> >>  			return strbuf_detach(&buf, NULL);
> >> +		}
> >
> > So we used to say "if it exists and accessible, return that".  Now
> > we say "if it exists and is not a directory, return that".
> >
> > I have to wonder what would happen if it exists as a non-directory
> > but we cannot access it.  Is that a regression?
> 
> I guess it would be, yeah. Would this be related to tha situation where
> the user isn't allowed to access something in their PATH?

This code path is related to correcting EACCES errors into ENOENT. But
it does not bother checking permissions itself.  We know there is some
permission problem, because execvp told us EACCES, so we are only
checking whether such a file actually exists at all in the PATH. And
that is why we are using F_OK with access, and not X_OK.

So any reason for which stat() would fail would presumably cause
access(F_OK) to fail, too (mostly things like leading directories not
being readable), and I think converting the access into a stat is OK.

Adding the !ISDIR on top of it makes sense if you want to consider the
directory in your PATH to be a harmless thing to be ignored. However, I
am not sure that is a good idea. The intent of ignoring the original
EACCES is that it could be caused by totally uninteresting crap, like an
inaccessible directory in your PATH.

Whereas in this case, the error really is that we found "git-foo", but
it is somehow broken. And it almost certainly is a configuration error
on the part of the user (why would they put a git-foo directory in their
PATH? Presumably they meant to put its contents into the PATH).

So I think your implementation is fine, but I'm a little dubious of the
value of ignoring such an error.

-Peff

      parent reply	other threads:[~2012-10-02 21:27 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-02 14:46 [PATCH] run-command: don't try to execute directories Carlos Martín Nieto
2012-10-02 17:35 ` Junio C Hamano
2012-10-02 19:32   ` Carlos Martín Nieto
2012-10-02 19:59     ` Junio C Hamano
2012-10-02 21:26     ` Jeff King [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121002212645.GA26789@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=cmn@elego.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).