Talk:XDG Base Directory

From ArchWiki


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)
Would it be advised to use symbolic links to manually split such offending programs into their corresponding places? There are a lot of offending packages that store their cache inside the $XDG_CONFIG_HOME instead of in $XDG_CACHE_HOME. I noticed a pattern, though. Most of the offenders use Electron, or are Chromium-based browsers... could they be nudged to automatically migrate the data to the corresponding places? Rolandog (talk) 12:58, 10 February 2022 (UTC)
To answer your first question, for any use cases I can think of, I wouldn't advise it. For the case of having all of your ~/.config in VCS, replacing the offending configurations with symlinks provides no clear advantage over adding a line to a .gitignore. In fact, this increases the overhead needed to setup a new system, and some might argue that the complexity added to your hierarchy by having the same files in two locations is also undesirable.
As for the Electron programs, this is an even more egregious abuse of $XDG_CACHE_HOME than Alad was referring to. This section was, as I understand it, mainly targeting Qt programs who put human-unreadable, non-configuration state in configuration files. Nevertheless, the same principles apply. Add the offending programs to a .gitignore. Though most Electron programs indeed share a common structure, I feel like .gitignore is too primitive to do anything very useful with this information. I think you still be best off blocking entire Electron program config directories manually. Cheers, CodingKoopa (talk) 04:42, 2 March 2022 (UTC)
I deleted Chromium from the `partial' list because it abuses the ~.config directory. Unfortunately it had some links. I woudn't put it in the `hardcoded' section though. Maybe we could have an `unsupported' section, to be used when we need to explain why we consider some program unsupported and write there some references? Tétrapyle (talk) 08:59, 20 December 2022 (UTC)
Programs like Chromium are not "unsupported" in the same way that programs who use $HOME/.directory, and this should be reflected in their placement. Given how prevalent XDG abuse is, I would honestly put them where they would go anyways, and note the abuse in the Notes column. The alternatives would unneededly complicate the page by adding another "degree" of support, I think. -- CodingKoopa (talk) 02:22, 25 December 2022 (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)
I for one am not fond of 5 (?!) additional colored columns. It leads to visual overload, there's already enough columns in the table as is. Maybe we can just think of some alternative categories if "partial" is deemed misleading. -- Alad (talk) 08:24, 11 November 2021 (UTC)
I question the value add for all the extra fields. Especially as compliance in programs tends to be more nuanced than this allows. For example, many programs make use of XDG_CONFIG_HOME but debatably fail to correctly follow the standard, mixing state with config, etc. The reality is many developers have different interpretations of the standard which would require far more binary options to capture. I propose a simpler table that doesn't try to over-define abstract values for implementations, and just captures the implementation detail.
Application Official paths XDG Base Directory Implementation Notes
Cool-utils .cool-utils/, $XDG_CONFIG_HOME/cool-utils/ Uses $XDG_CONFIG_DIR by default as of 1.2.0.[2] Stores extension binaries with config.
git-xmonad .git-xmonad No After legacy
Dumper $XDG_DATA_HOME/dumper/ Yes (an example of a program that always had native support for the standard)
Hostile-app .hostileapp/ [WONTFIX No] Workaround: $ export GARBAGEBIN="$XDG_DATA_HOME"/hostile-app
Comic-paralyze-image (talk) 15:23, 11 November 2021 (UTC)
More columns are better for people…
  • maintaining this page
  • looking to move projects towards supporting XDG more
  • selecting software based on XDG-support
Fewer columns are better for people…
  • trying to get their particular piece of software to work better with XDG
That's my current impression.
  • I've spent more time as part of the more-columns-group, than I have as part of the fewer-columns-group.
  • I suspect that much more time is spent by the latter group.
  • The table should imo still stay readable to people who are seeing it for the 1st time (Cpt. Obvious).
  • But it would be nice to be able to express and sort by more granularity.
  • I disagree that more columns automatically make it overwhelming; Wikipedia has a lot of these tables. They've probably put a lot of thought into them, and they're still using them. Cyethiod (talk) 13:55, 12 November 2021 (UTC)
It doesn't matter what Wikipedia has or hasn't. Adding 5 columns is an extreme measure to add "more granularity". 1 extra column is fine for me. -- Alad (talk) 14:01, 12 November 2021 (UTC)
I disagree. Most, if not all people who arrive at this ArchWiki-article, have seen Wikipedia pages with tables in them. Both projects even use the same software. Worth mentioning: Lahwaacz's doubt that even Wikipedia has a table as large as those on this page.
Am I right in thinking that you and I agree on more granularity, but not on the way to achieve it? :) Cyethiod (talk) 16:18, 12 November 2021 (UTC)
I doubt that even Wikipedia has a table as large as those on this page... — Lahwaacz (talk) 15:13, 12 November 2021 (UTC)
Would this serve as a sufficient counter-example? 23 columns (36 rows) - Comparison of virtual reality headsets #Tethered. Cyethiod (talk) 16:12, 12 November 2021 (UTC)
That's not nearly as large, since there are over 400 rows in 4 tables on this page. Also none of those 23 columns contains arbitrary-width content like the current "Notes" column here. None of the proposals above removed that column, and one even added another column where arbitrary notes might be added. — Lahwaacz (talk) 16:37, 12 November 2021 (UTC)
For every user on Wikipedia that wants larger, more verbose tables, there are a dozen users that will cite rules about Manual of Style violations, original research, etc. I would not hold Wikipedia articles as a shining example of _the correct way to do something_. If you really want a reference from Wikipedia, I would find a MOS page instead.
In general I am a more-columns person, but having made some effort myself to implement overrides I really think we would need more than six columns to capture **everything** meaningful.
If we wanted more columns, I would suggest following the standard more closely:
Application Data files Configuration files State data Executable files Notes
Cool-utils $XDG_CONFIG_HOME/cool-utils/ as of 1.2.0.[3] $XDG_CONFIG_HOME/cool-utils/ Stores extension binaries with config.
git-xmonad .git-xmonad[4] .git-xmonad After legacy
Dumper $XDG_DATA_HOME/dumper/ $XDG_CONFIG_HOME/dumper/ (an example of a program that always had native support for the standard)
Hostile-app .hostileapp/WONTFIX .hostileapp/ .hostileapp/ Workaround: $ export GARBAGEBIN="$XDG_DATA_HOME"/hostile-app
The biggest problem with an extended table like this, is the additional onus on writers to confirm AND AGREE that an implementation is correct. Agreeing on the standard doesn't appear to be easy.
--Comic-paralyze-image (talk) 18:53, 12 November 2021 (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.[5] 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)

OpenAL .alsoftrc

i'm pretty sure openal supports xdg base dir since it's in the changelog, but i don't want to contribute it myself since i don't know how to actually test if what i do is correct. every other archwiki page i've seen (such as Gaming#Binaural_audio_with_OpenAL) only mentions ~/.alsoftrc. can someone help figure out the situation with openal?

SArpnt (talk) 23:32, 5 November 2022 (UTC)