Re: [boost] [filesystem] home_directory_path

Subject: Re: [boost] [filesystem] home_directory_path
From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2010-10-18 17:00:01

Marsh Ray wrote:
> On 10/18/2010 09:58 AM, Jeff Flinn wrote:
>> In looking at implementing a portable home_directory_path function a few
>> questions arise.
>>
>> Based on http://en.wikipedia.org/wiki/Home_directory, POSIX and other
>> UNIX flavors 'appear' to be a straight forward use of the "HOME"
>> environment variable. Does anyone have any experience where the "HOME"
>> variable is not the proper source of the user's home directory?
>>
>> Windows NT and above have the "USERPROFILE" environment variable. Using
>> this would be the easiest to use. But I've seen discussion that this may
>> not always be properly defined, in particular if the user has reset
>> their home directory to a non-system drive.
> 
> I wouldn't count on it for anything critical.

Can you expand on that? What problems have you encountered.

>> I haven't tracked down it's
>> availability on WinCE. Does anyone have experience with this platform?
>>
>> There is the windows GetUserProfileDirectory api function also available
>> since NT4.
> 
> That's a the call to use if indeed you want "the root directory of the 
> specified user's profile".
> http://msdn.microsoft.com/en-us/library/bb762280.aspx
> 
> _But it's important to be prepared for case where the code is executing 
> as a user who does not actually have a profile on the machine!_

Of course. home_directory_path will have the same error capabilities as 
the recently added temp_directory_path function

> You might be better off calling SHGetFolderPath with a CSIDL value like 
> CSIDL_APPDATA.
> http://msdn.microsoft.com/en-us/library/bb762181.aspx
> http://msdn.microsoft.com/en-us/library/bb762494.aspx
> 
>> This is in the Userenv.lib/dll, obviously adding a link
>> dependancy. How are these sorts of system link dependencies handled?
>> Through bjam? Or is it acceptable/better to use #pragma
>> comment(lib,"Userenv.lib")?

Ah, SHGetFolderPath uses shell32.dll, but doesn't require and import 
library. I'll take a look at using this with CSIDL_PROFILE which 
corresponds to the GetUserProfileDirectory function.

>> In looking at some client code using home_directory_path, I see that
>> they generally are looking for the user's Desktop directory(Mac &
>> Windows). Obviously this only makes sense on GUI platforms. The issue
>> with merely getting this path via home_directory_path() / "Desktop" is
>> IIRC, that at least on windows "Desktop" is localized and may not exist
>> with that name on non-english localized systems. Windows has the
>> SHGetFolderPath api. I need to look into Mac's native support. Any
>> thoughts on the general usefulness of a portable desktop_directory_path?
> 
> It seems to me like if you're going to work with a "Desktop", you're 
> going to need a variety of platform specific logic to deal with things 
> like file types, icons, app associations, etc. You'd need a real 
> platform UI layer. So I don't think a single function to just find the 
> path is likely to be useful to many.

Well, in our case it's a well known location where users have installed 
other (legacy)apps that we need to communicate with. Nothing to do with 
icons, file types,...

Thanks, Jeff