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)


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)


XDG_RUNTIME_DIR is set by pam_systemd, so for the majority of Arch installations it is already set - "some systems" is ambiguous. It might be more useful to mention XDG_RUNTIME_DIR in init instead, together with XDG_VTNR. -- Alad (talk) 12:48, 26 December 2015 (UTC)

Thanks, for the moment I've made this edit: users on non-systemd machines will be able to adapt the information.
If you have a good idea for mentioning those vars in init, it can be interesting indeed.
Kynikos (talk) 05:10, 27 December 2015 (UTC)
While certainly useful and relevant for init, the article itself is short in the section. But Init#Dbus links out to Systemd/User#D-Bus, which has a subsection Systemd/User#Environment variables. How about adding it there instead? --Indigo (talk) 19:27, 4 January 2016 (UTC)
If we can verify that neither variables are set in the user instance, then +1 for adding them to that section. -- Alad (talk) 13:16, 16 January 2016 (UTC)

The wiki does not indicate what XDG_RUNTIME_DIR is set to (/run/user/$UID) This is the only XDG directory that isn't listed in the wiki and that information would have helped me. My edit was rejected as being redundant with the note. I'd suggest then that either the path be added to the note, or the note moved to the XDG_RUNTIME_DIR section and include the path there. —This unsigned comment is by Skimj (talk) 05:28, 12 December 2016‎. Please sign your posts with ~~~~!

The standard does not specify any default path for XDG_RUNTIME_DIR and we should not mix Arch-defaults with the standard paths. There is a link to pam_systemd which manages the variable. -- Lahwaacz (talk) 08:03, 12 December 2016 (UTC)
I only disagree that providing a key peice of information about how a software program operates is outside the scope of the wiki. Note also that the current pam_systemd documentation is slightly wrong: $USER vs. $UID.

Relevance of Arch-specific content on the ArchWiki

User:Earnest removed some content by judging it as "irrelevant", despite being clearly related to Arch Linux. The goal of that section can't simply be to mirror the specification, otherwise a simple link to it will be fine. I have undone the removal. Instead of starting an edit war, let's settle the issue here. — Kynikos (talk) 12:11, 4 January 2016 (UTC)

