strange interaction between open and cwd

[Lie Ryan]

On 05/04/10 07:57, Baz Walter wrote:
> On 03/05/10 19:12, Grant Edwards wrote:
>> On 2010-05-03, Baz Walter<bazwal at ftml.net>  wrote:
>>
>>>> You requested something that wasn't possible.  It failed.  What do
>>>> you think should have happened?
>>>
>>> path = '../abc.txt'
>>>
>>> os.path.realpath(path) ->  "OSError: [Errno 2] No such file or
>>> directory"
>>>
>>> therefore:
>>>
>>> open(path) ->  "IOError: [Errno 2] No such file or directory"
>>>
>>> i think that if the first of these seemingly "impossible" requests
>>> fails, it is reasonable to expect that the second one also fails. but
>>> the second one (sometimes) doesn't.
>>
>> Because the second one isn't impossible in the case you posted.
>>
>>> i think they should always either both succeed, or both fail.
>>
>> That's not how Unix filesystems work.
>>
>> Are you saying that Python should add code to it's open() builtin
>> which calls realpath() and then refuses to open files for which
>> realpath() fails?
> 
> my original question was really about *how* python does the "seemingly
> impossible". i had hoped there might be a way to augment realpath so
> that it would always work for any path which is openable. but apparently
> that is not possible for unix filesystems.

It's the OS that does the "seemingly impossible" things. Python only
makes the relevant system call with the string you've given, and leaves
the rest of the magic of resolving the real file to open, opening the
filename, moving the harddrive head, etc to OS kernel. If OS kernel
dictates that you can open a file that have no actual path; then Python
will do so.



>> Even though the user provided a legal and openable path?
> 
> that sounds like an operational definition to me: what's the difference
> between "legal" and "openable"?