[issue42957] os.readlink produces wrong result on windows
simon mackenzie added the comment:
I note os.path.realpath("v1") does produce the right path in windows. Maybe
that is what you meant. Will that work cross-platform?
On Tue, 19 Jan 2021 at 18:48, simon mackenzie wrote:
> For most people the expectation would be that it returns a path in the
> same format as any other path. Furthermore it seems odd to change the
> default behaviour after years when it worked as expected. I never heard of
> this substitute path before and it does not work in some circumstances e.g.
> docker does not recognise it.
>
> Note also that os.path.realpath(os.path.readlink("v1")) still returns
> ?\\d:\\v1. There needs to be some way of getting to the path that
> everyone actually uses.
>
> On Mon, 18 Jan 2021 at 21:25, Eryk Sun wrote:
>
>>
>> Eryk Sun added the comment:
>>
>> Symlinks and mountpoints (aka junctions) contain two forms of the target
>> path. There's a path that's intended for display in the shell, and there's
>> the actual substitute path to which the link resolves. os.readlink() was
>> changed to return the substitute path because the display form is not
>> mandated by filesystem protocols (it's sometimes missing, especially for
>> junctions) and not reliable (e.g. the display path may be a long path or
>> contain reserved names such that it's not valid without the \\?\ prefix).
>> It was decided to keep the C implementation of os.readlink() simple.
>> Whether to retain the \\?\ prefix was shifted to high-level functions that
>> consume the result of os.readlink(), such as os.path.realpath().
>>
>> There was a previous issue related to this, in that the shutil module
>> copies symlinks via os.readlink() and os.symlink(), which thus copies only
>> the substitute path now. The issue was closed as not a bug, but had it been
>> resolved with new functionality, I would have preferred to do so with a
>> low-level function to copy a reparse point, not by reverting the behavior
>> of os.readlink(). I also see no reason against adding an option to
>> readlink() to return the display path instead of the substitute path, or to
>> just remove the prefix. But I'd vote against making it the default behavior.
>>
>> --
>> components: +Library (Lib)
>> nosy: +eryksun
>> versions: +Python 3.10
>>
>> ___
>> Python tracker
>> <https://bugs.python.org/issue42957>
>> ___
>>
>
--
___
Python tracker
<https://bugs.python.org/issue42957>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42957] os.readlink produces wrong result on windows
simon mackenzie added the comment:
For most people the expectation would be that it returns a path in the same
format as any other path. Furthermore it seems odd to change the default
behaviour after years when it worked as expected. I never heard of this
substitute path before and it does not work in some circumstances e.g.
docker does not recognise it.
Note also that os.path.realpath(os.path.readlink("v1")) still returns
?\\d:\\v1. There needs to be some way of getting to the path that
everyone actually uses.
On Mon, 18 Jan 2021 at 21:25, Eryk Sun wrote:
>
> Eryk Sun added the comment:
>
> Symlinks and mountpoints (aka junctions) contain two forms of the target
> path. There's a path that's intended for display in the shell, and there's
> the actual substitute path to which the link resolves. os.readlink() was
> changed to return the substitute path because the display form is not
> mandated by filesystem protocols (it's sometimes missing, especially for
> junctions) and not reliable (e.g. the display path may be a long path or
> contain reserved names such that it's not valid without the \\?\ prefix).
> It was decided to keep the C implementation of os.readlink() simple.
> Whether to retain the \\?\ prefix was shifted to high-level functions that
> consume the result of os.readlink(), such as os.path.realpath().
>
> There was a previous issue related to this, in that the shutil module
> copies symlinks via os.readlink() and os.symlink(), which thus copies only
> the substitute path now. The issue was closed as not a bug, but had it been
> resolved with new functionality, I would have preferred to do so with a
> low-level function to copy a reparse point, not by reverting the behavior
> of os.readlink(). I also see no reason against adding an option to
> readlink() to return the display path instead of the substitute path, or to
> just remove the prefix. But I'd vote against making it the default behavior.
>
> --
> components: +Library (Lib)
> nosy: +eryksun
> versions: +Python 3.10
>
> ___
> Python tracker
> <https://bugs.python.org/issue42957>
> ___
>
--
___
Python tracker
<https://bugs.python.org/issue42957>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42957] os.readlink produces wrong result on windows
New submission from simon mackenzie :
os.readlink gives wrong result on python 3.8 onwards for windows
os.readlink("c:/users/simon/v1")
'?\\d:\\v1'
Should read d:\\v1
--
components: Windows
messages: 385218
nosy: paul.moore, simon mackenzie, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: os.readlink produces wrong result on windows
type: behavior
versions: Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue42957>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37867] docs says subprocess.run accepts a string but this does not work on linux
simon mackenzie added the comment: Would be clearer if the arguments were listed before the return object. On Thu, 15 Aug 2019 at 15:05, SilentGhost wrote: > > SilentGhost added the comment: > > But docs don't say that at all. You're looking at description of an > attribute of returned object. And of course it can be a string, under > certain conditions. The attributes of CompletedProcess and function > arguments are described in the standard way, and I haven't heard of anyone > mixing the two before. > > -- > resolution: -> not a bug > stage: -> resolved > status: open -> closed > > ___ > Python tracker > <https://bugs.python.org/issue37867> > ___ > -- ___ Python tracker <https://bugs.python.org/issue37867> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37867] docs says subprocess.run accepts a string but this does not work on linux
simon mackenzie added the comment: Technically true but I am not the first person to have incorrectly interpreted this that it can be a string which suggests it is not clear to the reader. Maybe should be explicitly stated in the description of run as it is not obvious or intuitive. On Thu, 15 Aug 2019 at 13:47, SilentGhost wrote: > > SilentGhost added the comment: > > The only place this phrase appears is in CompletedProcess.args description > and it is correct there. Whether args arguments of subprocess.run (or > generally Popen) can be a list or a string is discussed in Frequently Used > Arguments section, and it is perfectly clear from reading the text under > which condition you can pass a string as args argument. I don't think > anything needs fixing, both implementation and docs are correct. > > -- > assignee: -> docs@python > components: +Documentation > nosy: +SilentGhost, docs@python > type: -> behavior > > ___ > Python tracker > <https://bugs.python.org/issue37867> > ___ > -- title: docs says subprocess.run accepts a string but this does not work on linux -> docs says subprocess.run accepts a string but this does not work on linux ___ Python tracker <https://bugs.python.org/issue37867> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37867] docs says subprocess.run accepts a string but this does not work on linux
New submission from simon mackenzie : The docs for subprocess.run say "The arguments used to launch the process. This may be a list or a string." This works in windows but in linux it has to be a list. Either needs fixing or the docs need to be changed. -- messages: 349800 nosy: simon mackenzie priority: normal severity: normal status: open title: docs says subprocess.run accepts a string but this does not work on linux ___ Python tracker <https://bugs.python.org/issue37867> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
