On Wed, Aug 06, 2008 at 01:39:15AM +0100, Simon McVittie wrote: > Shouldn't Python builds of vim avoid this bug by stopping '' from being > prepended to sys.path in the first place?
As I mentioned earlier[0][1] in the bug log, I don't think removing '' from sys.argv is the correct change to make in Vim. > After looking through Python initialization and vim's if_python.c it > seems that the way forward is to set Python's argv, via PySys_SetArgv(), > to have a non-empty and absolute first argument. > > vim sets Python's argv to { "", NULL }, which according to a comment is to > avoid a crash when warn() is called. Changing that to { "/usr/bin/vim", NULL } > would seem to solve this problem - but for that matter, any safe value is > fine. The way Vim is using PySys_SetArgv (and therefore the resulting behavior) is exactly following the recommended use of PySys_SetArgv according to upstream's documentation[2]. > A safe value for argv[0] is any value where there won't be files dir/*.py or > dir/*/__init__.py, where dir == dirname(argv[0]). So setting argv[0] to > "/", "/usr/lib/something" or "/usr/share/vim" would be safe too, for instance. > > I'm afraid I haven't tested this in vim itself (the multiple builds take a > while...) but the attached program demonstrates it: > > [EMAIL PROTECTED] gcc -o484305 `python-config --cflags` `python-config > --ldflags` 484305.c > [EMAIL PROTECTED] ./484305 > (I have no argv!) > ['/usr/lib/python2.5', '/usr/lib/python2.5/plat-linux2', > ... more output ... > '/var/lib/python-support/python2.5/pyinotify'] > [EMAIL PROTECTED] ./484305 "" > [''] > ['', '/usr/lib/python2.5', '/usr/lib/python2.5/plat-linux2', > ... more output ... > '/var/lib/python-support/python2.5/pyinotify'] > [EMAIL PROTECTED] ./484305 "/usr/bin/vim" > ['/usr/bin/vim'] > ['/usr/bin', '/usr/lib/python2.5', '/usr/lib/python2.5/plat-linux2', > ... more output ... > '/var/lib/python-support/python2.5/pyinotify'] While this does provide a workaround for the issue, this is behavior inherent in the way Python is designed and should be fixed in Python. If we choose to instead address every application that embeds Python, we're just creating an endless stream of work for ourselves. From a quick check via Google's codesearch, at least X-Chat[3], Gnumeric[4], python-nautilus[5], and gedit[6] are likely to have this same problem. N.B., most of the above projects use a single-element argv of the project name. This is no different than using a single-element argv of "" since PySys_SetArgv attempts to resolve argv[0] to an absolute path and uses "" when it is unable to do so. [0] - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=484305#51 [1] - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=484305#61 [2] - "If there isn't a script that will be run, the first entry in argv can be an empty string." http://docs.python.org/api/initialization.html#l2h-881 [3] - http://ln-s.net/27az [4] - http://ln-s.net/27ay [5] - http://ln-s.net/27b1 [6] - http://ln-s.net/27b9 -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature