GeezerVison is showing github.com — Windows-style path is not recognized under cygwin · Issue #90907 · python/cpython
Windows-style path is not recognized under cygwin #90907Description
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:
assignee = None
closed_at = None
created_at = <Date 2022-02-14.18:42:01.267>
labels = ['type-bug', '3.9', 'OS-windows']
title = 'Windows-style path is not recognized under cygwin'
updated_at = <Date 2022-02-15.07:40:35.403>
user = 'https://github.com/mikekaganski' bugs.python.org fields:
activity = <Date 2022-02-15.07:40:35.403>
actor = 'lazka'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Windows']
creation = <Date 2022-02-14.18:42:01.267>
creator = 'mikekaganski'
dependencies = []
files = []
hgrepos = []
issue_num = 46751
keywords = []
message_count = 8.0
messages = ['413247', '413250', '413256', '413259', '413261', '413264', '413272', '413277']
nosy_count = 8.0
nosy_names = ['paul.moore', 'eric.smith', 'tim.golden', 'zach.ware', 'eryksun', 'steve.dower', 'lazka', 'mikekaganski']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue46751'
versions = ['Python 3.9'] Activitymikekaganski commented on Feb 14, 2022 MannequinAuthor More actions Using cyqwin 3.3.4-2, and python3:
Python 3.9.10 (main, Jan 20 2022, 21:37:52)
[GCC 11.2.0] on cygwin
Trying 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. ericvsmith commented on Feb 14, 2022 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 MannequinAuthor More actions Thanks 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.
It does: https://cygwin.com/packages/summary/python3.html ericvsmith commented on Feb 14, 2022
:) 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. zooba commented on Feb 14, 2022 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 MannequinAuthor More actions
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.
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?). eryksun commented on Feb 14, 2022 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 directory
Windows 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 Afaik 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. Sporking commented on Apr 24, 2022 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')
^Z
C:\example>c:\cygwin64\bin\python3.8 test.py
hello
C:\example>c:\cygwin64\bin\python3.9 test.py
hello
C:\example>c:\cygwin64\bin\python3.8 C:\example\test.py
hello
C:\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 directory
Cygwin 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 Joro pfmoore commented on Apr 24, 2022
Any 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. joro88 commented on Sep 26, 2024 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. joro88 commented on Sep 26, 2024 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. ericvsmith commented on Sep 26, 2024 @joro88 : Agreed, unfortunately. I've basically given up on Cygwin python, and use the native Windows version instead. gavenkoa commented on Sep 23, 2025 I'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 realpath prepend 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'
pfmoore commented on Sep 23, 2025 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
MetadataMetadataStatusShow more project fields
DevelopmentNo branches or pull requestsIssue actions
|