Re: [boost] [filesystem] Request for comments on proposed relative() function

On Wed, May 14, 2014 at 3:12 AM, Rob Stewart wrote:

On May 13, 2014 10:00:25 PM EDT, Gavin Lambert wrote:...

...

I'm assuming that the intended use case of this is to "minimise" a path given a known working directory, and unrelated absolute paths are already in their minimal form in that context.

That's a reasonable use case, but this function is only about returning the portion of p that is relative to base.

...

Or another possibly useful output (as Daniel hinted at, though I don't think he got the case right) would be to return a relative path using dotdot syntax, so:

BOOST_TEST(fs::relative("/abc", "/abc/def") == path("..")); BOOST_TEST(fs::relative("/ghi", "/abc/def") == path("../../ghi"));

This could be more useful in some cases (it bloats the path but makes it more immune to being moved elsewhere). Maybe we even need both.

Interesting

The function has now been renamed from relative() to lexically_relative() to make clearer that it deal with paths at a purely lexical level. I probably should have mentioned that work is underway on several additional functions to "do-the-right-thing" when the paths exist or partially exist in the external file system. On possibility is to add a semi_canonical() function which behaves like canonical() for an existing portion of a path, and then normalizes any trailing non-existent portion. This would allow an additional function that does the right thing for existing or partially existing paths. It might be implemented like this: path relative(const path& p, const path& base) { return lexically_relative(semi_canonical(p), semi_canonical(base)); } It isn't clear yet if these semantics are really the most useful.

...

Although that brings up another question (which I'm not really familiar enough with the "path" class internals to answer by looking at the example implementation): is "base" intended to be assumed as a directory name (which is how most filesystem "make relative" functions typically work) or as a file name (which is how URL "make relative" works)?

path makes no assumptions about what it references, or whether the pathname even exists in the filesystem.

+1 Thanks to both Gavin and Rob for their comments, --Beman