[Python-Dev] Re: Weird error handling in os._execvpe

[Guido van Rossum]

> I think the patch associated with this thread has an unintended
> consequence.
> 
> In http://mail.python.org/pipermail/python-dev/2002-August/027229.html
> Zack pointed out three flaws in the original code:
> 
>     [...]
>     Third, if an error other than the expected one comes back, the
>     loop clobbers the saved exception info and keeps going.  Consider
>     the situation where PATH=/bin:/usr/bin, /bin/foobar exists but is
>     not executable by the invoking user, and /usr/bin/foobar does not
>     exist.  The exception thrown will be 'No such file or directory',
>     not the expected 'Permission denied'.
> 
> The patch, as I understand it, changes the behaviour so as to raise
> the exception "Permission denied" in this case.
> 
> Consider a similar situation in which both /bin/foobar (not executable
> by the user) and /usr/bin/foobar (executable by the user) exist.
> Given the command "foobar", the shell will execute /usr/bin/foobar.
> If I understand the patch correctly, python will give up when it
> encounters /bin/foobar and raise the "Permission denied" exception.
> 
> I believe this just happened to me today.  I had a shell script named
> "gcc" in ~/bin (first on my path) some months back.  When I was
> finished with it, I just did "chmod -x ~/bin/gcc" and forgot about it.
> Today was the first time since this patch went in that I ran gcc via
> python (using scipy's weave).  Boy was I surprised at the message
> "unable to execute gcc: Permission denied"!
> 
> I guess the fix is to save the EPERM exception and keep going
> in case there is an executable later in the path.

This is definitely a bug.  Can you or Zack provide a patch?

I've opened a bug report:

http://python.org/sf/601077

--Guido van Rossum (home page: http://www.python.org/~guido/)