On Sun, May 18, 2014 at 6:02 PM, Peter Dimov
Yakov Galka wrote: ... On second thought though, I'm not sure that this is what I'd want from usability point of view. When the user gives me "c:a", he probably wants "c:a" and not "c:/x/a", even if the documentation states that paths are treated relative to "c:/x". ... "c:/x" / "/a" == "/a" "d:/x" / "/a" == "/a"
for the same usability reasons.
I don't follow. The real-world use-case is that I have some config/project/database/install-dir named x = "c:/myproduct", that references another file y, conceptually relative to itself. I think we all agree that if y = "a.txt" then x / y = "c:/myproduct/a.txt" is the desired result. Now, if y = "/windows/a.txt" I would definitely expect the result to be "c:/windows/a.txt", and not "/windows/a.txt" which may end up resolved to "d:/windows/a.txt" if "d:" is the current drive. How "/abc" is any different from "a.txt" in this respect?
In this case, both z1 and z2 are absolute (even though they are not absolute by the N3940 definition.)
OK, went through N3940 (as I said, wasn't following it for some time). The problem of the definition
A path that unambiguously identifies the location of a file without reference to an additional starting location.
is that it is unclear what 'location' is (a path or an inode?) and that it lacks a quantifier. After 10 minutes trying to understand what it says, I think that this is what it tried to say: x is absolute iff for all possible filesystem instances F (under the given OS), if exists a filesystem node f in F and a program state S such that f = open(F, S, x), then for all program states S, f = open(F, S, x). (i.e. ∀F ∃f ∈ F ((∃S f = open(F,S,x)) → (∀S f = open(F,S,x)))) Here open(F, S, x) is the node of F that the path x resolves to at the program state S, and program state S includes current directory, environment vars, etc... -- Yakov