> 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4