Talk:XDG Base Directory

emacs

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)

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 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 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.

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

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

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

Android

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.

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

Vim/Neovim

Hi,

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)

Firefox

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)

ReadALConfig() in alconfig.cpp searches xdg paths in addition to legacy (~/.alsoftrc and /etc/alsoft.conf so I'll add it to "supported" wowaname # C 22:02, 14 February 2023 (UTC)

Adding references to developer communication unavailable on web

Talked to xscreensaver upstream re XDG, they clearly communicated WONTFIX. However, since they don't use a bugtracker and instead only communicate via direct email, there is no webpage to link to. ATM, just copied their response into the table -- <ref> doesn't appear to work there. However, this is clearly suboptimal -- is there a better way of doing this? Gesh (talk) 10:10, 6 August 2023 (UTC)

You can just add a link. — Lahwaacz (talk) 12:22, 6 August 2023 (UTC)

Am confused. I just spent the entire paragraph above explaining why there is no page to link to -- only an email by upstream to me where they expressed their strong objection to changing the situation. I guess you _could_ bug upstream to add an entry to the FAQ, but I'd rather not prod them for that myself, given the vehemence of the objection (I gather it might be a bit of a sore spot).

In case my edit is restored, further communication from upstream yesterday (2023-08-06) seems to confirm invoking xscreensaver with HOME=$XDG_CONFIG_HOME/xscreensaver/ should work (referring to ~/.xscreensaver)

Both xscreensaver and xscreensaver-settings use that file and communicate with each other through it. xscreensaver-text, xscreensaver-getimage-file and vidwhacker also read it. xscreensaver-getimage-file and mapscroller.pl use FreeDesktop locations for cache files if those directories exist.

Gesh (talk) 18:05, 7 August 2023 (UTC)

I meant you could add a link instead of <ref> which technically does not work on this wiki. — Lahwaacz (talk) 21:12, 7 August 2023 (UTC)

How would that help? The entire reason I'm asking for <ref> is to be able to move the contents of the email I'm citing to a footnote or similarly move it to somewhere where it doesn't dominate the page. Where would I link to? Unless you're suggesting I encode it in a data url or pastebin it, a la [data:text/plain;charset=utf-8;base64,SSB0aGluayB3aGF0IHlvdSdyZSBhc2tpbmcgZm9yIGlzOiBzdG9yZSB0aGUgY29uZmlndXJhdGlvbiBmaWxlIHNvbWV3aGVyZSBvdGhlciB0aGFuIGxpdGVyYWxseSB+Ly54c2NyZWVuc2F2ZXIsIGFuZCBubywgSSdtIG5ldmVyLCBldmVyIGdvaW5nIHRvIGRvIHRoYXQuIEl0IGhhcyB0aG]? Note that even that is unsupported -- wiki only allows linking to http(s) urls. Gesh (talk) 08:24, 8 August 2023 (UTC)

That would be a blunt abuse of <ref> as that is intended for verifiable citations. There is no alternative solution for what you want to do. You need a verifiable source to cite, so either convince upstream to make a public statement or disclose the private communication somewhere (which may be unethical in itself). If you don't want to do it, I suggest you just leave it. — Lahwaacz (talk) 08:37, 8 August 2023 (UTC)

Fine, talked with upstream, they didn't want to put in the FAQ, so I guess this will remain undocumented. Too bad. Gesh (talk) 11:26, 11 August 2023 (UTC)

Please don't add hacky solutions

Aliasing rm -rf tastes like a recipe for disaster. If a program does not support XDG Base Directory, please don't propose hacky workarounds. --AvidSeeker (talk) 06:36, 9 August 2023 (UTC)

If the partial support for XDG Base Directories is so broken that the entire workflow collapses without a hacky workaround, then the software doesn't deserve to be in the partial support section under this new rule. But there's no section for software whose partial support is so broken that the support may as well not exist. Since python-filetags^AUR neither fully nor partially supports XDG Base Directories, but also doesn't hardcode a path, I removed the package from the list entirely.

The only reason why my original solution didn't use a hacky workaround is because I fixed the bug in my fork. But the fix is currently stuck in PR review limbo. — Fedora (talk) 07:02, 9 August 2023 (UTC)

Octave now seems to support XDG Base Directory

Opening Octave, I can see that the settings are put in `${XDG_CONFIG_HOME}/octave/octaverc`, and the history in `${XDG_DATA_HOME}/octave/history`. However, as I'm not a user of the software, I don't know if there are some parts of it that still don't respect it.

—This unsigned comment is by SuperSamus (talk) 17:04, 27 September 2023. Please sign your posts with ~~~~!

sqlite3 should no longer be considered hardcoded

sqlite3 version 3.43.2 (and likely earlier versions) will read $XDG_CONFIG_HOME/sqlite3/sqliterc without needing to pass that path through -init.

ClimbTheStairs (talk) 23:55, 2 November 2023 (UTC)

Hello,

I don't see anything about it in the Changelog.

I tested with a Docker archlinux container with pacman -Sy && pacman -S sqlite3, these are the files the sqlite3 (3.44.2) binary tries to access:

[root@a16321f44e60 ~]# whatfiles -o wf-version sqlite3 --version

whatfiles log location: wf-version

3.44.2 2023-11-24 11:41:44 ebead0e7230cd33bcec9f95d2183069565b9e709bf745c9b5db65cc0cbf9alt1 (64-bit)

[root@a16321f44e60 ~]# cat wf-version

mode: read, file: /usr/lib/glibc-hwcaps/x86-64-v3/libreadline.so.8, syscall: openat(), PID: 64, process: sqlite3

mode: read, file: /usr/lib/glibc-hwcaps/x86-64-v2/libreadline.so.8, syscall: openat(), PID: 64, process: sqlite3

mode: read, file: /usr/lib/libreadline.so.8, syscall: openat(), PID: 64, process: sqlite3

mode: read, file: /usr/lib/libm.so.6, syscall: openat(), PID: 64, process: sqlite3

mode: read, file: /usr/lib/libz.so.1, syscall: openat(), PID: 64, process: sqlite3

mode: read, file: /usr/lib/libc.so.6, syscall: openat(), PID: 64, process: sqlite3

mode: read, file: /etc/ld.so.cache, syscall: openat(), PID: 64, process: sqlite3

mode: read, file: /usr/lib/libncursesw.so.6, syscall: openat(), PID: 64, process: sqlite3

mode: read, file: /etc/nsswitch.conf, syscall: openat(), PID: 64, process: sqlite3

mode: read, file: /etc/passwd, syscall: openat(), PID: 64, process: sqlite3

mode: read, file: /root/.sqliterc, syscall: openat(), PID: 64, process: sqlite3

It seems that there is no attempt at all to check around ~/.config/, only ~/.sqliterc is read, and if you were to run commands within the sqlite shell, history would be written to ~/.sqlite_history. ToM (talk) 22:25, 6 January 2024 (UTC)

Hi, I did a bit more testing. Apparently, sqlite3 will read $XDG_CONFIG_HOME/sqlite3/sqliterc only if (1) XDG_CONFIG_HOME is set, and (2) $XDG_CONFIG_HOME/sqlite3/sqliterc exists.

Here are the commands and output I used:

# export XDG_CONFIG_HOME=$HOME/etc
# mkdir -p "$XDG_CONFIG_HOME/sqlite3"
# touch "$XDG_CONFIG_HOME/sqlite3/sqliterc"
# whatfiles -o wf-version sqlite3 --version
whatfiles log location: wf-version
-- Loading resources from /root/etc/sqlite3/sqliterc
3.44.2 2023-11-24 11:41:44 ebead0e7230cd33bcec9f95d2183069565b9e709bf745c9b5db65cc0cbf9alt1 (64-bit)
# cat wf-version
mode:  read, file: /usr/lib/libreadline.so.8, syscall: openat(), PID: 168015, process: sqlite3
mode:  read, file: /usr/lib/libm.so.6, syscall: openat(), PID: 168015, process: sqlite3
mode:  read, file: /usr/lib/libz.so.1, syscall: openat(), PID: 168015, process: sqlite3
mode:  read, file: /usr/lib/libc.so.6, syscall: openat(), PID: 168015, process: sqlite3
mode:  read, file: /etc/ld.so.cache, syscall: openat(), PID: 168015, process: sqlite3
mode:  read, file: /usr/lib/libncursesw.so.6, syscall: openat(), PID: 168015, process: sqlite3
mode:  read, file: /root/etc/sqlite3/sqliterc, syscall: openat(), PID: 168015, process: sqlite3

ClimbTheStairs (talk) 23:22, 6 January 2024 (UTC)

I can reproduce your example but what I don't understand is:

> and (2) $XDG_CONFIG_HOME/sqlite3/sqliterc exists.

Unexpected egg'n'chicken situation here! To know whether the file exists, a read attempt has to be made, which we don't see in my quoted output. It only show the read attempt on /root/.sqliterc, which does not exists at this point - still a read attemp is required.

(ps: here is find_xdg_config() in sqlite source)

ToM (talk) 12:21, 7 January 2024 (UTC)

aws-cdk

https://aur.archlinux.org/packages/aws-cdk

https://github.com/aws/aws-cdk/issues/7530

`export CDK_HOME="$XDG_DATA_HOME"/cdk`

CDK will still make a ".cdk" folder within CDK_HOME.

My only item within CDK_HOME/.cdk is a "cache" folder.

Would like some feedback on whether XDG_DATA_HOME is appropriate since the app doesn't follow XDG, or if another dir would be better. Ntippie (talk) 18:42, 6 January 2024 (UTC)

Moving "Supported" section to Xdg Base Directory/Supported

This list is getting too long; let's move supported programs to a separate wiki page.

If a program fully supports XDG base directories with no problem, I see no reason for it to be listed here. I'd suppose that users often check this wiki page for partially supported or unsupported programs to see the current status or if there is a workaround. AvidSeeker (talk) 23:57, 9 February 2024 (UTC)

While I agree the tables are too long and unwieldy, I think removing the "supported" section is somewhat contentious:

• Many programs under "supported" include notes about fallback behaviour for historical locations which are useful for when migrating to XDG.
• Many programs are only "supported" from specific versions, and understanding which version is useful for understanding when/if it's possible to migrate.
• Some programs only "support" XDG in some usecases. For example, only when used by itself and embedded use or use with plugins may not work.
• Many programs say they're using XDG but their usage of it is caveated:
  • The program may have just moved everything from ~/.foo/ to ${XDG_CONFIG_HOME}/foo so although it's putting files in the config directory, that directory includes things like logs (state), binaries & plugins (data), etc. It's debatable if this really counts as supporting the standard rather than abusing it.
  • The program may have different behaviour depending on the existence of env vars. For example, it may have it's own FOO_CONFIG variable which takes precedent.
  • The program may have different behaviour if directories exist in their "legacy" locations. For example, if ~/.foo/ still exists in the user's home it won't load any XDG dirs.
  • The program may have different behaviour if a local config file exists. For example, it may not load XDG dirs if a .foo/ dir exists in the current working directory.

IMO, the correct solution to the massive tables is to refactor the page. Instead of three tables for supported/partial/hardcoded - the data is instead grouped alphabetically, with tables for A..Z and programs don't move between sections. This makes it easier to navigate, and better reflects that programs often choose to implement the standard in different ways.

I previously tried to propose a new unified set of columns between the three sections without success. I would be happy to do the migration but it's a lot of work if somebody doesn't engage on the talk page but decides to revert the change regardless.

Comic-paralyze-image (talk) 12:07, 11 February 2024 (UTC)

What I usually do is search (CTRL+F) for the package. This automatically bolds the supported/partial/hardcoded subsection the first match is in. So, the current simple layout has advantages in my opinion. The other reasons Comic-paralyze-image lists are valid too, of course. At least for now I don't see it that helpful to move supported out of the way either. Then, for a unified table an extra column is needed, leaving less space for all the ~/.config/.. items (and even less for the hardcoded ones, which don't need the 'supported since' column), while we still want the TOC on the left. So, not sure it's much to gain for now.

I was wondering if we switch order of the subsections, but it's less logical and line item numbers don't vary that much at this moment. It's not about my way, but is the status quo really that impractical?

--Indigo (talk) 21:44, 11 February 2024 (UTC)

Terraform RC File

Per the current documentation ( https://developer.hashicorp.com/terraform/cli/config/config-file#locations ), `TF_CLI_CONFIG_FILE` can be used to point to a `*.tfrc` file. The plugin cache dir can be set from the rc file too. --harleypig 07:44, 1 March 2024 (UTC)