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

Subject: Re: [boost] [filesystem] Request for comments on proposedrelative()function
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2014-05-20 19:18:53

On 17/05/2014 02:32, quoth Peter Dimov:
> Madness. How about we just say c:a/b is c:/a/b and be done with it.

You might be able to get away with that in a GUI app -- but then a GUI 
app shouldn't be getting those kinds of paths in the first place.

You can't get away with it in a console app, at least in the context of 
parsing command line arguments.  (If you have something separate 
translating arguments into absolute paths [does the alternate setargv do 
that?] then you might -- although that doesn't help you if you're 
parsing response files or scripts as well.)

When the user provides a console app with drive-relative paths, they 
expect them to be relative to the current directory of those drives, as 
most recently set by that user.  Treating it as rooted is just going to 
confuse and annoy them.

>> But they are read by the Windows API, including SetCurrentDirectory,
>> GetFullPathName, etc... So there is still a per-drive notion of
>> "current directory" in addition to "THE current directory".
>
> They are read but not written. If the environment says that the current
> directory of D: is D:\foo and you SetCurrentDirectory( "D:\\bar" ), the
> current directory of D: remains D:\foo in the environment. So D:test was
> D:\foo\test, becomes D:\bar\test while the current directory is D:\bar,
> and then reverts to D:\foo\test when the current directory becomes C:\foo.
>
> Madness, as I said. No sane person uses such paths. :-)

There *is* a perverse kind of logic to it.  The current directory of 
alternate drives are set by the user (or a user agent such as batch 
files), and the user expects them to stay where they set them until the 
next time they change them themselves.

But yes, such paths should only be used in the context of user input 
(command line or response files).  They should be translated to "real" 
paths as soon as possible and stored that way.  But there has to be some 
mechanism for doing that translation -- and it seems like something 
Filesystem ought to provide.

> To support c:a, we need either to distinguish between "c:" and "c:/"
> as path elements, or posit that c:/ consists of { "c:", "/" }. The
> openat-based definition then becomes associative (using either), if
> I'm not mistaken. Although I very well could be, because did I
> mention the word madness in relation to all this? I forget.

Granted I haven't verified this, but the docs of Filesystem suggested 
that it already did that.