Talk:XDG Base Directory

From ArchWiki
Jump to navigation Jump to search


Has anyone looked at XDG Directories for emacs? Ben Creasy (talk) 02:40, 15 July 2015 (UTC)

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 --load or --directory argument. -- Alad (talk) 09:15, 1 September 2015 (UTC)

Emacs should be XDG-aware in the first 27.* release (see this commit). Not sure if this warrants updating the table yet. Odnir (talk) 22:00, 28 August 2019 (UTC)


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 recentFileList, geometry and windowState keys -- IMHO this is exactly the stuff that belongs to $XDG_CACHE_HOME or $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 * to GIT_DIR/info/exclude is 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)

Should command-line history be data or cache?

Should they be placed in XDG_DATA_HOME, or XDG_CACHE_HOME? --Franklin Yu (talk) 20:07, 16 May 2017 (UTC)

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_HOME on 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)
Should it not be XDG_STATE_HOME ($HOME/.local/state) now? Baerbeisser (talk) 07:29, 6 August 2021 (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.

Cyant (talk) 11:55, 25 February 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 example, 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 (environment 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 example, GnuPG)

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)?

Apollo22 (talk) 13:58, 14 March 2019 (UTC)

#Partial meaning is implied in the XDG Base Directory#Support section:
For those not currently supporting the Base Directory Specification, workarounds will be demonstrated to emulate it instead.
The workarounds will be limited to anything not involving patching the source, executing code stored in environment variables or compile-time options. The rationale for this is that configurations should be portable across systems and having compile-time options prevent that.
If you can't change directories without modifying the code, it goes to #Hardcoded. Maybe it should not be #Partial as it actually does not support the spec but #Workaround available.
I also propose using fields to describe how different programs work with the spec, instead of just having 3 categories:
Application Legacy paths Dir split XDG variables XDG fallback Legacy fallback Legacy files moved Notes
Cool-utils .cool-utils/ No Yes Yes Yes No
git-xmonad .git-xmonad No After legacy No Yes No
Dumper .dumper/ Yes Yes Yes No Old copies left
Hostile-app .hostileapp/ No No, WONTFIX No Yes No $ export GARBAGEBIN="$XDG_DATA_HOME"/hostile-app
-- Svito (talk) 01:55, 23 April 2020 (UTC)
It's hard to say if everything in those new fields would be useful. I don't think it should matter if the application prefers its own environment variables or legacy config paths, or if it migrates old configs to xdg dirs. I think it's good enough as long as you can run the latest version for the first time and it follows the spec.
I definitively support getting rid of the misleading word "Partial". The fact that there are workarounds using per-application environment variables does not change the fact that most of that software does not support the spec at all.
-- nl6720 (talk) 12:09, 23 April 2020 (UTC)
I think its definitely confusing/annoying: [1]. Documenting these particularities would avoid confusion. -- Svito (talk) 11:27, 25 April 2020 (UTC)
As long as the column title meanings are explained, I think it would certainly be an improvement over the current tables. -- nl6720 (talk) 09:24, 28 April 2020 (UTC)

Should Organizations/DEs be mentioned?

Kind of obvious that the major DEs follow the spec since is mainly run by those groups, but I think that that's not obvious from this article. I think it's important to mention how KDE, GNOME, Qt, GTK, Debian, Ubuntu, Red Hat, etc. are following the spec. Since they're not single applications they don't really fit in any of the main sections, but I think they definitely deserve the mention.

Hobyamnlyzfsr (talk) 21:35, 9 September 2019 (UTC)

It's not obvious, even does fully not follow its own standards: e.g. Cursor themes#XDG specification does not use the XDG base directory standard... -- Lahwaacz (talk) 07:54, 23 April 2020 (UTC)

MPV removing XDG support

It looks like MPV will need to be removed from this as the author decided it's "stupid" - see

Not sure if this will make it into a release branch though as a few days ago he also made it crash on boot at Gnome because gnome was also "broken" or something and then reverted it (or if Arch devs will revert this pointless commit for the Arch package).

—This unsigned comment is by Vash63 (talk) 11:45, 9 July 2020‎. Please sign your posts with ~~~~!

