strange interaction between open and cwd
in [Python]
|
Prev: ANN: expy 0.6.7 released!
Next: long int computations
From: Grant Edwards on 3 May 2010 10:56 On 2010-05-03, Baz Walter <bazwal(a)ftml.net> wrote: > On 03/05/10 14:46, Peter Otten wrote: >> Baz Walter wrote: >> >>> attempting to remove the cwd would produce an error). but how can python >>> determine the parent directory of a directory that no longer exists? >> >> My tentative explanation would be that the directory, namely the inode, >> still exists -- only the entry for it in its parent directory is gone. >> >> So "one level up from here" is still a valid operation, but there is no >> longer a path in the file system associated with "here". > > so "here" must always be available somehow, Yes. > even if getcwd() fails If the current working directory doesn't _have_ a path within a filesystem, what do you expect it to do? > (something like the environment variable $PWD). shame that > os.getenv('PWD') isn't reliable, as it would solve my issue :( I don't understand what you mean by that. -- Grant Edwards grant.b.edwards Yow! I'm wet! I'm wild! at gmail.com
From: Baz Walter on 3 May 2010 12:27 On 03/05/10 15:56, Grant Edwards wrote: > On 2010-05-03, Baz Walter<bazwal(a)ftml.net> wrote: >> On 03/05/10 14:46, Peter Otten wrote: >>> Baz Walter wrote: >>> >>>> attempting to remove the cwd would produce an error). but how can python >>>> determine the parent directory of a directory that no longer exists? >>> >>> My tentative explanation would be that the directory, namely the inode, >>> still exists -- only the entry for it in its parent directory is gone. >>> >>> So "one level up from here" is still a valid operation, but there is no >>> longer a path in the file system associated with "here". >> >> so "here" must always be available somehow, > > Yes. > >> even if getcwd() fails > > If the current working directory doesn't _have_ a path within a > filesystem, what do you expect it to do? well, i expect it to fail, like i said :) >> (something like the environment variable $PWD). shame that >> os.getenv('PWD') isn't reliable, as it would solve my issue :( > > I don't understand what you mean by that. i'm trying to understand how the path of the cwd can be known if there is no entry for it in the filesytem - but this is starting to get a little OT, so i won't pursue it here any longer.
From: Grant Edwards on 3 May 2010 12:34 On 2010-05-03, Baz Walter <bazwal(a)ftml.net> wrote: >>> (something like the environment variable $PWD). shame that >>> os.getenv('PWD') isn't reliable, as it would solve my issue :( >> >> I don't understand what you mean by that. > > i'm trying to understand how the path of the cwd can be known if there > is no entry for it in the filesytem It can't. That's why cwd() failed. > - but this is starting to get a little OT, so i won't pursue it here > any longer. OK. -- Grant Edwards grant.b.edwards Yow! Should I do my BOBBIE at VINTON medley? gmail.com
From: Baz Walter on 3 May 2010 12:59 On 03/05/10 15:55, Grant Edwards wrote: > On 2010-05-03, Baz Walter<bazwal(a)ftml.net> wrote: >> On 03/05/10 14:56, Chris Rebert wrote: >>>> but how does '..' get resolved in the relative path '../abc.txt'? i'm >>>> assuming python must initially use getcwd() internally to do this, and then >>>> if that fails it falls back on something else. but what is that something >>>> else? is it something that is reproducible in pure python? >>> >>> I would think that the OS system call, not Python itself, does the >>> relative->absolute conversion. >> >> so there is a discrepancy between some of the std library path functions >> (like realpath, getcwd, abspath) and the built-in open function. > > Not really. There is a discrepancy between your perception and > expectations and the way the Unix filesystem works. it's a fact that realpath/abspath/normpath etc can fail for paths that don't when used with os.stat or the builtin open function. i think it's reasonable to expect that a path that can be used to successfully open a file wont then produce "No such file or directory" errors when used with an os.path function like realpath. it shouldn't be necessary to have detailed knowledge of the underlying filesytem to be able to use os.path - it's supposed to be generic. >> there are files which can be opened for which it is impossible to >> resolve their full paths (on some platforms). > > Sort of. The file in question _has_ a full path, you just can't tell > what it is based on the path you used to open it. yes, that's exactly what i was trying to demonstrate in my OP. i can use python to open a file; but under certain circumstances, there seems to be no guarantee that i can then use python to locate that file in the filesystem.
From: Grant Edwards on 3 May 2010 13:12
On 2010-05-03, Baz Walter <bazwal(a)ftml.net> wrote: > it's a fact that realpath/abspath/normpath etc can fail for paths > that don't when used with os.stat or the builtin open function. True. > i think it's reasonable to expect that a path that can be used to > successfully open a file wont then produce "No such file or > directory" errors when used with an os.path function like realpath. Yes, I understand that's what you think. That's not, however, a reasonable expectation in some cases. > it shouldn't be necessary to have detailed knowledge of the > underlying filesytem to be able to use os.path - it's supposed to be > generic. If you ask for the path of a file that has no path (or for which the path can't be determined from the provided information), what do you propose should happen? >>> there are files which can be opened for which it is impossible to >>> resolve their full paths (on some platforms). >> >> Sort of. The file in question _has_ a full path, you just can't tell >> what it is based on the path you used to open it. > > yes, that's exactly what i was trying to demonstrate in my OP. i can > use python to open a file; but under certain circumstances, there > seems to be no guarantee that i can then use python to locate that > file in the filesystem. Exactly. In your example, it's simply not possible to determine the file's absolute path within the filesystem given the relative path you provided. You requested something that wasn't possible. It failed. What do you think should have happened? -- Grant Edwards grant.b.edwards Yow! There's enough money at here to buy 5000 cans of gmail.com Noodle-Roni! |