directory
directory copied to clipboard
haskell
The XdgDirectory datatype doesn't provide a way to query $XDG_RUNTIME_DIR
I'm not entirely sure how we'd properly integrate this in the existing API, as (unlike the other Xdg directories) XDG_RUNTIME_DIR doesn't have a default value. On the other hand, it's quite a hassle to reimplement getXdgDirectory myself just for RUNTIME_DIR
Would calling lookupEnv "XDG_RUNTIME_DIR" suffice?
Is there any benefit from having this in directory?
I guess this could be interesting to have a portable function returning $XDG_RUNTIME_DIR on unixes and something else on windows.
I'm not happy with the wontfix resolution of this issue. The XDG spec has quite a bit of stuff around XDG_RUNTIME_DIR. It would be great if directory had code to do all of this checks.
$XDG_RUNTIME_DIR defines the base directory relative to which user-specific non-essential runtime files and other file objects (such as sockets, named pipes, ...) should be stored. The directory MUST be owned by the user, and he MUST be the only one having read and write access to it. Its Unix access mode MUST be 0700.
If $XDG_RUNTIME_DIR is not set applications should fall back to a replacement directory with similar capabilities and print a warning message. Applications should use this directory for communication and synchronization purposes and should not place larger files in it, since it might reside in runtime memory and cannot necessarily be swapped out to disk.
code to do all of this checks.
The program is not required to verify those.
My read of the spec is that those are requirements that the program can assume about the system configuration. In other words, it is the user / admin / distro who has the onus of ensuring that the directory has the correct permissions etc. The program isn't obliged to verify any of them, and for the average program there isn't necessarily anything actionable if these requirements aren't met, other than maybe printing a warning.
There is no canonical replacement directory for XDG_RUNTIME_DIR that I'm aware of either, so the fallback will probably vary depending on the program at hand.
More generally, I am wondering whether directory is the right place to handle all the features of XDG (vs delegating to a non-boot package). Bear in mind that main reason XDG was introduced to directory was to offer a more compliant replacement for getAppUserDataDirectory. Would supporting the full XDG spec be stretching the scope too much? How would one extend the semantics of XDG to Windows platforms?
I guess this could be interesting to have a portable function returning $XDG_RUNTIME_DIR on unixes and something else on windows.
The closest I can think of is Win32.getTemporaryDirectory. If that works for your use case maybe that could be used as a substitute, although it hardly meets any of the requirements in the XDG specification.
Closing for reasons discussed in https://github.com/haskell/directory/issues/93#issuecomment-855482568.