The problem is that the python path name is quoted if it contains spaces.  The launcher does not remove the extra quotes and fails.

I 'solved' by editing the pip.exe to remove the quotes.

ps - Windows programs are normally installed under c:\Program Files or c:\Program Files (x86).  That should be the default in the installer if possible.

I've previously reported this issue against setuptools (which generates the executable) and apparently they consider it a "feature". I don't have the link handy from my phone, but if you find the issue on bitbucket you can help attract some more attention to this.

See issue 21699. This is fixed in distlib 0.1.9. The latest pip uses distlib 0.2.0, so just update from pip 1.5.6 to 6.0.3.

    C:\>"C:\Program Files\Python27\Scripts\pip.exe" --version                                                               
    pip 6.0.3 from C:\Program Files\Python27\lib\site-packages (python 2.7)

Instructions for upgrading:
https://pip.pypa.io/en/latest/installing.html#upgrade-pip

Having pip not work after a straight install to the normal place you'd install it on windows can't be a feature.

Even after I changed the .exe, pip itself breaks on the same problem.  Basically, you can't install python to
the normal place on windows until this is fixed.

Josh

On Dec 27, 2014, at 9:49 AM, Steve Dower <report@bugs.python.org> wrote:

> 
> Steve Dower added the comment:
> 
> I've previously reported this issue against setuptools (which generates the executable) and apparently they consider it a "feature". I don't have the link handy from my phone, but if you find the issue on bitbucket you can help attract some more attention to this.
> 
> ----------
> 
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue23121>
> _______________________________________

The safest fix would be to make subprocess strip double-quotes from the executable path.

Double quote (") is not an allowed character in Windows file systems.  There is no case under 
which it can be correct to spawn a process in Windows where the path is quoted.

http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx

On Dec 27, 2014, at 4:04 PM, Joshua Ellinger <report@bugs.python.org> wrote:

> 
> Joshua Ellinger added the comment:
> 
> Having pip not work after a straight install to the normal place you'd install it on windows can't be a feature.
> 
> Even after I changed the .exe, pip itself breaks on the same problem.  Basically, you can't install python to
> the normal place on windows until this is fixed.
> 
> Josh
> 
> On Dec 27, 2014, at 9:49 AM, Steve Dower <report@bugs.python.org> wrote:
> 
>> 
>> Steve Dower added the comment:
>> 
>> I've previously reported this issue against setuptools (which generates the executable) and apparently they consider it a "feature". I don't have the link handy from my phone, but if you find the issue on bitbucket you can help attract some more attention to this.
>> 
>> ----------
>> 
>> _______________________________________
>> Python tracker <report@bugs.python.org>
>> <http://bugs.python.org/issue23121>
>> _______________________________________
> 
> ----------
> 
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue23121>
> _______________________________________

If distlib 0.2.0 fixes this, then it should be fixed in pip 6+ when installing from Wheels. If the same problem exists in setuptools then it'll need to get fixed in setuptools (or pip will need to start writing it's own console scripts when installing from sdist too).

> If the same problem exists in setuptools then it'll need to 
> get fixed in setuptools (or pip will need to start writing 
> it's own console scripts when installing from sdist too).

Will setuptools eventually switch to using distlib also? Currently setuptools has a different problem. Instead of errnously double quoting the EXE path, it doesn't quote it at all. As you can see in the cdb debugger output below, CreateProcessA is called without properly quoting the path to python.exe (register rdx is the 2nd parameter, lpCommandLine). 

    C:\>cdb "C:\Program Files\Python27\Scripts\test.exe"

    [clip]

    0:000> bp kernel32!CreateProcessA
    0:000> g
    Breakpoint 0 hit
    kernel32!CreateProcessA:
    00000000`77a4acf0 4c8bdc          mov     r11,rsp
    0:000> db @rdx        
    00000000`00585c40  43 3a 5c 50 72 6f 67 72-61 6d 20 46 69 6c 65 73  C:\Program Files
    00000000`00585c50  5c 50 79 74 68 6f 6e 32-37 5c 70 79 74 68 6f 6e  \Python27\python
    00000000`00585c60  2e 65 78 65 20 22 43 3a-5c 50 72 6f 67 72 61 6d  .exe "C:\Program
    00000000`00585c70  20 46 69 6c 65 73 5c 50-79 74 68 6f 6e 32 37 5c   Files\Python27\
    00000000`00585c80  53 63 72 69 70 74 73 5c-74 65 73 74 2d 73 63 72  Scripts\test-scr
    00000000`00585c90  69 70 74 2e 70 79 22 00-00 ab ab ab ab ab ab ab  ipt.py".........
    00000000`00585ca0  ab ab ab ab ab ab ab ab-ab fe ee fe ee fe ee fe  ................
    00000000`00585cb0  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................

So test.exe will actually run C:\program.exe, if it exists. For example:

    C:\>type program.c
    #include <stdio.h>
    int main(int argc, char *argv[])
    {
        int i;
        for (i=0; i < argc; i++)
            printf("%s\n", argv[i]);
        return 0;
    }
    
    C:\>dir /b C:\program.exe
    program.exe
    
    C:\>"C:\Program Files\Python27\Scripts\test.exe"
    C:\Program
    Files\Python27\python.exe
    C:\Program Files\Python27\Scripts\test-script.py

I do not know what setuptools plans on with regards to distlib sorry.

As 2.7 is now out of support, I'm going to go ahead and close this issue.