Cygwin和Windows路径冲突； 同时使用 Windows 和 cygwin Python

Question

I've installed cygwin on Windows XP. Mercurial on cygwin stopped working after I installed some software on Windows. The symptom can be simplified to python not being able to locate modules in its library:

>>> import os
Traceback (most recent call last):
  file "<stdin>", line 1, in <module>
ImportError: No module named os

One of the pieces of software I installed in Windows (subversion) uses python so now Windows has its own Python installation. Don't ask why I wish to use mercurial under cygwin and subversion under Windows; suffice to say I do, but that's beside the point. It seems cygwin tries to use the Windows python instead of its own, or at least that's what I think is happening. If that's not the cause, please enlighten me. Anyway...

$ find /cygdrive/c -name os.py /cygdrive/c/csvn/Python25/Lib/os.py /cygdrive/c/cygwin/lib/python2.6/os.py

echo $PATH confirms that /cygdrive/c/csvn/Python25 is before /usr/lib/python2.6. I'm no cygwin wiz, but from what I can tell /etc/profile adds the Windows path to cygwin's $PATH, and I don't know how to keep it from doing so. As a workaround I modified.profile to explicitly set PATH, excluding those paths from Windows. But, the problem remains:

$ echo $PATH
/usr/local/bin:/usr/bin:/usr/lib/python2.6
$ hg
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "/usr/bin/hg", line 10, in <module>
    import os
ImportError: No module named os

$ ls /usr/lib/python2.6/os.py
/usr/lib/python2.6/os.py

It looks like the path conflict has not actually been resolved, because when I issue the above "find" command again I get the same results, with /cygdrive/c/csvn/Python25/Lib/os.py showing up first. In theory there may be some other reason python isn't working on cygwin, but not being able to control my PATH would still be a problem. Any ideas?

Answer 1

Unfortunately my colleague who also had the problem already uninstalled the csvn thing, so I can't check. But reading the doc suggests the culpable variable might be $PYTHONHOME . Check whether it's set and try unsetting it!

Answer 2

Have you tried the solutions found in this other SO post ? Seems like a similar problem.