For the record, this change never made it to a release version. It was reverted 2020-10-15.[2] Comic-paralyze-image (talk) 22:09, 29 December 2020 (UTC)


I updated the android paths, but these might also be valid alternatives:

$ export ANDROID_AVD_HOME="$XDG_DATA_HOME"/android/avd

In the end I decided it would make more sense to have emulators and their configuration together in XDG_DATA_HOME, as the configuration is probably useless on its own.

—This unsigned comment is by Xerus (talk) 10:55, 23 December 2020 (UTC). Please sign your posts with ~~~~!

Tried the android configuration suggested, as well as `ADB_VENDOR_KEYS` (as suggested by `adb --help`). None of these had any effect.

Gesh (talk) 19:46, 3 February 2021 (UTC)



somehow the suggested way to set up the VIMINIT environment variable in case you want to use separate configs for Vim and Neovim

export VIMINIT='if !has('nvim') | source "$XDG_CONFIG_HOME/vim/vimrc" | endif'

does not work for me. I had to change it to:

export VIMINIT='if !has("nvim") | let $MYVIMRC="$XDG_CONFIG_HOME/vim/vimrc" | else | let $MYVIMRC="$XDG_CONFIG_HOME/nvim/init.vim" | endif | source $MYVIMRC'

Besides some minor fixes to the first line, that were necessary to make the first line work in Vim (e.g. double quotes around nvim), with the first line Neovim didn't load my ~/.config/nvim/init.vim. The second line fixes this issue.

I'm using Vim version 8.2.1989 and Neovim version 0.4.4.

I didn't want to change the article right away, because maybe I just did something else wrong. Does someone has the same issue with the suggested setup?

Schuam (talk) 07:41, 29 December 2020 (UTC)


Mozilla Firefox puts the default profile in ~/.mozilla/. There is a workaround for "moving" it out of the home directory, though — Firefox has the command line option --profile (I can't actually find documentation on this online, and there's no Firefox man page, but it's in the firefox --help output), which lets you specify a different profile directory to use than the one in the home directory. If you write a shell script wrapper for firefox to use a profile from, say, $XDG_DATA_HOME/mozilla/firefox, then ~/.mozilla/ basically becomes useless.

Note that even when specifying a different profile directory, ~/.mozilla/ still gets created regardless. Though, this directory can be removed safely without affecting the new profile, so in the same wrapper script you could automatically remove the ~/.mozilla/ directory immediately after its creation.

Should this be included in Firefox's entry under Notes? I think it's at least worth mentioning for people that really want to move Firefox out of the home directory.

Inco (talk) 20:52, 20 April 2021 (UTC)

It should be added to the Firefox page and then linked from the notes column. -- Lahwaacz (talk) 20:58, 20 April 2021 (UTC)
The ~/.mozilla directory gets recreated during the runtime of Firefox. I wrote a wrapper which solves this issue: MozXDG -- Jorengarenar (talk) 09:05, 21 April 2021 (UTC)

Obscure software

Was wondering how much sense it would make to add obscure/rare software to the list, such as games. I was specifically thinking about MapTool which places files in the home directory but can be configured not to. Maze (talk) 03:04, 24 June 2021 (UTC)

80% of this page is already for obscure software, so I don't see how it would make a difference. -- MrX (talk) 11:47, 24 June 2021 (UTC)

Where to put workarounds?

Some are statically set Variables, some are dynamically obtained (scripted), some are aliases, some can be set in shell, some need to be set before graphical login. So where to set them per user, where globally? I think that should be mentioned in the wiki.

Per user i have them in ~/.bashrc and ~/.bash_aliases (respective XDG_CONFIG_HOME/bash/..., must be set before shell launched) and in ~/.xinitrc and ~/.xprofile and/or ~/.xsession (respective XDG_CONFIG_HOME/session/...).

But the global settings? Should they go to /etc/X11/xinit/xinitrc.d/? And things like bash's HISTFILE to /etc/profile.d and .../Xsession edited to load /etc/profile?

Baerbeisser (talk) 07:23, 6 August 2021 (UTC)