Talk:XDG Base Directory
- It seems that still needs an
~/.emacs, so I'm unsure it's a great improvement over a single
~/.emacs.d. That said, you could try to start emacs with the
--directoryargument. -- Alad (talk) 09:15, 1 September 2015 (UTC)
Abuse of XDG_CONFIG_HOME
I've just revised the VCS management of my config files and had to put configs of practically all graphical programs to
.gitignore, because they all abuse the
$XDG_CONFIG_HOME path for the purpose of persistent cache, which is
$XDG_CACHE_HOME. A typical config file of a Qt programs looks like this, notice especially the
windowState keys -- IMHO this is exactly the stuff that belongs to
$XDG_DATA_HOME. The Qt programs are notorious, I suspect the toolkit itself is responsible. But there is more: inkscape puts there
extension-errors.log, syncthing even the entire database. What shall we do about this? There are not many graphical programs in the tables on this page, but inkscape is listed under "Supported", which is not entirely true... -- Lahwaacz (talk) 22:12, 21 August 2015 (UTC)
- The article uses "workarounds [that] will be limited to anything not involving patching the source, executing code stored in environment variables or compile-time options." as an arbiter for the "Partial" category, and anything more complicated than that for "Hardcoded". I.e., categorization is based on what's needed to moving dotfiles from $HOME to some, hopefully correct, XDG directory or directories.
- One way to supplement this would be the Notes column in the Supported category (which is now mostly empty anyway), to expand on programs which don't follow the intent of the XDG directories or which just lazily stack things together. -- Alad (talk) 09:08, 1 September 2015 (UTC)
- This is why adding
GIT_DIR/info/excludeis so great. I have no idea why people who are familiar with git don't do this by default. This allows you to only track files you explicitly want to track with impunity. But yes, there's plenty of programs which don't follow the spec to the letter and that's mostly fine; it's fine because at least the root of their directory is now under user control. Using git properly makes this a non-issue and I'd rather projects at least support some of XDG than be forever debating what "cache" vs "data" means... Earnest (talk) 15:31, 12 September 2015 (UTC)
- This is why adding
Should command-line history be data or cache?
- Cache is data than can be deleted at any time without losing anything important, as it can be regenerated by the application (e.g. by re-downloading something or otherwise). Data in
XDG_DATA_HOMEon the other hand has an impact on what the user can do, and the user would mind about losing it. Of course it may depend on the application in question where you draw the line of what's "important", but when deleting command line history, (1) the user loses possibilities (reusing a command) and information/knowlege ("what was that command again?"), and (2) the data cannot be regenerated by the application, so I would clearly put it in
XDG_DATA_HOME. —Ayekat (talk) 22:30, 16 May 2017 (UTC)
nvidia uses XDG_CACHE_HOME, how to test CUDA?
Using nvidia 390.25 and just noticed that it now stores its cache in $XDG_CACHE_HOME/.nv rather than ~/.nv and edited the page accordingly. I don't know if CUDA was also changed and don't know how to check. If someone else knows, please tell me or try it yourself and update the page if needed. I already checked nvidia-settings, it is not yet changed.
Suggestions for GnuPG
Current suggestion for GnuPG is
$ export GNUPGHOME="$XDG_CONFIG_HOME"/gnupg
$ gpg2 --homedir "$XDG_CONFIG_HOME"/gnupg
However, GnuPG places more than configuration files in
$GNUPGHOME. For example, in my machine I have following files
Both are binary files. According to the name they are the public key ring and some database. I don't think they belong to
$XDG_CONFIG_HOME. Maybe we should specify their path manually, to re-direct them to somewhere in
$XDG_DATA_HOME? --Franklin Yu (talk) 21:13, 14 November 2018 (UTC)
Add description of support categories
Hi, do you think we could add a description of what each categories (Supported, Partial, Hardcoded) means ? For exemple, I don't know where to put things like the following:
- app that use a hardcoded .config, not using the XDG variables - app that use the XDG_CONFIG_HOME for EVERYTHING - app where we can use alternative methods (environnment variable, option, ...) for specific files - app where we can use alternative methods, freeing $HOME, but not using the correct path for each file (config vs cache vs data) (for exemple, gpg)
Maybe we could make those categories evolve, either by refactoring the categories (creating new ones), and/or putting the categories directly in the table (still allowing seeing programs per category) ?