-
-
Notifications
You must be signed in to change notification settings - Fork 31.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pathlib.Path.resolve() returns path with double slash when resolving a relative path in root directory #77841
Comments
I have recently found a weird behaviour while trying to resolve a relative path located on the root directory on a macOs. I tried to resolve a Path('spam') and the interpreter answered PosixPath('//spam') —double slash for root— instead of (my) expected PosixPath('/spam'). I think that this is a bug. I ran the interpreter from root directory (cd /; python). Once running the interpreter, this is what I did: >>> import pathlib
>>> pathlib.Path.cwd()
PosixPath('/')
# since the interpreter has been launched from root
>>> p = pathlib.Path('spam')
>>> p
PosixPath('spam')
# just for checking
>>> p.resolve()
PosixPath('//spam')
# beware of double slash instead of single slash I also checked the behaviour of Path.resolve() in a non-root directory (in my case launching the interpreter from /Applications). >>> import pathlib
>>> pathlib.Path.cwd()
PosixPath('/Applications')
>>> p = pathlib.Path('eggs')
>>> p
PosixPath('eggs')
>>> p.resolve()
PosixPath('/Applications/eggs')
# just one slash as root in this case (as should be) So it seems that double slashes just appear while resolving relative paths in the root directory. More examples are:
>>> pathlib.Path('spam/egg').resolve()
PosixPath('//spam/egg')
>>> pathlib.Path('./spam').resolve()
PosixPath('//spam')
>>> pathlib.Path('./spam/egg').resolve()
PosixPath('//spam/egg') but >>> pathlib.Path('').resolve()
PosixPath('/')
>>> pathlib.Path('.').resolve()
PosixPath('/') Intriguingly, >>> pathlib.Path('spam').resolve().resolve()
PosixPath('/spam')
# 'spam'.resolve = '//spam'
# '//spam'.resolve = '/spam'!!!
>>> pathlib.Path('//spam').resolve()
PosixPath('/spam') I have found the same behaviour in several Python versions: Python 3.6.5 (default, May 15 2018, 08:20:57) Python 3.4.8 (default, Mar 29 2018, 16:18:25) Python 3.5.5 (default, Mar 29 2018, 16:22:58) Python 3.7.0b4 (default, May 4 2018, 22:01:49) All running on: macOs High Sierra 10.13.4 (17E202) There is also confirmation of same issue on Ubuntu 16.04 (Python 3.5.2) and Opensuse tumbleweed (Python 3.6.5) I have searched for some information on this issue but I did not found anything useful. Python docs (https://docs.python.org/3/library/pathlib.html) talks about "UNC shares" but this is not the case (in using a macOs HFS+ filesystem). PEP-428 (https://www.python.org/dev/peps/pep-0428/) says:
>>> PureWindowsPath('//some/path')
PureWindowsPath('//some/path/')
>>> PurePosixPath('///some/path')
PurePosixPath('/some/path')
>>> PurePosixPath('//some/path')
PurePosixPath('//some/path') I do not think that this is related to the aforementioned issue. However, I also checked the POSIX specification link (http://pubs.opengroup.org/onlinepubs/009...#tag_04_11) and found:
I do not really think that this can cause a double slashes while resolving a relative path on macOs. So, I think that this issue could be a real bug in pathlib.Path.resolve() method. Specifically on POSIX flavour. A user of Python Forum (killerrex) and I have traced the bugs to Lib/pathlib.py:319 in the Python 3.6 repository https://github.com/python/cpython/blob/3...pathlib.py. Specifically, in line 319:
For pathlib.Path('spam').resolve() in the root directory, newpath is '//spam' since:
killerrex has suggested two solutions:
if path.endswith(sep):
newpath = path + name
else:
newpath = path + sep + name Thank you. |
Script to reproduce: import os
import pathlib
# Change to the Root directory
os.chdir('/')
# Create a relative path object.
p = pathlib.Path('spam')
print(p.resolve()) Expected output: Incorrect output |
For reviewers, I submitted a patch PR 7666. |
Please review my pull request. |
This issue cropped up recently in the black project: psf/black#1631 It appears to me that PR 7666 was closed without being merged. I created #21971 before I had found this issue. |
Sorry it took so long, this will get released in Python 3.8.6 and newer. |
Thanks Łukasz for finanlizing this work :) |
"//path"
#21971Note: 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:
The text was updated successfully, but these errors were encountered: