James - > >> Either way, I see two options: > >> > >> 1) Save sys.path before calling PySys_SetArgv and restore it afterward. > >> 2) Prune the first element of sys.path after calling PySys_SetArgv. > >> > >> We know that PySys_SetArgv always adds an element to the front of > >> sys.path and we know that we're giving it a value that isn't valid (to > >> prevent a segfault in some warn() function I can't find a reference to). > >> > >> Adding an arbitrary, hopefully non-existent path in order to search for > >> and remove it just smells bad to me when there's defined behavior. My > >> initial idea when I got this bug was to simply do 2) but I changed to > >> the filter() patch later to be (I thought) more robust. > >> > >> I'd be interested in knowing where your Python install comes from so I > >> can see why it's behaving differently. > > > > I'm using Python 2.5. The implementation of PySys_SetArgv() uses > > realpath(). It expands "" to the current directory. I haven't looked > > at the details, but I suspect that's what is causing the behavior I > > notice. > > Then this appears to be a difference (bug?) in your libc. This is not > the case with glibc 2.7 or 2.8 (the two systems I can currently test > on). Those error with ENOENT (as specified by SUS[0]).
I'm on FreeBSD. I used this test program: #include <stdio.h> #include <sys/param.h> #include <stdlib.h> #include <errno.h> main() { char buf[PATH_MAX]; char *s; errno = 0; buf[0] = 0; s = realpath("", buf); printf("errno = %d; s = %s; buf = %s\n", errno, s, buf); } Result (when pwd is /tmp): errno = 0; s = /tmp; buf = /tmp The definition of realpath() doesn't say what happens for an empty string. It might handle it as "." or give an error. > > You can see this file here: > > http://svn.python.org/view/python/trunk/Python/sysmodule.c?rev=64856&view=markup > > > > I think using a magic directory name works better than assuming > > something about the python code, e.g. prepending an entry to sys.path. > > This is one of the express purposes of PySys_SetArgv, as I mentioned > earlier. The Python developers have stated multiple times[1][2] that > they consider the sys.path adjustment to be intended behavior and the > actual bug is implicit relative imports instead of defaulting to > absolute imports and using relative imports when requested. > > Either way, thanks for pointing out the issue about using a buggy libc. > I'll keep that in mind when I push patches to other projects. > > [0] - http://www.opengroup.org/onlinepubs/009695399/functions/realpath.html > [1] - http://bugs.python.org/issue946373 > [2] - http://lists.gnu.org/archive/html/emacs-devel/2008-09/msg00215.html Did you test my proposed solution on Linux? I think it should work everywhere. - Bram -- hundred-and-one symptoms of being an internet addict: 255. You work for a newspaper and your editor asks you to write an article about Internet addiction...in the "first person." /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ download, build and distribute -- http://www.A-A-P.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]