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.
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
- 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)?
- #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
- 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)
Should Organizations/DEs be mentioned?
Kind of obvious that the major DEs follow the spec since Freedesktop.org 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.
- It's not obvious, even freedesktop.org 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 https://github.com/mpv-player/mpv/commit/269f0e743e5634691f0c9d5b1b8a4bb68eedbbd0
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).
- For the record, this change never made it to a release version. It was reverted 2020-10-15. Comic-paralyze-image (talk) 22:09, 29 December 2020 (UTC)
I updated the android paths, but these might also be valid alternatives:
$ export ANDROID_EMULATOR_HOME="$ANDROID_PREFS_ROOT"/emulator $ 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.
Tried the android configuration suggested, as well as `ADB_VENDOR_KEYS` (as suggested by `adb --help`). None of these had any effect.
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?
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,
~/.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.
- It should be added to the Firefox page and then linked from the notes column. -- Lahwaacz (talk) 20:58, 20 April 2021 (UTC)