Consider doing something smarter with XDG multi-paths

[andybarron]

This user on Reddit has an example of when using the first thing returned by XDG isn't a good idea. Perhaps we could check each path it returns and choose one based on some heuristic? Investigate...

[Arvamer]

If I understand XDG Base Directory specification correctly, $XDG_DATA_DIRS is used to find application specific data like images or sound effects. If you don't want to add more functions, {get_,}app_{dir,root}(SharedData) could try to return directory where application specific subdir is already created (checking also $XDG_DATA_HOME). If more directories match, results could be filtered using app's binary path (on Linux you can use fs::read_link("/proc/self/exe") although it's not portable to other Unixes). For example, if application binary is in /usr/bin function should return /usr/share.

This doesn't solve issue with data_root(), but now you only need one additional function :).

[andybarron]

Thanks for the info (and sorry for the late response)! I like the idea of checking to see if a path already exists in any XDG path; that'll work well.

Not sure what we'll do about choosing where to create a new one, though; I'd like it to be non-Linux-specific. I'll look into this more.

[Arvamer]

Actually there is function in std::env that returns path to executable (current_exe), there is no need to use fs::read_link("/proc/self/exe").