On 10/20/2010 01:33 PM, Stewart, Robert wrote:
Bjørn Roald wrote:
On 10/19/2010 06:56 PM, Christian Holmquist wrote:
Is there a POSIX equivalent for My Documents?
I think the users home directory is the closest you get as a general statement unless you start getting into details that are more specific for each POSIX system and/or distribution.
I disagree. The home directory is more like C:\ on Windows.
Wrong. I agree with statements in other postings that the home directory on Unix/Linux is not anything like C:\ on Windows.
As I mentioned in another post, there is no specific equivalent. Each user chooses to put documents in various subdirectories as suits their preference, so there isn't a good default on POSIX systems.
I assume you are talking about default for something that matches "My Documents" on Windows. I see absolutely no reason a boost::filesystem method that return the users My Documents folder on Windows should not return the users home directory on POSIX. What is so wrong with that? What problems should arise? As far as having a default behavior for these methods, assuming you with default mean something to fall back to when the primary method fails, I don't know if defaults are a good idea and I never suggested it. I think the proper strategy is to try a defined sequence of zero or more established techniques to find a valid existing directory covering a defined boost::filesystem concept for the given platform runtime environment. If that all fail it is probably best for the function to give up and and fail rather than guessing on some default directory and possibly trying to create the path.
Some desktop environments provide an equivalent, but as there is no standard even among those, it is still up to client code to determine the best equivalent, if wanted.
I still see no problems with just using $HOME on unix like systems as a match to My Documents. They do not have to be equivalent, they just need to be a place in the filesystem that serve the same concept for the software. An example is the concept of a directory under which the users private documents normally are organized.
method name POSIX path XP path -------------------------------------------------------------- ----------------------------------- temp_path /tmp c:\TEMP user_(home|profile)_path /home/bjorn c:\Documents and Settings\bjorn user_docs_path /home/bjorn c:\Documents and Settings\bjorn\My Documents
I disagree with your mappings. I think leaving undefined what has no standard definition is superior. Also, temp_path should be taken from the environment before using a fallback like /tmp.
I never sugested this table as a mapping. Immediately before my table I had text you have cut away, I quote myself:
A set of names of methods/enums and typical returned paths could be:
So please do not suggest I simply suggested a mapping.
user_appdata_path /home/bjorn
c:\Documents and Settings\bjorn\AppData appdata_path /etc c:\Documents and Settings\All Users\AppData user_desktop_path /home/bjorn/Desktop ?? c:\Documents and Settings\bjorn\Desktop desktop_path /etc/Desktop ?? c:\Documents and Settings\All Users\AppData etc..
This gets one into even more proprietary directions. A Desktop "folder" assumes a GUI which isn't necessarily the case on a POSIX system.
Agree, hence I put my question marks. Also, there is no standard way of defining the path to the desktop if there where a GUI. I do not even know if all GUI's have the concept of a desktop, or if they do if all of them map this to a filesystem directory.
The AppData "folder" on Windows has no equivalent on POSIX systems.
Why not? For the same concept as the Windows users AppData on POSIX systems the home directory works just fine. I have many directories in my Linux home directory containing application data for their respective applications. Many of these applications put their data in hidden files/directories to avoid polluting the home directory too much, but it is the standard solution as far as I can tell.
/etc is not appropriate as the user won't have write permission unless root.
That is why I suggested this to be similar to c:\Documents and Settings\All Users\AppData on Windows which typically require Administrator rights.
If such were to be supported by Filesystem, the best behavior remains leave undefined what has no standard definition.
The tricky part here is to come up with the desired concepts we want support for in boost::filesystem and then determine if there is a good solution on each relevant runtime platform. Looking for defined equivalence is the same as giving up. Then we will gain nothing. regards, Bjørn