The article relies that those variables are set somewhere, and the bug report provides some historical background. That said, what Arch does is not part of the specification; so those lines should either be a Note (as we have now), or moved to a more appropriate section (or article?) and part of the regular text.
In either case, it's preferable to have the text in one place, i.e. merge the two notes on Arch and XDG_RUNTIME_DIR. -- Alad (talk) 13:14, 16 January 2016 (UTC)
Since this is our only article that discusses the support for the specification (and it wouldn't make sense to have another), I think it's only natural that, even before talking about the various applications, we say how Arch itself supports it.
If it was me, I'd take a different approach, and restructure the "The XDG Base Directory specification" section so that, instead of duplicating the upstream specification (which is as easy to read), its primary goal is indeed to introduce what variables have to be defined by end users in an Arch system, and which ones are set by default, still accompanying them with short descriptions of their purpose, so that using Notes isn't even necessary anymore. The section could be renamed to e.g. "Define the variables".
Kynikos (talk) 05:33, 17 January 2016 (UTC)
If you have a different approach in mind, could you make a draft here or on your user page?
About the variables, more expansive descriptions may be better suited for other articles, such as systemd/User, as suggested in #Expansion. For example, compare [1] for the importance of XDG_RUNTIME_DIR to systemd/User. We could then link from here. -- Alad (talk) 00:51, 29 January 2016 (UTC)
I didn't have anything complicated in mind, just rewriting the section intro from a different perspective, see User:Kynikos/XDG Base Directory support for an example. Note that XDG_RUNTIME_DIR is actually a link to Systemd/User#XDG_RUNTIME_DIR where I too think we should move the specific info. — Kynikos (talk) 04:16, 30 January 2016 (UTC)

Sample the explicit XDG Base Directory environment variables setup

[Moved from Talk:General recommendations. -- Alad (talk) 14:40, 22 September 2016 (UTC)]
  • Someone, more experienced in proper usage of XDG Base Directory environment variables, - can contribute configuration from his setup (that complies both Arch architecture an XDG Base Directory Specification). - PiroXiline (talk) 14:08, 20 September 2016 (UTC)
This page provides a general overview, not specific procedures. In this case, those are already outlined in XDG Base Directory support. -- Alad (talk) 08:35, 21 September 2016 (UTC)
I wrote here, because raising a post-install process addition is to start a discussion in 'General recommendations'. I could not start it in XDG Base Directory support, and :::I wrote here, because raising a post-install process addition is to start a discussion in 'General recommendations'. I could not start it in XDG Base Directory support, and start to explain the major point to add reference info from 'General recommendations' there. - PiroXiline (talk) 14:19, 22 September 2016 (UTC)
Here is proposition of sample from my setup:

Explicitly set XDG Base Directory environment variables

By default in Arch XDG Base Directory environment variables are empty, relaying on XDG Base Directory Specification defaults.

If these variables are empty, some programs doesn't comply to specification, and place their data in $HOME/.app-folder. In $HOME/.app-folder application starts to store all it's information (configuration files, data, and cache simultaneously). While XDG Base Directory usage requires separation of configuration files, data, and cache.

Changing the environment variables after these programs placed their data in $HOME/.app-folder, creates a problem of separation and linking all applications to configuration files, data and caches. Otherwise default application behavior is to populate new directories with default configuration, data and caches.

So a good workaround to that issue is set XDG Base Directory environment variables after Arch Linux basic installation during post-install process. While system is in clear state.

To explicitly set XDG Base Directory environment variables to proper defaults:

Note: Environment file ~/.pam_environment does not provide support for globing or variable expansion of shells, so '$HOME' or '~' taken as literal relative directory names.
Note: If no path specified in ~/.pam_environment is not absolute path, than path relative to user $HOME is implied.

So it also can be:


XDG_*_HOME variables has priority over XDG_*_DIRS.

Many things not obvious in Environment_variables#Defining_variables and specs, that is why I checked it by try and error and made a notes to users. Maybe that notes need to be merged in Environment_variables#Defining_variables, I rely on your opinion.
I, for myself, also added to XDG_DATA_DIRS and XDG_DATA_DIRS some additional cross-reference paths, for a purpose cleaning-up and some live migration. So apps look in more places to find their configs/data/caches.
So also can be added Tip:
Tip: On manual migration, cross-reference paths can be added to end of XDG_*_DIRS, if needed. So application, after XDG_*_HOME, going to look in XDG_*_HOME with more places to find configuration, data and cache.
-- PiroXiline (talk) 14:38, 22 September 2016 (UTC)
The first part gives the impression that setting XDG_* variables is somehow going to make applications which do not respect the specification comply, which is obviously false.
The second part duplicates Environment variables. If something is not clear in that article, mention it on the talk page: Talk:Environment variables. -- Alad (talk) 14:47, 22 September 2016 (UTC)

Arch package page, or project page?

Currently in the Application column of the tables, there are three types of links: wiki links like fish, package links like ncurses (including AUR like sublime-text-devAUR), and project links like antimicro. Is there any consensus about the preference of these three types? I suggest wiki links over package over project links, because:

  1. Wiki pages have more information, and typically contains both package links and project links.
  2. Package pages contains project links, along with some information useful to Arch users.

Thoughts? --Franklin Yu (talk) 20:28, 22 April 2017 (UTC)

To be honest I'm not sure why this page even contains package links; we have List of applications and dedicated articles where we already keep those links up-to-date. Using wiki links instead does sound like a better idea. -- Alad (talk) 22:47, 22 April 2017 (UTC)
So you prefer project links over package links? Or no link at all, if the application does not have a Wiki link? --Franklin Yu (talk) 06:22, 23 April 2017 (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)