Bug#493937: [Patch] Prevent loading of Python modules in working directory
Bram at moolenaar.net
Fri Nov 14 20:42:08 UTC 2008
> > > This is incorrect. In Vim's current code, PySys_SetArgv is called with
> > > an argv that is simply an empty string (and a terminating NULL
> > > sentinel). This causes sys.path's first element to be the empty string,
> > > thus causing any Python import statements to use Vim's current working
> > > directory as the first location to check for the requested module.
> > >
> > > The filter specifically removes any elements in sys.path that evaluate
> > > to false (i.e., the empty string).
> > That is not what happens for me. Somehow somewhere the empty entry is
> > changed to the full path of the directory above the current directory.
> > I don't know where, but I see it happening. I have tried this with:
> > :py import sys
> > :py print sys.path
> > > Using the attached print_sys.path.diff, the following is printed when I
> > > start Vim (the sys.path before and after my suggested filter() command):
> > >
> > > ['', '/usr/lib/python2.5', '/usr/lib/python2.5/plat-linux2', '/usr/lib/python2.5/lib-tk', '/usr/lib/python2.5/lib-dynload', '/usr/local/lib/python2.5/site-packages', '/usr/lib/python2.5/site-packages']
> > > ['/usr/lib/python2.5', '/usr/lib/python2.5/plat-linux2', '/usr/lib/python2.5/lib-tk', '/usr/lib/python2.5/lib-dynload', '/usr/local/lib/python2.5/site-packages', '/usr/lib/python2.5/site-packages']
> > As mentioned, for me the first entry is not '' but a path. The filter
> > command you suggested doesn't remove it. I don't know where the
> > difference between our systems comes from.
> This is bizarre as I don't see how this could be happening in vanilla
> Python code, so it seems like your install has been patched to add this
> behavior. 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
You can see this file here:
I think using a magic directory name works better than assuming
something about the python code, e.g. prepending an entry to sys.path.
A later version may correct the mistake and not change sys.path for an
empty string. I think my version of the fix handles those situations.
hundred-and-one symptoms of being an internet addict:
252. You vote for foreign officials.
/// Bram Moolenaar -- Bram at Moolenaar.net -- 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 ///
More information about the pkg-vim-maintainers