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".
> _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
>> 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
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,...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk