On Mon, Mar 26, 2012 at 8:19 PM, Jeff King <peff@xxxxxxxx> wrote: > This seems to come up about once a year. The short of it is that execve > will return EACCESS whether the file exists is not actually executable > by you, or if you have an inaccessible element in your PATH. execvp will > continue the search if it sees EACCESS, but will return EACCESS if it > finds nothing. So git just sees the EACCESS and doesn't know if you > have bogus entries in your PATH or if there is a permissions problem > with your executable files. > > For something like a shell, it's not that big a deal; either way, you > couldn't execute the command in question. For git, it matters more > because we first try to exec an external command, and then fall back to > an alias (because externals take precedence over aliases). > > 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). Thanks for the detailed explanation! > I think the general feeling last time this came up was "why not just > remove the cruft from your PATH?" Because I didn't know there was cruft in my path. The cruft was put there by a sloppily written project setup script that is not under my control, and it may be difficult to get the owner of that script to fix it. Even after the script is fixed, we're certain to run into other sloppy scripts in the future. It took me quite a while to figure out the real problem the first couple of times this happened, and I'm sure many of my colleagues who use the same project setup script would not have figured it out at all, so if there's anything Git can do to make it easier for them, I think it's worth doing. BTW repairing the crufty PATH is not easy, because the project setup script will have added many unfamiliar things to PATH, so you have to check them one by one to figure out which ones are bad. > But I would personally be OK with > option (3) above, and it is probably not that hard to implement. I would be happy with option (3). This is the part where I sheepishly confess that I probably can't find time to work on this myself, but if option (3) is also acceptable to Junio, I may be able to find a coworker to do it. So Junio, do you have any objection to (3)? James -- 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