On Tue, Nov 22, 2011 at 12:54 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Imagine you did not have alias.aliasedinit in ~/.gitconfig but had a > script called $(pwd)/searchpath/git-aliasedinit which we would fail to > execute. What message would we get in that case? Currently I think we get > permission denied. Correct. > Would we get the same with your patch, or something that does not hint > at all that there is a permission problem? Nope. That would be just as confusing and inarguably incorrect at that -- bash differentiates between commands that exist, but cannot be executed due to permissions (access denied) and paths that cannot be read (they are ignored in the search). > See also the "tangent" part of > > http://thread.gmane.org/gmane.comp.version-control.git/171755 > > and the discussion that follows it. I do not think we reached any > conclusion nor a patch. There's no black-on-white conclusion there. I get the impression that no one really has an idea of what they want when encountering EACCES. Git has to do what's reasonable to provide the user with information. Currently I think it does too little. Jonathan N. gave the option of optionally using libexplain[1]. It's pretty verbose and accurate: fatal: cannot exec 'git-frotz': execvp(pathname = "git-frotz", argv = ["git-frotz"]) failed, Permission denied (13, EACCES) because the process does not have search permission to the pathname "/home/frans/devsw/searchpath" directory, the process effective UID 1000 "frans" matches the directory owner UID 1000 "frans" and the owner permission mode is "r--", and the process is not privileged (does not have the DAC_READ_SEARCH capability): Success I wouldn't be in favor of adding the dependency just to enable users to track down PATH issues though. Also, I think "Cannot access /home/frans/devsw/searchpath" would just as well do the trick. For Jonathan's example[2] libexplain doesn't have a clear answer either: fatal: cannot exec 'git-frotz': execvp(pathname = "git-frotz", argv = ["git-frotz"]) failed, Permission denied (13, EACCES): Permission denied If git is going to do some diagnostics on why the execvp returned EACCES, it can still give a few hints. Most of the more likely options are then ruled out. Frans [1] http://article.gmane.org/gmane.comp.version-control.git/171860 [2] http://article.gmane.org/gmane.comp.version-control.git/171848 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html