[Python-Dev] Testsuite fails on Windows if a space is in the path

[Steve Holden]

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
> sys.version"
> 
> 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
> sys.version""
> 
> (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.

regards
  Steve
-- 
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