[Python-Dev] Testsuite fails on Windows if a space is in the path
steve at holdenweb.com
Sat Sep 16 20:41:42 CEST 2006
Martin v. Löwis wrote:
> The test suite currently (2.5) has two failures on Windows
> if Python is installed into a directory with a space in it
> (such as "Program Files"). The failing tests are test_popen
> and test_cmd_line.
> The test_cmd_line failure is shallow: the test fails to properly
> quote sys.executable when passing it to os.popen. I propose to
> fix this in Python 2.5.1; see #1559413
> test_popen is more tricky. This code has always failed AFAICT,
> except that the test itself is a recent addition. The test tries
> to pass the following command to os.popen
> "c:\Program Files\python25\python.exe" -c "import sys;print sys.version"
> For some reason, os.popen invokes doesn't directly start Python as
> a new process, but install invokes
> cmd.exe /c "c:\Program Files\python25\python.exe" -c "import sys;print
> Can somebody remember what the reason is to invoke cmd.exe (or COMSPEC)
> in os.popen?
> In any case, cmd.exe fails to execute this, claiming that c:\Program
> is not a valid executable. It would run
> cmd.exe /c "c:\Program Files\python25\python.exe"
> just fine, so apparently, the problem is with argument that have
> multiple pairs of quotes. I found, through experimentation, that it
> *will* accept
> cmd.exe /c ""c:\Program Files\python25\python.exe" -c "import sys;print
> (i.e. doubling the quotes at the beginning and the end). I'm not quite
> sure what algorithm cmd.exe uses for parsing, but it appears that
> adding a pair of quotes works in all cases (at least those I could think
> of). See # 1559298
> Here are my questions:
> 1. Should this be fixed before the final release of Python 2.5?
> 2. If not, should it be fixed in Python 2.5.1? I'd say not: there
> is a potential of breaking existing applications. Applications
> might be aware of this mess, and deliberately add a pair of
> quotes already. If popen then adds yet another pair of quotes,
> cmd.exe will again fail.
> 3. If not, should this be fixed in 2.6 in the way I propose in
> the patch (i.e. add quotes around the command line)?
> Or can anybody propose a different fix?
> 4. How should we deal with different values of COMSPEC? Should
> this patch only apply for cmd.exe, or should we assume that
> other shells are quirk-compatible with cmd.exe in this
> respect (or that people stopped setting COMSPEC, anyway)?
> Any comments appreciated,
1. Because this is almost certainly Windows version-dependent I would
suggest that you definitely hold off trying to fix it for 2.5 - it would
almost certainly make another RC necessary, and even that wouldn't
guarantee the required testing (I sense that Windows versions get rather
less pre-release testing than others).
2. I agree with your opinion: anyone for whom this is an important issue
has almost certainly addressed it with their own (version-dependent)
workarounds that will break with the change.
3/4. Tricky. I don't think it would be wise to assume
quirk-compatibility across all Windows command processors. On balance I
suspect we should just alter the documentation to note that quirks int
he underlying platform may result in unexpected behavior on quoted
arguments, perhaps with an example or two.
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden
More information about the Python-Dev