[Python-Dev] Re: Weird error handling in os._execvpe
Steve M. Robbins
Tue, 27 Aug 2002 15:57:57 -0400
I think the patch associated with this thread has an unintended
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.