Repository navigation
Windows-style path is not recognized under cygwin #90907
Description
Activity
mikekaganski commented
on Feb 14, 2022 mikekaganskimannequinMannequinAuthorUsing cyqwin 3.3.4-2, and python3:
Python 3.9.10 (main, Jan 20 2022, 21:37:52)
[GCC 11.2.0] on cygwinTrying this bash command line:
python3 C:/path/to/script.py
results in this error:
"python3: can't open file '/cygdrive/c/path/to/curdir/C:/path/to/script.py': [Errno 2] No such file or directory"
OTOH, calling it like
python3 /cygdrive/c/path/to/script.py
gives the expected output:
"usage: script.py [-h] ..."
It seems that python3 doesn't recognize "C:/path/to/script.py" to be a proper full path under cygwin, while most other cygwin apps handle those fine. E.g.,
nano C:/path/to/script.py
opens the script for editing without problems.
The mentioned path syntax is useful and supported under cygwin, so it would be nice if python3 could support it, too. Especially useful it is in mixed development environment, mixing Windows native tools and cygwin ones; using such path style allows to use same paths for both kinds of tools, simplifying scripts.
Are you running from bash (or another cygwin shell), or from cmd.exe, or something else?
How did you install the version of python you're executing in the examples you provided? To my knowledge, cygwin's installer doesn't have a 3.9 available.
I don't see this behavior on cygwin's python3.8, either from cmd.exe or from zsh.
mikekaganski commented
on Feb 14, 2022 mikekaganskimannequinMannequinAuthorThanks for looking at this!
Are you running from bash (or another cygwin shell), or from cmd.exe, or something else?
:) Citing myself:
Trying this *bash* command line:
To my knowledge, cygwin's installer doesn't have a 3.9 available.
:) Citing myself:
> Trying this *bash* command line:
Oops, sorry for missing that.
As for 3.9: it's not available through the 64 bit installer (at least, I don't see it there). I'll look and see what's involved in installing it.
Are you running the 32- or 64-bit version?
Also: I suspect this is a cygwin problem that will need to be reported upstream.
Does Cygwin not use : as a path list separator? (What would normally be
; on Windows.)Perhaps the CPython build needs to be patched specially here to handle
different separator character.mikekaganski commented
on Feb 14, 2022 mikekaganskimannequinMannequinAuthorAs for 3.9: it's not available through the 64 bit installer (at least, I don't see it there). I'll look and see what's involved in installing it.
I don't remember if I did something special to install it; however, just maybe you need to install python39 directly.
Are you running the 32- or 64-bit version?
64-bit.
Does Cygwin not use : as a path list separator?
It uses : as path separator:
$ echo $PATH /opt/lo/bin:/usr/local/bin:/usr/bin:/cygdrive/c/Program Files/AdoptOpenJDK/jdk-11.0.7.10-hotspot/bin:/cygdrive/c/Program Files (x86)/Common Files/Oracle/Java/javapath:/cygdrive/c/ProgramData/Oracle/Java/javapath:/cygdrive/c/Windows/System32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0:...
But obviously, it can't use Windows-style paths in the $PATH (for that reason?).
MSYS2 has basically the same problem when the script is passed as a Windows path, except it uses "/c" for the "C:" drive instead of "/cygdrive/c".
# python3 -VV Python 3.9.9 (main, Dec 28 2021, 11:05:23) [GCC 11.2.0] # echo $PWD /proc # python3 C:/Temp/test.py python3: can't open file '/proc/C:/Temp/test.py': [Errno 2] No such file or directoryWindows paths in the command-line arguments appear to be passed without conversion:
# python3 -ic 1 C:/Temp/test.py >>> import os >>> open(f'/proc/{os.getpid()}/cmdline').read().split('\0') ['python3', '-ic', '1', 'C:/Temp/test.py', '']They're generally supported:
>>> open('C:/Temp/test.py').read() 'import sys\nprint(sys.executable)\n\n' >>> os.path.samefile('C:/Temp/test.py', '/c/Temp/test.py') True >>> os.path.abspath('C:/Temp/test.py') 'C:/Temp/test.py'realpath() doesn't support them:
>>> os.path.realpath('C:/Temp/test.py') '/:/Temp/test.py'But the C API _Py_wrealpath() does:
>>> import ctypes >>> path = (ctypes.c_wchar * 1000)() >>> ctypes.pythonapi._Py_wrealpath('C:/Temp/test.py', path, 1000) 1484496 >>> path.value '/c/Temp/test.py'lazka commented
on Feb 15, 2022 lazkamannequinMannequinAfaik Cywin programs only work with native Windows paths if the paths happen to get directly passed to the OS APIs and not interpreted in any way before that. So I don't think this is a bug and expected behavior.
Use "cygpath C:/path/to/script.py" to convert the path to the right format first.
I disagree that this is "expected behavior". The majority of Cygwin programs (including languages such as Perl, etc.) work just fine with Windows paths. This is by design, to avoid Windows users having to constantly call 'cygpath' every time they execute something from the command line, or want to pass it a path pasted from a Windows Explorer window or other source that produces Windows paths. See here for some documentation of this:
https://cygwin.com/cygwin-ug-net/using.html#pathnames-win32
I don't know to what degree this support for Windows paths is due to the Python distribution itself, versus to some kind of patching that the Cygwin team or the Cygwin support libraries may do to it to add support for Windows, but it generally works, at least for paths that don't have Windows-specific things like embedded spaces.
Cygwin's version of Python 3.8 worked fine in this regard. When we upgraded to Python 3.9, things suddenly broke, and we saw the behavior described in this bug report. I think that this behavior is a regression between versions 3.8 and 3.9, and I would very much like it to be fixed. I'm not sure who is responsible for fixing it, however.
Some evidence that this is a regression:
C:\example>copy con test.py
#!/usr/bin/env python3
print('hello')
^ZC:\example>c:\cygwin64\bin\python3.8 test.py
helloC:\example>c:\cygwin64\bin\python3.9 test.py
helloC:\example>c:\cygwin64\bin\python3.8 C:\example\test.py
helloC:\example>c:\cygwin64\bin\python3.9 C:\example\test.py
/usr/bin/python3.9: can't open file '/cygdrive/c/example/C:\example\test.py': [Errno 2] No such file or directoryCygwin Python 3.9 apparently does not recognize that paths starting with "C:\" are absolute Windows paths, and so it tries to join them to the current directory as if they were relative paths before trying to invoke the python script.
Any advice on how to get a bug report for this regression to the right team as soon as reasonably possible? This bug is very inconvenient, and breaks a lot of our scripts. It makes Python dramatically less useable than other languages (Perl, Ruby, etc.) under Cygwin, and may force us to downgrade to Python 3.8 until it is fixed.
Reacted by John Neffenger and JoroAny advice on how to get a bug report for this regression to the right team as soon as reasonably possible?
You should report it to the cygwin python maintainers (whoever they are, I'm afraid I don't know). Either they will be able to fix it (most likely) or they will be able to pinpoint what core Python behaviour change is affecting this.
I absolutely agree with @Sporking
All other cygwin programs take windows paths and work fine.
The workaround what @pfmoore suggested makes usage of cygwin python pretty hard. Especially when some bat files should call python. If they call cygpath and current installation of python is native, it would fail. There are at least 3 cases - native, cygwin, mingw. Installation via package managers could introduce more cases. So such workaround will be pretty dirty.
Bat files are immature and such checks are not so easy to implement, read and support.
I recommend never to use python via cygwin. Install native package. If 2.5 years there is no progress, I expect nothing good for nearby future. It's a timewaster.
And one more reason to avoid cygwin python - versions are pretty old.
Newest python in cygwin repo is 3.9.16.
Native stable versions are:
- 3.12.6
- 3.11.10
- 3.10.15
- 3.9.20
Even if we compare 3.9 branch, there are about 2 years of latency:
- Cygwin python version is 3.9.16 is from Dec. 6, 2022
- Native Python 3.9.20 is from Sept. 6, 2024
So there are security concerns of using cygwin python.
@joro88 : Agreed, unfortunately. I've basically given up on Cygwin python, and use the native Windows version instead.
Reacted by JoroI'm working with Mercurial. It cannot use Windows style paths because internally it resorts to
os.path.realpath, which is broken:(Pdb) p os.path.realpath('c:/Users') '/cygdrive/e/my/c:/Users'As you see
realpathprepend current directory. It basically breaks everything.By interactive debug session, demonstrating the problem:
>>> from mercurial import hg, ui >>> UI = ui.ui() >>> import pdb >>> pdb.run("hg.repository(UI, path=b'c:/Users/user/my/utils', create=False)") ... (Pdb) w /usr/lib/python3.9/bdb.py(580)run() -> exec(cmd, globals, locals) <string>(1)<module>() /usr/lib/python3.9/site-packages/mercurial/hg.py(240)repository() -> repo = cls.instance( /usr/lib/python3.9/site-packages/mercurial/hg.py(153)instance() -> return cls.instance(ui, path, *args, **kwargs) /usr/lib/python3.9/site-packages/mercurial/localrepo.py(3625)instance() -> repo = repo_maker() /usr/lib/python3.9/site-packages/mercurial/localrepo.py(3623)repo_maker() -> return makelocalrepository(ui, localpath, intents=intents) (Pdb) p hgpath b'/cygdrive/e/my/c:/Users/user/my/utils/.hg'As noted above, if you want to see progress on this, you'll need to report it to the maintainers of the cygwin Python package in the first instance.
I'll also note that at this point, Python 3.9 is long out of bugfix support (and nearly out of security support) and you should upgrade to a newer version of Python.
Reacted by Oleksandr Gavenko- added a parent issue
on May 15, 2026
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields: