Jeff King <peff@xxxxxxxx> writes: > This seems to come up about once a year.... > ... > So basically our options are: > > 1. Start treating EACCESS silently as ENOENT. The downside is that we > fail to report the proper error when the file really does have > permissions problems (we would say "command not found", but that is > misleading). > > 2. Implement our own execvp, differentiating between "path not > available for looking in" and "we found the command, but there was > a permissions problem". I think somebody was working on this a few > months ago (search for "add exeecvp failure diagnostics") but it > seems to have fizzled. > > 3. If we get an EACCESS, remember it, try to do the alias lookup, and > then if that fails, report the "Permission denied" error (not > "command not found"). That is following the spirit of what execvp > does (it will find later entries in the PATH if they are there, but > otherwise will remember the EACCESS error). > > From what I can tell, dash uses stock execvp, and ends up closest to > (3). Bash seems to have implemented their own path lookup, as it will > distinguish between the two cases as in (2): > ... > I think the general feeling last time this came up was "why not just > remove the cruft from your PATH?" But I would personally be OK with > option (3) above, and it is probably not that hard to implement. http://thread.gmane.org/gmane.comp.version-control.git/171755/focus=171838 shows that it was almost exactly a year ago; we tried (2) and nobody liked it. I got an impression from the discussion in it that #3 may give confusing messages to the end users, but I didn't think the issues through. -- 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