https://wiki.archlinux.org/api.php?action=feedcontributions&user=Baerbeisser&feedformat=atomArchWiki - User contributions [en]2024-03-28T11:58:31ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Polkit&diff=777727Polkit2023-05-10T21:17:56Z<p>Baerbeisser: Wiki has a page about theShell</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Security]]<br />
[[de:PolicyKit]]<br />
[[fr:Polkit]]<br />
[[ja:Polkit]]<br />
[[ru:Polkit]]<br />
[[zh-hans:Polkit]]<br />
{{Related articles start}}<br />
{{Related|Session}}<br />
{{Related|Sudo}}<br />
{{Related|Users and groups}}<br />
{{Related articles end}}<br />
From [https://www.freedesktop.org/wiki/Software/polkit/ polkit homepage]:<br />
<br />
:polkit is an application-level toolkit for defining and handling the policy that allows unprivileged processes to speak to privileged processes: It is a framework for centralizing the decision making process with respect to granting access to privileged operations for unprivileged applications.<br />
<br />
Polkit is used for controlling system-wide privileges. It provides an organized way for non-privileged processes to communicate with privileged ones. In contrast to systems such as sudo, it does not grant root permission to an entire process, but rather allows a finer level of control of centralized system policy.<br />
<br />
Polkit works by delimiting distinct actions, e.g. running GParted, and delimiting users by group or by name, e.g. members of the wheel group. It then defines how – if at all – those users are allowed those actions, e.g. by identifying as members of the group by typing in their passwords.<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|polkit}} package.<br />
<br />
=== Authentication agents ===<br />
<br />
An authentication agent is used to make the user of a session prove that they really are the user (by authenticating as the user) or an administrative user (by authenticating as an administrator). The {{Pkg|polkit}} package contains a textual authentication agent called 'pkttyagent', which is used as a general fallback. <br />
<br />
If you are using a graphical environment, make sure that a graphical authentication agent is installed and [[autostarting|autostarted]] on login (e.g. via [[xinitrc]]).<br />
<br />
[[Cinnamon]], [[Deepin]], [[GNOME]], [[GNOME Flashback]], [[KDE]], [[LXDE]], [[LXQt]], [[MATE]], [[theShell]] and [[Xfce]] have an authentication agent already.<br />
In other desktop environments, you have to choose one of the following implementations:<br />
* {{Pkg|lxqt-policykit}}, which provides {{ic|/usr/bin/lxqt-policykit-agent}}<br />
* {{Pkg|lxsession}} or {{Pkg|lxsession-gtk3}}, which provides {{ic|/usr/bin/lxpolkit}}<br />
* {{Pkg|mate-polkit}}, which provides {{ic|/usr/lib/mate-polkit/polkit-mate-authentication-agent-1}}<br />
* {{AUR|polkit-efl-git}}, which provides {{ic|/usr/bin/polkit-efl-authentication-agent-1}}<br />
* {{Pkg|polkit-gnome}}, which provides {{ic|/usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1}}<br />
* {{Pkg|polkit-kde-agent}}, which provides {{ic|/usr/lib/polkit-kde-authentication-agent-1}}<br />
* {{AUR|ts-polkitagent}}, which provides {{ic|/usr/lib/ts-polkitagent}}<br />
* {{AUR|xfce-polkit}} or {{AUR|xfce-polkit-git}}, which provides {{ic|/usr/lib/xfce-polkit/xfce-polkit}}<br />
* {{AUR|polkit-dumb-agent-git}}, minimalistic desktop independent agent which provides {{ic|/usr/bin/polkit-dumb-agent}}<br />
<br />
{{Tip|Before continuing, check your autostart configuration with a look at the process list. For example, with {{ic|pgrep -af polkit-gnome}}.}}<br />
<br />
== Configuration ==<br />
<br />
{{Warning|Do not amend the default permission files of packages, as these may be overwritten on package upgrades.}}<br />
<br />
Polkit definitions can be divided into two kinds:<br />
* '''Actions''' are defined in XML {{ic|.policy}} files located in {{ic|/usr/share/polkit-1/actions}}. Each action has a set of default permissions attached to it (e.g. you need to identify as an administrator to use the GParted action). The defaults can be overruled but editing the actions files is NOT the correct way.<br />
*'''Authorization rules''' are defined in JavaScript {{ic|.rules}} files. They are found in two places: <br />
** 3rd party packages can use {{ic|/usr/share/polkit-1/rules.d}} (though few if any do) <br />
** {{ic|/etc/polkit-1/rules.d}} is for local configuration.<br />
<br />
Polkit operates on top of the existing permissions systems in Linux – group membership, administrator status – it does not replace them. The .rules files designate a subset of users, refer to one (or more) of the actions specified in the actions files, and determine with what restrictions these actions can be taken by those users. As an example, a rules file could overrule the default requirement for all users to authenticate as an admin when using GParted, determining that some specific user does not need to. A different example: A certain user is not allowed to use GParted at all.<br />
<br />
{{Note|This does not preclude running GParted by means which do not respect polkit, such as the command line. Therefore, polkit should be used to expand access to privileged services for unprivileged users, rather than try to curtail the rights of (semi-)privileged users. For security purposes, [[Sudo|sudoers]] is still the way to go.}}<br />
<br />
=== Actions ===<br />
<br />
{{Tip|To display Policykit actions in a graphical interface, install the {{AUR|polkit-explorer-git}} package.}}<br />
<br />
The actions available to you via polkit will depend on the packages you have installed. Some are used in multiple desktop environments ''(org.freedesktop.*)'', some are DE-specific ''(org.gnome.*)'' and some are specific to a single program ''(org.gnome.gparted.policy)''. The command {{ic|pkaction}} lists all the actions defined in {{ic|/usr/share/polkit-1/actions}} for quick reference.<br />
<br />
To get an idea of what polkit can do, here are a few commonly used groups of actions:<br />
* '''[[Systemd|systemd-logind]]''' ''(org.freedesktop.login1.policy)'' actions regulated by polkit include powering off, rebooting, suspending and hibernating the system, including when other users may still be logged in.<br />
* '''[[udisks]]''' ''(org.freedesktop.udisks2.policy)'' actions regulated by polkit include mounting file systems and unlocking encrypted devices.<br />
* '''[[NetworkManager]]''' ''(org.freedesktop.NetworkManager.policy)'' actions regulated by polkit include turning on and off the network, wifi or mobile broadband.<br />
<br />
Each action is defined in an {{ic|<action>}} tag in a .policy file. The {{ic|org.gnome.gparted.policy}} contains a single action and looks like this:<br />
<br />
<?xml version="1.0" encoding="UTF-8"?><br />
<!DOCTYPE policyconfig PUBLIC<br />
"-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"<br />
<nowiki>"http://www.freedesktop.org/software/polkit/policyconfig-1.dtd"></nowiki><br />
<policyconfig><br />
<br />
<action id="org.gnome.gparted"><br />
<message>Authentication is required to run the GParted Partition Editor</message><br />
<icon_name>gparted</icon_name><br />
<defaults><br />
<allow_any>auth_admin</allow_any><br />
<allow_inactive>auth_admin</allow_inactive><br />
<allow_active>auth_admin</allow_active><br />
</defaults><br />
<annotate key="org.freedesktop.policykit.exec.path">/usr/bin/gparted</annotate><br />
<annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate><br />
</action><br />
<br />
</policyconfig><br />
<br />
The attribute '''id''' is the actual command sent to [[D-Bus]], the '''message''' tag is the explanation to the user when authentication is required and the '''icon_name''' is sort of obvious. <br />
<br />
The '''defaults''' tag is where the permissions or lack thereof are located. It contains three settings: '''allow_any''', '''allow_inactive''', and '''allow_active'''. Inactive sessions are generally remote sessions (SSH, VNC, etc.) whereas active sessions are logged directly into the machine on a TTY or an X display. allow_any is the setting encompassing both scenarios. <br />
<br />
For each of these settings the following options are available:<br />
* ''no'': The user is not authorized to carry out the action. There is therefore no need for authentication.<br />
* ''yes'': The user is authorized to carry out the action without any authentication.<br />
* ''auth_self'': Authentication is required but the user need not be an administrative user.<br />
* ''auth_admin'': Authentication as an administrative user is required.<br />
* ''auth_self_keep'': The same as auth_self but, like sudo, the authorization lasts a few minutes.<br />
* ''auth_admin_keep'': The same as auth_admin but, like sudo, the authorization lasts a few minutes.<br />
These are default setting and unless overruled in later configuration will be valid for all users.<br />
<br />
As can be seen from the GParted action, users are required to authenticate as administrators in order to use GParted, regardless of whether the session is active or inactive.<br />
<br />
=== Authorization rules ===<br />
<br />
Authorization rules that overrule the default settings are laid out in a set of directories as described above. For all purposes relating to personal configuration of a single system, only {{ic|/etc/polkit-1/rules.d}} should be used. <br />
<br />
The {{ic|addRule()}} method is used for adding a function that may be called whenever an authorization check for action and subject is performed. Functions are called in the order they have been added until one of the functions returns a value. Hence, to add an authorization rule that is processed before other rules, put it in a file in {{ic|/etc/polkit-1/rules.d}} with a name that sorts before other rules files, for example {{ic|00-early-checks.rules}}.<br />
<br />
The layout of the .rules files is fairly self-explanatory:<br />
/* Allow users in admin group to run GParted without authentication */<br />
polkit.addRule(function(action, subject) {<br />
if (action.id == "org.gnome.gparted" &&<br />
subject.isInGroup("admin")) {<br />
return polkit.Result.YES;<br />
}<br />
});<br />
<br />
Inside the function, we check for the specified action ID ''(org.gnome.gparted)'' and for the user's group ''(admin)'', then return a value "yes".<br />
<br />
=== Administrator identities ===<br />
<br />
The {{ic|addAdminRule()}} method is used for adding a function that may be called whenever administrator authentication is required. The function is used to specify what identities may be used for administrator authentication for the authorization check identified by action and subject. Functions added are called in the order they have been added until one of the functions returns a value. <br />
<br />
The default configuration for administrator identities is contained in the file {{ic|50-default.rules}} so any changes to that configuration should be made by copying the file to, say, {{ic|40-default.rules}} and editing that file.<br />
{{hc|/etc/polkit-1/rules.d/50-default.rules|<nowiki><br />
polkit.addAdminRule(function(action, subject) {<br />
return ["unix-group:wheel"];<br />
});</nowiki>}}<br />
<br />
{{Note|Your user needs to be listed as a member of the group in {{ic|/etc/group}}. Merely having it as your primary group does not work with polkit. See [https://gitlab.freedesktop.org/polkit/polkit/-/issues/131 polkit issue 131].}}<br />
<br />
The only part to edit (once copied) is the return array of the function: as whom should a user authenticate when asked to authenticate as an administrative user? If they are a member of the group designated as admins, they only need enter their own password. If some other user, e.g. root, is the only admin identity, they would need to enter the root password. The format of the user identification is the same as the one used in designating authorities. <br />
<br />
The Arch default is to make all members of the group '''wheel''' administrators. A rule like below will have polkit ask for the root password instead of the users password for Admin authentication.<br />
<br />
{{hc|/etc/polkit-1/rules.d/49-rootpw_global.rules|<br />
/* Always authenticate Admins by prompting for the root<br />
* password, similar to the rootpw option in sudo<br />
*/<br />
polkit.addAdminRule(function(action, subject) {<br />
return ["unix-user:root"];<br />
});<br />
}}<br />
<br />
== Examples ==<br />
<br />
=== Debugging/logging ===<br />
To enable logging with {{ic|polkit.log()}} function, remove {{ic|--no-debug}} flag from {{ic|ExecStart}} command in {{ic|/usr/lib/systemd/system/polkit.service}} file.<br />
The following rule logs detailed information about any requested access.<br />
{{hc|/etc/polkit-1/rules.d/00-log-access.rules|<nowiki><br />
polkit.addRule(function(action, subject) {<br />
polkit.log("action=" + action);<br />
polkit.log("subject=" + subject);<br />
});</nowiki>}}<br />
<br />
=== Disable suspend and hibernate ===<br />
<br />
{{Merge|Power management|This is probably a better fit for the dedicated page.}}<br />
<br />
The following rule disables suspend and hibernate for all users.<br />
{{hc|/etc/polkit-1/rules.d/10-disable-suspend.rules|<nowiki><br />
polkit.addRule(function(action, subject) {<br />
if (action.id == "org.freedesktop.login1.suspend" ||<br />
action.id == "org.freedesktop.login1.suspend-multiple-sessions" ||<br />
action.id == "org.freedesktop.login1.hibernate" ||<br />
action.id == "org.freedesktop.login1.hibernate-multiple-sessions")<br />
{<br />
return polkit.Result.NO;<br />
}<br />
});</nowiki>}}<br />
<br />
=== Bypass password prompt ===<br />
<br />
To achieve something similar to the [[sudo]] {{ic|NOPASSWD}} option and get authorized solely based on [[Users and groups|user/group]] identity, you can create custom rules in {{ic|/etc/polkit-1/rules.d/}}. This allows you to override password authentication either [[#For specific actions|only for specific actions]] or [[#Globally|globally]]. See [https://gist.github.com/4013294/ccacedd69d54de7f2fd5881b546d5192d6a2bddb] for an example rule set.<br />
<br />
==== Globally ====<br />
<br />
Create the following file as root:<br />
{{hc|/etc/polkit-1/rules.d/49-nopasswd_global.rules|<br />
/* Allow members of the wheel group to execute any actions<br />
* without password authentication, similar to "sudo NOPASSWD:"<br />
*/<br />
polkit.addRule(function(action, subject) {<br />
if (subject.isInGroup("wheel")) {<br />
return polkit.Result.YES;<br />
}<br />
});<br />
}}<br />
<br />
Replace {{ic|wheel}} by any group of your preference.<br />
<br />
This will result in automatic authentication for '''any''' action requiring admin rights via Polkit. As such, be careful with the group you choose to give such rights to.<br />
<br />
There is also {{ic|AUTH_ADMIN_KEEP}} which allows to keep the authorization for 5 minutes. However, the authorization is per process, hence if a new process asks for an authorization within 5 minutes the new process will ask for the password again anyway.<br />
<br />
==== For specific actions ====<br />
<br />
Create the following file as root:<br />
{{hc|/etc/polkit-1/rules.d/49-nopasswd_limited.rules|<nowiki><br />
/* Allow members of the wheel group to execute the defined actions <br />
* without password authentication, similar to "sudo NOPASSWD:"<br />
*/<br />
polkit.addRule(function(action, subject) {<br />
if ((action.id == "org.gnome.gparted" ||<br />
action.id == "org.libvirt.unix.manage") &&<br />
subject.isInGroup("wheel"))<br />
{<br />
return polkit.Result.YES;<br />
}<br />
});<br />
</nowiki>}}<br />
<br />
The {{ic|action.id}}s selected here are just (working) examples for GParted and [[Libvirt]], but you can replace them by any other of your liking as long as they exist (custom made or supplied by a package), and so can you define any group instead of {{ic|wheel}}.<br />
<br />
The {{ic|<nowiki>||</nowiki>}} operator is used to delimit actions (logical OR), and {{ic|&&}} means logical AND and must be kept as the last operator.<br />
<br />
==== Udisks ====<br />
<br />
[[File manager]]s may ask for a password when trying to mount a storage device, or yield a ''Not authorized'' or similar error. See [[Udisks#Configuration]] for details.<br />
<br />
=== Allow management of individual systemd units by regular users ===<br />
<br />
By checking for certain values passed to the polkit policy check, you can give specific users or groups the ability to manage specific units. As an example, you might want regular users to start and stop [[wpa_supplicant]]:<br />
<br />
{{hc|/etc/polkit-1/rules.d/10-wifimanagement.rules|<nowiki><br />
polkit.addRule(function(action, subject) {<br />
if (action.id == "org.freedesktop.systemd1.manage-units") {<br />
if (action.lookup("unit") == "wpa_supplicant.service") {<br />
var verb = action.lookup("verb");<br />
if (verb == "start" || verb == "stop" || verb == "restart") {<br />
return polkit.Result.YES;<br />
}<br />
}<br />
}<br />
});</nowiki><br />
}}<br />
<br />
== See also ==<br />
<br />
* [https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html Polkit manual page]<br />
* [https://doc.opensuse.org/documentation/leap/security/html/book-security/cha-security-policykit.html Authorization with PolKit] (openSUSE Leap Security guide)</div>Baerbeisserhttps://wiki.archlinux.org/index.php?title=XDG_Base_Directory&diff=774962XDG Base Directory2023-04-07T14:16:47Z<p>Baerbeisser: Seems like cups fixed this. https://github.com/OpenPrinting/cups/issues/10</p>
<hr />
<div>[[Category:Freedesktop.org]]<br />
[[Category:Configuration files]]<br />
[[Category:Development]]<br />
[[ja:XDG Base Directory]]<br />
[[pt:XDG Base Directory]]<br />
{{Related articles start}}<br />
{{Related|Dotfiles}}<br />
{{Related|XDG user directories}}<br />
{{Related articles end}}<br />
<br />
This article summarizes the [https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html XDG Base Directory specification] in [[#Specification]] and tracks software support in [[#Support]].<br />
<br />
== Specification ==<br />
<br />
Please read the [https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html full specification]. This section will attempt to break down the essence of what it tries to achieve.<br />
<br />
Only {{ic|XDG_RUNTIME_DIR}} is set by default through [https://www.freedesktop.org/software/systemd/man/pam_systemd.html pam_systemd]. It is up to the user to explicitly define the other variables according to the specification.<br />
<br />
See [[Environment variables#Globally]] for information on defining variables.<br />
<br />
=== User directories ===<br />
<br />
* {{ic|XDG_CONFIG_HOME}}<br />
** Where user-specific configurations should be written (analogous to {{ic|/etc}}).<br />
** Should default to {{ic|$HOME/.config}}.<br />
<br />
* {{ic|XDG_CACHE_HOME}}<br />
** Where user-specific non-essential (cached) data should be written (analogous to {{ic|/var/cache}}).<br />
** Should default to {{ic|$HOME/.cache}}.<br />
<br />
* {{ic|XDG_DATA_HOME}}<br />
** Where user-specific data files should be written (analogous to {{ic|/usr/share}}).<br />
** Should default to {{ic|$HOME/.local/share}}.<br />
<br />
* {{ic|XDG_STATE_HOME}}<br />
** Where user-specific state files should be written (analogous to {{ic|/var/lib}}).<br />
** Should default to {{ic|$HOME/.local/state}}.<br />
<br />
* {{ic|XDG_RUNTIME_DIR}}<br />
** Used for non-essential, user-specific data files such as sockets, named pipes, etc.<br />
** Not required to have a default value; warnings should be issued if not set or equivalents provided.<br />
** Must be owned by the user with an access mode of {{ic|0700}}.<br />
** Filesystem fully featured by standards of OS.<br />
** Must be on the local filesystem.<br />
** May be subject to periodic cleanup.<br />
** Modified every 6 hours or set sticky bit if persistence is desired.<br />
** Can only exist for the duration of the user's login.<br />
** Should not store large files as it may be mounted as a tmpfs.<br />
** pam_systemd sets this to {{ic|/run/user/$UID}}.<br />
<br />
=== System directories ===<br />
<br />
* {{ic|XDG_DATA_DIRS}}<br />
** List of directories separated by {{ic|:}} (analogous to {{ic|PATH}}).<br />
** Should default to {{ic|/usr/local/share:/usr/share}}.<br />
<br />
* {{ic|XDG_CONFIG_DIRS}}<br />
** List of directories separated by {{ic|:}} (analogous to {{ic|PATH}}).<br />
** Should default to {{ic|/etc/xdg}}.<br />
<br />
== Support ==<br />
<br />
{{Expansion|The current supported/partial/hardcoded split is not detailed enough and can be misleading. The tables could be merged into one (with more fields added on how the programs work with the specification) or differently named categories could be used.|section=Add description of support categories}}<br />
<br />
This section exists to catalog the growing set of software using the [https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html XDG Base Directory Specification] introduced in 2003.<br />
This is here to demonstrate the viability of this specification by listing commonly found dotfiles and their support status.<br />
For those not currently supporting the Base Directory Specification, workarounds will be demonstrated to emulate it instead.<br />
<br />
The workarounds will be limited to anything not involving patching the source, executing code stored in [[environment variables]] or compile-time options.<br />
The rationale for this is that configurations should be portable across systems and having compile-time options prevent that.<br />
<br />
Hopefully this will provide a source of information about exactly what certain kinds of dotfiles are and where they come from.<br />
<br />
=== Contributing ===<br />
<br />
When contributing make sure to use the correct section.<br />
<br />
Nothing should require code evaluation (such as [[vim]] and {{ic|VIMINIT}}), patches or compile-time options to gain support and anything which does must be deemed hardcoded.<br />
Additionally, if the process is error prone or difficult, it should also be classified as hardcoded.<br />
<br />
* The first column should be either a link to an internal article, a [[Template:Pkg]] or a [[Template:AUR]].<br />
* The second column is for any legacy files and directories the project had (one per line), this is done so people can find them even if they are no longer read.<br />
* In the third, try to find the commit or version a project switched to XDG Base Directory or any open discussions and include them in the next two columns (two per line).<br />
* The last column should include any appropriate workarounds or solutions. Please verify that your solution is correct and functional.<br />
<br />
=== Supported ===<br />
<br />
{| class="wikitable sortable" style="width: 100%"<br />
! Application<br />
! Legacy Path<br />
! Supported Since<br />
! Discussion<br />
! Notes<br />
|-<br />
| {{AUR|aerc-git}}<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| [[ALSA]]<br />
| {{ic|~/.asoundrc}}<br />
| [https://github.com/alsa-project/alsa-lib/commit/577df365f66ee09579864fc771136e690927b3bf 577df36]<br />
[https://github.com/alsa-project/alsa-lib/releases/tag/v1.2.3 1.2.3]<br />
| [https://github.com/alsa-project/alsa-lib/issues/49]<br />
| {{ic|XDG_CONFIG_HOME/alsa/asoundrc}}<br />
|-<br />
| {{AUR|anaconda}}<br />
| {{ic|~/.conda/.condarc}}, {{ic|~/.conda/condarc}}, {{ic|~/.conda/condarc.d/}}, {{ic|~/.condarc}}<br />
| [https://github.com/conda/conda/blob/main/CHANGELOG.md#4110-2021-11-22 4.11.0]<br />
| [https://conda.io/projects/conda/en/latest/user-guide/configuration/use-condarc.html#searching-for-condarc] [https://github.com/conda/conda/pull/10982]<br />
| Previous versions required setting variables in {{ic|condarc}}:<br />
{{hc|1=$XDG_CONFIG_HOME/conda/condarc|2=conda-build:<br />
# Replace /home/user/.local/share with your $XDG_DATA_HOME path, as the<br />
# `conda-build.root-dir` option does not support environment expansion<br />
root-dir: /home/user/.local/share/conda/conda-bld<br />
envs_dirs:<br />
- ${XDG_DATA_HOME}/conda/envs<br />
pkgs_dirs:<br />
- ${XDG_CACHE_HOME}/conda/pkgs}}<br />
|-<br />
| [https://developer.android.com/studio/index.html Android Studio]<br />
| {{ic|~/.AndroidStudioX.X}}<br />
| [https://developer.android.com/studio/intro/studio-config#file_location Android Studio 4.1]<br />
|<br />
|<br />
XDG_CONFIG_HOME/Google/AndroidStudioX.X<br />
XDG_DATA_HOME/Google/AndroidStudioX.X<br />
XDG_CACHE_HOME/Google/AndroidStudioX.X<br />
[https://developer.android.com/studio/intro/studio-config#file_location Location overview by Google] does not mention XDG - paths could be hardcoded instead of using the proper variable, though that is unlikely as Intellij IDEA, which Android Studio is based on, implements it properly as well<br />
|-<br />
| [[Anki]]<br />
| {{ic|~/Anki}}, {{ic|~/Documents/Anki}}<br />
|<br />
| [https://github.com/dae/anki/pull/49] [https://github.com/dae/anki/pull/58] [https://docs.ankiweb.net/files.html]<br />
| Uses {{ic|$XDG_DATA_HOME/Anki2}} as default if no older location exists, can be changed by using {{ic|1=anki -b <anki_dir>}}<br />
|-<br />
| {{AUR|antimicrox}}<br />
| {{ic|~/.antimicro}}, {{ic|~/.antimicrox}}<br />
| [https://github.com/Antimicrox/antimicrox/commit/edba864 edba864]<br />
| [https://github.com/Antimicro/antimicro/issues/5]<br />
| <br />
|-<br />
| {{Aur|apvlv}}<br />
| {{ic|~/.apvlvrc}}<br />
| [https://github.com/naihe2010/apvlv/commit/ed0e0112b05b0cafa13ca4e215ee559c82194caf]<br />
| [https://github.com/naihe2010/apvlv/issues/70]<br />
| Uses {{ic|XDG_CONFIG_HOME/apvlv/apvlvrc}} now if it exist.<br />
|-<br />
| [[aria2]]<br />
| {{ic|~/.aria2}}<br />
| [https://github.com/tatsuhiro-t/aria2/commit/8bc1d37 8bc1d37]<br />
| [https://github.com/tatsuhiro-t/aria2/issues/27]<br />
|<br />
XDG_CONFIG_HOME/aria2/<br />
XDG_CACHE_HOME/aria2/<br />
|-<br />
| {{Pkg|asunder}}<br />
| {{ic|~/.asunder}} {{ic|~/.asunder_album_artist}} {{ic|~/.asunder_album_genre}} {{ic|~/.asunder_album_title}}<br />
| [https://littlesvr.ca/bugs/show_bug.cgi?id=31 2.9.0]{{Dead link|2021|05|17|status=SSL error}}<br />
| [https://littlesvr.ca/bugs/show_bug.cgi?id=52]{{Dead link|2021|05|17|status=SSL error}}<br />
| Uses {{ic|XDG_CONFIG_HOME/asunder/asunder}} for {{ic|~/.asunder}} and {{ic|XDG_CACHE_HOME/asunder/asunder_album_...}} for the other 3 files. Legacy paths are not removed after migration, they have to be deleted manually.<br />
|-<br />
| {{Pkg|audacity}}<br />
| {{ic|~/.audacity-data/}}<br />
| [https://github.com/audacity/audacity/releases/tag/Audacity-3.2.0 3.2.0]<br />
| [https://bugzilla.audacityteam.org/show_bug.cgi?id=2201]<br />
|<br />
XDG_CONFIG_HOME/audacity<br />
XDG_DATA_HOME/audacity<br />
|-<br />
| {{Pkg|binwalk}}<br />
| {{ic|~/.binwalk}}<br />
| [https://github.com/ReFirmLabs/binwalk/commit/2051757 2051757]<br />
| [https://github.com/ReFirmLabs/binwalk/issues/216]<br />
| {{ic|XDG_CONFIG_HOME/binwalk}}<br />
|-<br />
| {{Pkg|bitwarden-cli}}<br />
| {{ic|~/.config/Bitwarden CLI}}<br />
| [https://github.com/bitwarden/cli/releases/tag/v1.7.1 1.7.1]<br />
| [https://github.com/bitwarden/cli/pull/46]<br />
|<br />
XDG_CONFIG_HOME/Bitwarden CLI<br />
XDG_DATA_HOME/audacity<br />
<br />
The {{ic|BITWARDENCLI_APPDATA_DIR}} environment variable takes precedence.<br />
<br />
Currently contains a single {{ic|data.json}} file with all the vault data, so it ought to belong in {{ic|XDG_DATA_HOME}}<br />
|-<br />
| [[Blender]]<br />
| {{ic|~/.blender}}<br />
| [https://git.blender.org/gitweb/gitweb.cgi/blender.git/commit/4293f47 4293f47]<br />
| [https://developer.blender.org/T28943]<br />
|<br />
|- <br />
| {{Pkg|byobu}}<br />
| {{ic|~/.byobu}}<br />
| [https://launchpad.net/byobu/+milestone/4.17 4.17]<br />
| [https://bugs.launchpad.net/byobu/+bug/553105]<br />
| <br />
{{ic|XDG_CONFIG_HOME/byobu}}<br />
<br />
Legacy path takes precedence if present, or if {{ic|XDG_CONFIG_HOME}} is ''not'' set.<br />
|-<br />
| [https://www.haskell.org/cabal cabal]<br />
| {{ic|~/.cabal/}}<br />
| [https://github.com/haskell/cabal/commit/9f7dc55 9f7dc55]<br />
| [https://github.com/haskell/cabal/issues/680]<br />
|<br />
|-<br />
| {{Pkg|calcurse}}<br />
| {{ic|~/.calcurse}}<br />
| [https://github.com/lfos/calcurse/commit/04162d 04162d]<br />
| [https://github.com/lfos/calcurse/pull/254] [https://github.com/lfos/calcurse/issues/252]<br />
|<br />
XDG_CONFIG_HOME/calcurse<br />
XDG_DATA_HOME/calcurse<br />
<br />
If the legacy path {{ic|~/.calcurse}} is present, it will take precedence.<br />
|-<br />
| {{Pkg|calibre}}<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| {{Pkg|ccache}}<br />
| {{ic|~/.ccache}}<br />
| [https://ccache.dev/releasenotes.html#_ccache_4_0 4.0]<br />
| [https://github.com/ccache/ccache/issues/191]<br />
|<br />
XDG_CACHE_HOME/ccache<br />
XDG_CONFIG_HOME/ccache/ccache.conf<br />
|-<br />
| {{AUR|citra-git}}<br />
| {{ic|~/.citra-emu}}<br />
| [https://github.com/citra-emu/citra/commit/f7c3193 f7c3193]<br />
| [https://github.com/citra-emu/citra/pull/575]<br />
|<br />
|-<br />
| [https://clangd.llvm.org/config.html clangd]<br />
| {{ic|~/.clangd}}<br />
| [https://github.com/JohnHolmesII/llvm-project/commit/fdf7dcc fdf7dcc]{{Dead link|2022|09|23|status=404}}<br />
| [https://github.com/clangd/clangd/issues/341]<br />
| {{ic|XDG_CONFIG_HOME/clangd/config.yml}}<br />
<br />
{{ic|XDG_CACHE_HOME/clangd}}<br />
<br />
Project specific configuration can be specified in {{ic|proj/.clangd}}.<br />
Configuration is combined when this is sensible. In case of conflicts, user config has the highest precedence, then inner project, then outer project.<br />
|-<br />
| [[Composer]]<br />
| {{ic|~/.composer}}<br />
| [https://github.com/composer/composer/releases/tag/1.0.0-beta1 1.0.0-beta1]<br />
| [https://github.com/composer/composer/pull/1407]<br />
|<br />
|-<br />
| [[cURL]]<br />
| {{ic|~/.curlrc}}<br />
| [https://curl.se/changes.html#7_73_0 7.73.0]<br />
| [https://github.com/curl/curl/issues/5829]<br />
| {{ic|XDG_CONFIG_HOME/.curlrc}}<br />
|-<br />
| {{Pkg|d-feet}}<br />
| {{ic|~/.d-feet}}<br />
| [https://gitlab.gnome.org/GNOME/d-feet/commit/7f6104b 7f6104b]<br />
|<br />
|<br />
|-<br />
| {{Pkg|dconf}}<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| [[Dolphin emulator]]<br />
| {{ic|~/.dolphin-emu}}<br />
| [https://github.com/dolphin-emu/dolphin/commit/a498c68 a498c68]<br />
| [https://github.com/dolphin-emu/dolphin/pull/2304]<br />
|<br />
|-<br />
| {{AUR|dr14_tmeter}}<br />
|<br />
| [https://github.com/simon-r/dr14_t.meter/commit/7e777ca 7e777ca]<br />
| [https://github.com/simon-r/dr14_t.meter/pull/30]<br />
| {{ic|XDG_CONFIG_HOME/dr14tmeter/}}<br />
|-<br />
| {{Pkg|dunst}}<br />
|<br />
| [https://github.com/dunst-project/dunst/commit/78b6e2b 78b6e2b]<br />
| [https://github.com/dunst-project/dunst/issues/22]<br />
| {{ic|XDG_CONFIG_HOME/dunst/}}<br />
|-<br />
| [[Emacs]]<br />
| {{ic|~/.emacs}} {{ic|~/.emacs.d/init.el}}<br />
| [https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=4118297ae2fab4886b20d193ba511a229637aea3]<br />
[https://www.gnu.org/savannah-checkouts/gnu/emacs/emacs.html#Releases 27.1]<br />
|<br />
| {{ic|XDG_CONFIG_HOME/emacs/init.el}}<br />
Legacy paths have precedence over XDG paths. Emacs will never create {{ic|XDG_CONFIG_HOME/emacs/}}.<br />
Workaround for 26.3 or older: It's possible to set {{ic|HOME}}, but it has unexpected side effects.<br />
|-<br />
| [[fish]]<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| {{Pkg|fltk}}<br />
| {{ic|~/.fltk/}}<br />
| [https://github.com/fltk/fltk/commit/7308bcdb74e34626c6459699cb57371afd7b343b 7308bcd]<br />
| [https://www.fltk.org/str.php?L3370+P0+S0+C0+I0+E0+V%25+Qxdg] [https://github.com/fltk/fltk/issues/79]<br />
| Only supported in version 1.4.0, which hasn't been released yet (as of 9-July-2022)<br />
|-<br />
| [[fontconfig]]<br />
| {{ic|~/.fontconfig}} {{ic|~/.fonts}}<br />
| [https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commit/8c255fb 8c255fb], [https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commit/437f03299bd1adc9673cd576072f1657be8fd4e0]<br />
|<br />
| Config goes in {{ic|XDG_CONFIG_HOME/fontconfig/fonts.conf}} or {{ic|XDG_CONFIG_HOME/fontconfig/conf.d/}}, fonts are stored in {{ic|XDG_DATA_HOME/fonts/}}<br />
|-<br />
| {{Pkg|fontforge}}<br />
| {{ic|~/.FontForge}} {{ic|~/.PfaEdit}}<br />
| [https://github.com/fontforge/fontforge/commit/e4c2cc7 e4c2cc7]<br />
|<br />
[https://github.com/fontforge/fontforge/issues/847]<br />
[https://github.com/fontforge/fontforge/issues/991]<br />
|<br />
|-<br />
| {{Pkg|freecad}}<br />
| {{ic|~/.FreeCAD}}<br />
| [https://github.com/FreeCAD/FreeCAD/commit/e7e2994ba e7e2994ba]<br />
[https://github.com/FreeCAD/FreeCAD/releases/tag/0.20 0.20.0]<br />
| [https://forum.freecad.org/viewtopic.php?f=9&t=63648]<br />
| Defaults to<br />
XDG_CONFIG_HOME/FreeCAD<br />
XDG_DATA_HOME/FreeCAD<br />
XDG_CACHE_HOME/FreeCAD<br />
legacy path can be used with {{ic|FreeCAD --keep-deprecated-paths}}<br />
|-<br />
| {{Pkg|freerdp}}<br />
| {{ic|~/.freerdp}}<br />
| [https://github.com/FreeRDP/FreeRDP/commit/edf6e72 edf6e72]<br />
|<br />
|<br />
|-<br />
| [[Gajim]]<br />
| {{ic|~/.gajim}}<br />
| [https://dev.gajim.org/gajim/gajim/commit/3e777ea 3e777ea]<br />
| [https://dev.gajim.org/gajim/gajim/issues/2149]<br />
|<br />
|-<br />
| {{AUR|gconf}}<br />
| {{ic|~/.gconf}}<br />
| [https://gitlab.gnome.org/Archive/gconf/commit/fc28caa fc28caa]<br />
| [https://bugzilla.gnome.org/show_bug.cgi?id=674803]<br />
|-<br />
| [[GDB]]<br />
| {{ic|~/.gdbinit}}, {{ic|~/.gdb_history}}<br />
| [https://lists.gnu.org/archive/html/info-gnu/2021-09/msg00007.html 11.1]<br />
|<br />
| {{ic|XDG_CONFIG_HOME/gdb/gdbinit}}, {{ic|1=export GDBHISTFILE="$XDG_DATA_HOME"/gdb/history}}<br />
|-<br />
| [[GIMP]]<br />
| {{ic|~/.gimp-x.y}} {{ic|~/.thumbnails}}<br />
|<br />
[https://gitlab.gnome.org/GNOME/gimp/commit/60e0cfe 60e0cfe]<br />
[https://gitlab.gnome.org/GNOME/gimp/commit/483505f 483505f]<br />
|<br />
[https://bugzilla.gnome.org/show_bug.cgi?id=166643]<br />
[https://bugzilla.gnome.org/show_bug.cgi?id=646644]<br />
|<br />
|-<br />
| [[Git]]<br />
| {{ic|~/.gitconfig}}<br />
| [https://github.com/git/git/commit/0d94427 0d94427]<br />
|<br />
| {{ic|XDG_CONFIG_HOME/git/config}}<br />
|-<br />
| [https://github.com/google/gops gops]<br />
|<br />
| [https://github.com/google/gops/commit/71c4255 71c4255]<br />
|<br />
|<br />
|-<br />
| [[Wikipedia:gnuplot|gnuplot]]<br />
| {{ic|~/.gnuplot_history}}<br />
| [https://sourceforge.net/p/gnuplot/gnuplot-main/ci/a5562b1/ a5562b1]<br />
[https://sourceforge.net/p/gnuplot/gnuplot-main/merge-requests/12/]<br />
|<br />
|<br />
|-<br />
| {{AUR|goobook}}<br />
| {{ic|~/.goobookrc}}<br />
| [https://gitlab.com/goobook/goobook/-/blob/master/CHANGES.rst 3.5]<br />
| [https://gitlab.com/goobook/goobook/-/merge_requests/11]<br />
| {{ic|XDG_CONFIG_HOME/goobookrc}}<br />
|-<br />
| [[Godot Engine]]<br />
| {{ic|~/.godot}}<br />
| [https://github.com/godotengine/godot/pull/12988/commits/73049d115e190b8c356f0689a9079c3c73cc5765 73049d1]<br />
[https://github.com/godotengine/godot/releases/tag/3.0-stable 3.0-stable]<br />
| [https://github.com/godotengine/godot/issues/3513]<br />
|<br />
|-<br />
| [[GStreamer]]<br />
| {{ic|~/.gstreamer-0.10}}<br />
| [https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/4e36f93 4e36f93]<br />
| [https://bugzilla.gnome.org/show_bug.cgi?id=518597]<br />
|<br />
|-<br />
| [[GTK]] 3<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| {{Pkg|helm}}<br />
| {{ic|~/.helm}}<br />
| [https://github.com/helm/helm/releases/tag/v3.0.0 3.0.0]<br />
|<br />
|<br />
|-<br />
| {{Pkg|htop}}<br />
| {{ic|~/.htoprc}}<br />
| [https://github.com/hishamhm/htop/commit/93233a6 93233a6]<br />
|<br />
|<br />
|-<br />
| {{Pkg|httpie}}<br />
| {{ic|~/.httpie}}<br />
| [https://github.com/httpie/httpie/commit/5af0874ed302e9ef79cec97836529ccf353e53f7 5af0874]<br />
| [https://github.com/httpie/httpie/issues/145]<br />
|<br />
|-<br />
| [[i3]]<br />
| {{ic|~/.i3}}<br />
| [http://code.stapelberg.de/git/i3/commit/?id=7c130fb 7c130fb]<br />
|<br />
|<br />
|-<br />
| {{Pkg|i3blocks}}, {{AUR|i3blocks-git}}<br />
|<br />
| [https://github.com/vivien/i3blocks/commit/a1782404c7d933145b048d0d1872ea40d7a293b6]<br />
|<br />
|<br />
|-<br />
| [https://archlinux.org/packages/?name=i3-gaps i3-gaps]<br />
|<br />
| [https://github.com/Airblader/i3/commit/7c130fb540da378c4ba3744d2ff39983df3ad705]<br />
|<br />
|<br />
|-<br />
| {{Pkg|i3status}}<br />
| {{ic|~/.i3status.conf}}<br />
| [http://code.stapelberg.de/git/i3status/commit/?id=c3f7fc4 c3f7fc4]<br />
|<br />
|<br />
|-<br />
| {{Pkg|i3status-rust}}<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| [https://github.com/JetBrains/ideavim IdeaVim]<br />
| {{ic|~/.ideavimrc}}<br />
| [https://github.com/JetBrains/ideavim/pull/212 0.54.1-EAP]<br />
| [https://youtrack.jetbrains.com/issue/VIM-664]<br />
| {{ic|XDG_CONFIG_HOME/ideavim/ideavimrc}}<br />
|-<br />
| {{Pkg|imagemagick}}<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| [[Inkscape]]<br />
| {{ic|~/.inkscape}}<br />
| [https://wiki.inkscape.org/wiki/index.php/Release_notes/0.47#Preferences 0.47]<br />
| [https://bugs.launchpad.net/inkscape/+bug/199720]<br />
|<br />
|-<br />
| [http://ipython.org ipython]<br />
| {{ic|~/.ipython}}<br />
| [https://ipython.readthedocs.io/en/stable/whatsnew/version8.html#re-added-support-for-xdg-config-directories 8.0.0]<br />
| [https://github.com/ipython/ipython/pull/13224]<br />
| The default dotfile path is still $HOME but xdg directories (or ~/.config/ipython if XDG_* vars are unset) are supported and work correctly.<br />
|-<br />
| [https://iwd.wiki.kernel.org/ iwd] / iwctl<br />
| {{ic|~/.iwctl_history}}<br />
| [https://git.kernel.org/pub/scm/network/wireless/iwd.git/commit/?id=d3e00d7f d3e00d7f]<br />
|<br />
|<br />
|-<br />
| {{Pkg|intellij-idea-community-edition}} / {{AUR|intellij-idea-ultimate-edition}}<br />
| {{ic|~/.IntelliJIdeaXXXX.X}}<br />
| [https://confluence.jetbrains.com/display/IDEADEV/IntelliJ%2BIDEA%2B2020.1%2B%28201.6668.121%2Bbuild%29%2BRelease%2BNotes 2020.1]<br />
| [https://youtrack.jetbrains.com/issue/IDEA-22407]<br />
|<br />
XDG_CONFIG_HOME/JetBrains/IntelliJIdeaXXXX.X<br />
XDG_DATA_HOME/JetBrains/IntelliJIdeaXXXX.X<br />
XDG_CACHE_HOME/JetBrains/IntelliJIdeaXXXX.X<br />
|-<br />
| {{Pkg|josm}}<br />
| {{ic|~/.josm}}<br />
| [https://josm.openstreetmap.de/changeset/11162/josm 11162]<br />
| [https://josm.openstreetmap.de/ticket/6664]<br />
|<br />
|-<br />
| [https://github.com/jupyter jupyter]<br />
| {{ic|~/.jupyter}}<br />
| opt-in in 5.0, opt-out in 6.0, compulsory in 7.0 ([https://github.com/jupyter/jupyter_core/blob/f5ab1ac19225c7925282e9c5ae466767b4086361/CHANGELOG.md#migrate-to-standard-platform-directories changelog])<br />
| <br />
| {{ic|XDG_CONFIG_HOME/jupyter}}<br />
|-<br />
| [[Kakoune]]<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| {{AUR|keynav}}<br />
| {{ic|~/.keynavrc}}<br />
|<br />
|<br />
| {{ic|XDG_CONFIG_HOME/keynav/keynavrc}}<br />
|-<br />
| [[Core utilities|less]]<br />
| {{ic|~/.lesshst}}, {{ic|~/.lesskey}}<br />
| [https://www.greenwoodsoftware.com/less/news.590.html 590]<br />
full support in [https://www.greenwoodsoftware.com/less/news.600.html 600]<br />
| [https://github.com/gwsw/less/issues/153]<br />
| The environment variables {{ic|XDG_CONFIG_HOME}} and {{ic|XDG_DATA_HOME}} '''must''' be set in version 590. This is no longer necessary when version 600 lands.<br />
|-<br />
| latexmk (in {{Pkg|texlive-core}})<br />
| {{ic|~/.latexmkrc}}<br />
|<br />
|<br />
|<br />
{{ic|XDG_CONFIG_HOME/latexmk/latexmkrc}}<br />
|-<br />
| {{Pkg|lftp}}<br />
| {{ic|~/.lftp}}<br />
| [https://github.com/lavv17/lftp/commit/21dc400 21dc400]<br />
| [https://www.mail-archive.com/lftp@uniyar.ac.ru/msg04301.html]<br />
|<br />
|-<br />
| {{AUR|lgogdownloader}}<br />
| {{ic|~/.gogdownloader}}<br />
| [https://github.com/Sude-/lgogdownloader/commit/d430af6 d430af6]<br />
| [https://github.com/Sude-/lgogdownloader/issues/4]<br />
|<br />
|-<br />
| [[LibreOffice]]<br />
|<br />
|<br />
[https://cgit.freedesktop.org/libreoffice/ure/commit/?id=a6f56f7 a6f56f7]<br />
[https://cgit.freedesktop.org/libreoffice/bootstrap/commit/?id=25bd2ee 25bd2ee]<br />
| [https://bugs.documentfoundation.org/show_bug.cgi?id=32263]<br />
|<br />
|-<br />
| {{Pkg|luarocks}}<br />
| {{ic|~/.luarocks}}<br />
| [https://github.com/luarocks/luarocks/pull/1298/commits/cd16cdd5f889024f28cc384e3d721a4f4a3261d3 cd16cdd]<br />
| [https://github.com/luarocks/luarocks/pull/1298]<br />
|<br />
XDG_CONFIG_HOME/luarocks<br />
XDG_CACHE_HOME/luarocks<br />
<br />
If the legacy path {{ic|~/.luarocks}} is present, it will take precedence.<br />
|-<br />
| [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS]<br />
| {{ic|~/.pki}}<br />
| [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.42_release_notes 3.42]<br />
| [https://bugzilla.mozilla.org/show_bug.cgi?id=818686]<br />
|<br />
|-<br />
| [[Streamlink]]<br />
| {{ic|~/.livestreamerrc}}<br />
| [https://github.com/chrippa/livestreamer/commit/ea80591 ea80591]<br />
| [https://github.com/chrippa/livestreamer/pull/106]<br />
|<br />
|-<br />
| [[mc]]<br />
| {{ic|~/.mc}}<br />
|<br />
[https://github.com/MidnightCommander/mc/commit/1b99570 1b99570]<br />
[https://github.com/MidnightCommander/mc/commit/0b71156 0b71156]<br />
[https://github.com/MidnightCommander/mc/commit/ce401d7 ce401d7]<br />
| [https://www.midnight-commander.org/ticket/1851]<br />
|<br />
|-<br />
| [[Mercurial]]<br />
| {{ic|~/.hgrc}}<br />
|<br />
[https://www.mercurial-scm.org/repo/hg/rev/3540200 3540200]<br />
[https://www.mercurial-scm.org/wiki/Release4.2 4.2]<br />
|<br />
| {{ic|XDG_CONFIG_HOME/hg/hgrc}}.<br />
|-<br />
| [[msmtp]]<br />
| {{ic|~/.msmtprc}}<br />
|<br />
[https://github.com/marlam/msmtp-mirror/commit/af2f409 af2f409]<br />
v1.6.7+<br />
|<br />
| {{ic| XDG_CONFIG_HOME/msmtp/config}}.<br />
|-<br />
| {{Pkg|mesa}}<br />
|<br />
| [https://gitlab.freedesktop.org/mesa/mesa/-/commit/87ab26b 87ab26b]<br />
|<br />
| {{ic|XDG_CACHE_HOME/mesa}}<br />
|-<br />
| {{Pkg|milkytracker}}<br />
| {{ic|~/.milkytracker_config}}<br />
| [https://github.com/Deltafire/MilkyTracker/commit/eb487c5 eb487c5]<br />
| [https://github.com/Deltafire/MilkyTracker/issues/12]<br />
|<br />
|-<br />
| [[mozc]]<br />
| {{ic|~/.mozc}}<br />
| [https://github.com/google/mozc/commit/91cc1e19ef34aeb12888b697fefa52907f1a834d 91cc1e1]<br />
| [https://github.com/google/mozc/issues/474]<br />
|<br />
|-<br />
| [[mpd]]<br />
| {{ic|~/.mpdconf}}<br />
| [https://github.com/MusicPlayerDaemon/MPD/commit/87b7328 87b7328]<br />
|<br />
|<br />
|-<br />
| [[mpv]]<br />
| {{ic|~/.mpv}}<br />
| [https://github.com/mpv-player/mpv/commit/cb250d4 cb250d4]<br />
| [https://github.com/mpv-player/mpv/pull/864]<br />
|<br />
|-<br />
| [[mutt]]<br />
| {{ic|~/.mutt}}<br />
| [https://gitlab.com/muttmua/mutt/commit/b17cd67 b17cd67]<br />
| [https://gitlab.com/muttmua/trac-tickets/raw/master/tickets/closed/3207-Conform_to_XDG_Base_Directory_Specification.txt]<br />
|<br />
|-<br />
| {{Pkg|mypaint}}<br />
| {{ic|~/.mypaint}}<br />
| [https://github.com/mypaint/mypaint/commit/cf723b7 cf723b7]<br />
|<br />
|<br />
|-<br />
| [[nano]]<br />
| {{ic|~/.nano/}} {{ic|~/.nanorc}}<br />
| [https://git.savannah.gnu.org/cgit/nano.git/commit/?id=c16e79b c16e79b]<br />
| [https://savannah.gnu.org/patch/?8523]<br />
|<br />
|-<br />
| [[ncmpcpp]]<br />
| {{ic|~/.ncmpcpp}}<br />
|<br />
[https://github.com/arybczak/ncmpcpp/commit/38d9f81 38d9f81]<br />
[https://github.com/arybczak/ncmpcpp/commit/27cd86e 27cd86e]<br />
|<br />
[https://github.com/arybczak/ncmpcpp/issues/79]<br />
[https://github.com/arybczak/ncmpcpp/issues/110]<br />
| {{ic|ncmpcpp_directory}} should be set to avoid an {{ic|error.log}} file in {{ic|~/.ncmpcpp}}.<br />
|-<br />
| [[Neovim]]<br />
| {{ic|~/.nvim}} {{ic|~/.nvimlog}} {{ic|~/.nviminfo}}<br />
| [https://github.com/neovim/neovim/commit/1ca5646 1ca5646]<br />
|<br />
[https://github.com/neovim/neovim/issues/78]<br />
[https://github.com/neovim/neovim/pull/3198]<br />
|<br />
|-<br />
| [http://0ldsk00l.ca/nestopia/ Nestopia UE]<br />
| {{ic|~/.nestopia/}}<br />
| [https://github.com/0ldsk00l/nestopia/commit/d78381198a26a10333128e9bf28bc530a610c008 610c008] [https://github.com/0ldsk00l/nestopia/releases/tag/1.51.0 1.51.0]<br />
| [https://github.com/0ldsk00l/nestopia/issues/343]<br />
|<br />
|-<br />
| [[newsboat]]<br />
| {{ic|~/.newsboat}}<br />
| [https://github.com/akrennmair/newsbeuter/commit/3c57824 3c57824]<br />
| [https://github.com/akrennmair/newsbeuter/pull/39]<br />
| It is required to create both directories [https://man.archlinux.org/man/newsboat.1#FILES]:<br />
<br />
{{ic|1=mkdir -p "$XDG_DATA_HOME"/newsboat "$XDG_CONFIG_HOME"/newsboat}}<br />
|-<br />
| [https://github.com/nodejs/node-gyp node-gyp]<br />
| {{ic|~/.node-gyp}}<br />
| [https://github.com/nodejs/node-gyp/commit/2b5ce52a 2b5ce52a]<br />
| [https://github.com/nodejs/node-gyp/pull/1570]<br />
|<br />
|-<br />
| {{AUR|np2kai-git}}<br />
| {{ic|~/.config/np2kai}} {{ic|~/.config/xnp2kai}}<br />
| [https://github.com/AZO234/NP2kai/commit/56a1cc2 56a1cc2]<br />
| [https://github.com/AZO234/NP2kai/pull/50]<br />
|<br />
|-<br />
| [[notmuch]]<br />
| {{ic|~/.notmuch-config}}<br />
|<br />
| [https://notmuchmail.org/pipermail/notmuch/2011/007007.html]<br />
| {{ic|mkdir -p $XDG_CONFIG_HOME/notmuch/default; mv ~/.notmuch-config $XDG_CONFIG_HOME/notmuch/default/config}}<br />
|-<br />
| {{AUR|nteract-bin}}<br />
|<br />
| [https://github.com/nteract/nteract/commit/4593e72 4593e72]<br />
| [https://github.com/nteract/nteract/issues/180] [https://github.com/nteract/nteract/pull/3870]<br />
| [https://github.com/nteract/nteract/issues/4517 does not recognize workarounds for ipython/jupyter]<br />
|-<br />
| [[OfflineIMAP]]<br />
| {{ic|~/.offlineimaprc}}<br />
| [https://github.com/OfflineIMAP/offlineimap/commit/5150de5 5150de5]<br />
| [https://github.com/OfflineIMAP/offlineimap/issues/32]<br />
| {{ic|XDG_CONFIG_HOME/offlineimap/config}}<br />
|-<br />
| {{pkg|openal}}<br />
| {{ic|~/.alsoftrc}}<br />
| [https://github.com/kcat/openal-soft/commit/3c90ed95afa1feed70e6c5655cfeec096c00c23b 3c90ed9]<br />
| <br />
| {{ic|XDG_CONFIG_HOME/alsoft.conf}}<br />
|-<br />
| {{AUR|opentyrian}}<br />
| {{ic|~/.opentyrian}}<br />
| [https://github.com/opentyrian/opentyrian/commit/39559c3 39559c3]<br />
| [https://web.archive.org/web/20140815181350/http://code.google.com/p/opentyrian/issues/detail?id=125]<br />
|<br />
|-<br />
| {{AUR|osc}}<br />
| {{ic|~/.oscrc}} {{ic|~/.osc_cookiejar}} <br />
| [https://github.com/openSUSE/osc/commit/6bc2d3f939c2518ae555fbf75e3a11cc16fc5302 6bc2d3f]<br />
[https://github.com/openSUSE/osc/commit/ebcf3de6abe1ae142baa5bee4c9867cc1968bad1 ebcf3de]<br />
|[https://github.com/openSUSE/osc/pull/940 github.com/openSUSE/osc/pull/940]<br />
[https://github.com/openSUSE/osc/pull/940 github.com/osc/pull/940]<br />
|<br />
{{ic|XDG_CONFIG_HOME/osc/oscrc}}<br />
{{ic|XDG_STATE_HOME/osc/cookiejar}}<br />
<br />
Legacy path takes precedence if it exists<br />
|-<br />
| {{Pkg|pam-u2f}}<br />
| {{ic|~/.config/Yubico/u2f_keys}}<br />
| [https://github.com/Yubico/pam-u2f/commit/ad52dd82dead525dab94ded1916dcf6334459106 ad52dd8]<br />
| [https://github.com/Yubico/pam-u2f/issues/9]<br />
| {{ic|XDG_CONFIG_HOME/Yubico/u2f_keys}}<br />
|-<br />
| {{Pkg|pandoc-cli}}<br />
| {{ic|~/.pandoc/}}<br />
| [https://github.com/jgm/pandoc/commit/0bed0ab5a308f5e72a01fa9bee76488556288862 0bed0ab]<br />
| [https://github.com/jgm/pandoc/issues/3582]<br />
|<br />
|-<br />
| [[PCManFM]]<br />
| {{ic|~/.thumbnails}}<br />
| [https://github.com/lxde/libfm/issues/57 1.3.2]<br />
|<br />
|<br />
|-<br />
| {{AUR|pcsx2}}<br />
| {{ic|~/.pcsx2}}<br />
|<br />
[https://github.com/PCSX2/pcsx2/commit/87f1e8f 87f1e8f]<br />
[https://github.com/PCSX2/pcsx2/commit/a9020c6 a9020c6]<br />
[https://github.com/PCSX2/pcsx2/commit/3b22f0f 3b22f0f]<br />
[https://github.com/PCSX2/pcsx2/commit/0a012ae 0a012ae]<br />
| [https://github.com/PCSX2/pcsx2/issues/352] [https://github.com/PCSX2/pcsx2/issues/381]<br />
| <br />
|-<br />
| {{AUR|pdfsam}}<br />
| {{ic|~/.openjfx}}<br />
|<br />
|<br />
| {{ic|1=export _JAVA_OPTIONS=-Djavafx.cachedir="$XDG_CACHE_HOME"/openjfx}}<br />
|-<br />
| [https://pry.github.io/ Pry]<br />
| {{ic|~/.pryrc}} {{ic|~/.pry_history}}<br />
|<br />
[https://github.com/pry/pry/commit/a0be0cc7b2070edff61c0c7f10fa37fce9b730bd a0be0cc7]<br />
[https://github.com/pry/pry/commit/15e1fc929ed84c161abc5afc9be73488a41df397 15e1fc92]<br />
[https://github.com/pry/pry/commit/e9d1be0e17b294318dbb2f70f74a50486cfa044c e9d1be0e]<br />
| [https://github.com/pry/pry/issues/1316]<br />
|<br />
|-<br />
| {{AUR|python-autoimport}}<br />
| {{ic|~/.config/autoimport/config.toml}}<br />
| [https://github.com/lyz-code/autoimport/pull/206 1.2.0]<br />
| [https://github.com/lyz-code/autoimport/pull/172]<br />
| {{ic|XDG_CONFIG_HOME/autoimport/config.toml}}<br />
|-<br />
| {{Pkg|python-black}}<br />
| {{ic|~/.config/black}}<br />
| [https://github.com/psf/black/pull/1899 21.4b0]<br />
| [https://github.com/psf/black/issues/1577]<br />
| {{ic|XDG_CONFIG_HOME/black}}, {{ic|XDG_CACHE_HOME/black/<version>/}}<br />
|-<br />
| {{Pkg|python-pylint}}<br />
| {{ic|~/.pylint.d}}<br />
| [https://github.com/PyCQA/pylint/pull/4661 2.10]<br />
| [https://github.com/PyCQA/pylint/issues/1364]<br />
| Formerly {{ic|1=export PYLINTHOME="$XDG_CACHE_HOME"/pylint}}, global config still needs: {{ic|1=export PYLINTRC="$XDG_CONFIG_HOME"/pylint/pylintrc}}<br />
|-<br />
| {{Pkg|python-pip}}<br />
| {{ic|~/.pip}}<br />
| [https://github.com/pypa/pip/blob/548a9136525815dff41acd845c558a0b36eb1c5f/NEWS.rst#60-2014-12-22 6.0]<br />
| [https://github.com/pypa/pip/issues/1733]<br />
|<br />
|-<br />
| {{Pkg|python-poetry}}<br />
| {{ic|~/.poetry}}<br />
| [https://github.com/python-poetry/poetry/pull/3706]<br />
| [https://github.com/python-poetry/poetry/issues/2148]<br />
| Still creates {{ic|~/.poetry}} according to [https://github.com/python-poetry/poetry/issues/2148#issuecomment-943951697]<br />
|-<br />
| {{AUR|powershell}}<br />
|<br />
| [https://docs.microsoft.com/en-us/powershell/scripting/whats-new/what-s-new-in-powershell-core-60#filesystem 6.0]<br />
|<br />
|<br />
|-<br />
| {{Pkg|ppsspp}}<br />
| {{ic|~/.ppsspp}}<br />
| [https://github.com/hrydgard/ppsspp/commit/132fe47 132fe47]<br />
| [https://github.com/hrydgard/ppsspp/issues/4623]<br />
|<br />
|-<br />
| {{Pkg|procps-ng}}<br />
| {{ic|~/.toprc}}<br />
| [https://gitlab.com/procps-ng/procps/commit/af53e17 af53e17]<br />
|<br />
[https://gitlab.com/procps-ng/procps/merge_requests/38]<br />
[https://bugzilla.redhat.com/show_bug.cgi?id=1155265]<br />
|<br />
|-<br />
| [[pacman]]<br />
| {{ic|~/.makepkg.conf}}<br />
| [https://gitlab.archlinux.org/pacman/pacman/commit/80eca94 80eca94]<br />
| [https://lists.archlinux.org/archives/list/pacman-dev@lists.archlinux.org/thread/KTD2FW7YKY724UB7PT3GGP5L7TNWZYEP/]<br />
|<br />
|-<br />
| {{AUR|panda3d}}<br />
| {{ic|~/.panda3d}}<br />
| [https://github.com/panda3d/panda3d/commit/2b537d2 2b537d2]<br />
|<br />
|<br />
|-<br />
| {{AUR|poezio}}<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| [[PulseAudio]]<br />
| {{ic|~/.pulse}} {{ic|~/.pulse-cookie}}<br />
|<br />
[https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/commit/59a8618 59a8618]<br />
[https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/commit/87ae830 87ae830]<br />
[https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/commit/9ab510a 9ab510a]<br />
[https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/commit/4c195bc 4c195bc]<br />
| [https://bugzilla.redhat.com/show_bug.cgi?id=845607]<br />
|<br />
|-<br />
| {{AUR|pyroom}}<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| {{Pkg|quodlibet}}<br />
| {{ic|~/.quodlibet}}<br />
| 3.10.0<br />
| [https://github.com/quodlibet/quodlibet/issues/138]<br />
|<br />
|-<br />
| [[qutebrowser]]<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| [[qtile]]<br />
|<br />
|<br />
[https://github.com/qtile/qtile/commit/fd8686e fd8686e]<br />
[https://github.com/qtile/qtile/commit/66d704b 66d704b]<br />
[https://github.com/qtile/qtile/commit/51cff01 51cff01]<br />
| [https://github.com/qtile/qtile/pull/835]<br />
| Some optional bar widgets can create files and directories in non-compliant paths, but most often these are still configurable.<br />
|-<br />
| {{Pkg|rclone}}<br />
| {{ic|~/.rclone.conf}}<br />
| [https://github.com/ncw/rclone/commit/9d36258 9d36258]<br />
| [https://github.com/ncw/rclone/issues/868]<br />
|<br />
|-<br />
| {{Pkg|retroarch}}<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| {{AUR|rr}}<br />
| {{ic|~/.rr}}<br />
| [https://github.com/mozilla/rr/commit/02e7d41 02e7d41]<br />
| [https://github.com/mozilla/rr/issues/1455]<br />
|<br />
|-<br />
| [https://rspec.info RSpec]<br />
| {{ic|~/.rspec}}<br />
| [https://github.com/rspec/rspec-core/commit/5e395e2016f1da19475e6db2817eb26dae828c4c 5e395e2]<br />
| [https://github.com/rspec/rspec-core/issues/1773]<br />
|<br />
|-<br />
| [[rTorrent]]<br />
| {{ic|~/.rtorrent.rc}}<br />
| [https://github.com/rakshasa/rtorrent/commit/6a8d332 6a8d332]<br />
|<br />
|<br />
|-<br />
| [https://www.rubocop.org RuboCop]<br />
| {{ic|~/.rubocop.yml}}<br />
| [https://github.com/rubocop-hq/rubocop/commit/6fe5956c177ca369cfaa70bdf748b70020a56bf4 6fe5956]<br />
| [https://github.com/rubocop-hq/rubocop/issues/6662]<br />
|<br />
|-<br />
| [[Ruby#RubyGems]]<br />
| {{ic|~/.gem}}<br />
| [https://github.com/ruby/ruby/commit/5c6269c 3.0.0 (5c6269c)]<br />
| [https://github.com/ruby/ruby/pull/2174]<br />
|<br />
XDG_CONFIG_HOME/gemrc<br />
XDG_CONFIG_HOME/irb<br />
XDG_DATA_HOME/gem<br />
XDG_DATA_HOME/rdoc<br />
|-<br />
| [https://github.com/benvan/sandboxd sandboxd]<br />
| {{ic|~/.sandboxrc}}<br />
| [https://github.com/benvan/sandboxd/pull/14]<br />
| [https://github.com/benvan/sandboxd/issues/11]<br />
| {{ic|XDG_CONFIG_HOME/sandboxd/sandboxrc}}<br />
|-<br />
| {{Pkg|scribus}}<br />
| {{ic|~/.scribus}}<br />
| [https://wiki.scribus.net/canvas/Versione_1.5.3 1.5.3]<br />
| <br />
|-<br />
| {{Pkg|scummvm}}<br />
| {{ic|~/.scummvmrc}} {{ic|~/.scummvm/}}<br />
| [https://github.com/scummvm/scummvm/commit/7d014be0a2b796175a7ce40a9315603f711b2a30 7d014be]<br />
| [https://github.com/scummvm/scummvm/pull/656]<br />
| It is required to migrate data by hand.<br />
{{ic|mkdir "$XDG_CONFIG_HOME"/scummvm/ "$XDG_DATA_HOME"/scummvm}}<br />
{{ic|mv ~/.scummvmrc "$XDG_CONFIG_HOME"/scummvm/scummvm.ini}}<br />
{{ic|mv ~/.scummvm "$XDG_DATA_HOME"/scummvm/saves}}<br />
|-<br />
| {{Pkg|sdcv}}<br />
| {{ic|~/.stardict/}} {{ic|~/.sdcv_history}}<br />
| [https://github.com/Dushistov/sdcv/commit/958ec35 958ec35]<br />
| [https://github.com/Dushistov/sdcv/issues/51]<br />
|<br />
|-<br />
| {{AUR|skypeforlinux-stable-bin}}<br />
| {{ic|~/.Skype}}<br />
| 8.0<br />
|<br />
|<br />
|-<br />
| {{Pkg|snes9x}}<br />
| {{ic|~/.snes9x}}<br />
| [https://github.com/snes9xgit/snes9x/commit/93b5f11 93b5f11]<br />
| [https://github.com/snes9xgit/snes9x/issues/194]<br />
| By default, the configuration file is left blank with intention that the user will fill it at their will (through the gui or manually).<br />
|-<br />
| [[spectrwm]]<br />
| {{ic|~/.spectrwm}}<br />
| [https://github.com/conformal/spectrwm/commit/a30bbb a30bbb]<br />
| [https://github.com/conformal/spectrwm/pull/153]<br />
|<br />
|-<br />
| {{AUR|sublime-text-dev}}<br />
|<br />
| [https://www.sublimetext.com/dev build 4105]<br />
|<br />
| Prior to build 4105, the cache was placed in {{ic|XDG_CONFIG_HOME/sublime-text-3/Cache}}.<br />
|-<br />
| [[surfraw]]<br />
| {{ic|~/.surfraw.conf}} {{ic|~/.surfraw.bookmarks}}<br />
|<br />
[https://gitlab.com/surfraw/Surfraw/commit/3e4591d 3e4591d]<br />
[https://gitlab.com/surfraw/Surfraw/commit/bd8c427 bd8c427]<br />
[https://gitlab.com/surfraw/Surfraw/commit/f57fc71 f57fc71]<br />
|<br />
|<br />
|-<br />
| [[sway]]<br />
| {{ic|~/.sway/config}}<br />
| [https://github.com/SirCmpwn/sway/commit/614393c 614393c]<br />
| [https://github.com/SirCmpwn/sway/issues/5]<br />
| {{ic|XDG_CONFIG_HOME/sway/config}}<br />
|-<br />
| [[sxhkd]]<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| [[systemd]]<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| {{Pkg|teeworlds}}<br />
| {{ic|~/.teeworlds}}<br />
| [https://github.com/teeworlds/teeworlds/commit/d2e39d2f50684151490da446156622e69dd84a48]<br />
|<br />
|<br />
|-<br />
| [[termite]]<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| {{Pkg|tig}}<br />
| {{ic|~/.tigrc}}, {{ic|~/.tig_history}}<br />
| [https://github.com/jonas/tig/blob/master/NEWS.adoc#tig-22 2.2]<br />
| [https://github.com/jonas/tig/issues/513]<br />
| {{ic|~/.local/share/tig}} directory must exist, writes to {{ic|~/.tig_history}} otherwise.<br />
|-<br />
| [[tmux]]<br />
| {{ic|~/.tmux.conf}}<br />
| [https://raw.githubusercontent.com/tmux/tmux/3.1/CHANGES 3.1]<br />
| [https://github.com/tmux/tmux/issues/142]<br />
| 3.1 introduced {{ic|~/.config/tmux/tmux.conf}} and in [https://github.com/tmux/tmux/blob/a5f99e14c6f264e568b860692b89d11f5298a3f2/CHANGES#L145 3.2] {{ic|XDG_CONFIG_HOME/tmux/tmux.conf}} was added<br />
|-<br />
| [[tmuxp]]<br />
| {{ic|~/.tmuxp}}<br />
| [https://tmuxp.git-pull.com/history.html#tmuxp-1-5-0-2018-10-02 1.5.0]<br />
| [https://github.com/tmux-python/tmuxp/pull/404]<br />
| Fixed in [https://tmuxp.git-pull.com/history.html#tmuxp-1-5-2-2019-06-02 1.5.2]<br />
|-<br />
| {{AUR|tmuxinator}}<br />
| {{ic|~/.tmuxinator}}<br />
| [https://github.com/tmuxinator/tmuxinator/pull/511/commits/2636923 2636923]<br />
| [https://github.com/tmuxinator/tmuxinator/pull/511]<br />
|<br />
|-<br />
| [[Transmission]]<br />
| {{ic|~/.transmission}}<br />
| [https://github.com/transmission/transmission/commit/b71a298 b71a298]<br />
|<br />
|<br />
|-<br />
| {{Pkg|util-linux}}<br />
|<br />
| [https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=570b321 570b321]<br />
|<br />
|<br />
|-<br />
| [[Uzbl]]<br />
|<br />
| [https://github.com/uzbl/uzbl/commit/c6fd63a c6fd63a]<br />
| [https://github.com/uzbl/uzbl/pull/150]<br />
|<br />
|-<br />
| {{Pkg|vimb}}<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| [[VirtualBox]]<br />
| {{ic|~/.VirtualBox}}<br />
| [https://www.virtualbox.org/ticket/5099?action=diff&version=7 4.3]<br />
| [https://www.virtualbox.org/ticket/5099]<br />
|<br />
|-<br />
| {{Pkg|vis}}<br />
| {{ic|~/.vis}}<br />
|<br />
[https://github.com/martanne/vis/commit/68a25c7 68a25c7]<br />
[https://github.com/martanne/vis/commit/d138908 d138908]<br />
| [https://github.com/martanne/vis/pull/303]<br />
|<br />
|-<br />
| [[VLC]]<br />
| {{ic|~/.vlcrc}}<br />
| [https://git.videolan.org/?p=vlc.git;a=commit;h=16f32e1 16f32e1]<br />
| [https://trac.videolan.org/vlc/ticket/1267]<br />
|<br />
|-<br />
| {{Pkg|warsow}}<br />
| {{ic|~/.warsow-2.x}}<br />
| [https://github.com/Qfusion/qfusion/commit/98ece3f 98ece3f]<br />
| [https://github.com/Qfusion/qfusion/issues/298]<br />
|<br />
|-<br />
| [[WeeChat]]<br />
| {{ic|~/.weechat}}<br />
| [https://github.com/weechat/weechat/commit/70cdf21681d75090c3df9858c9e7ce5a85433856]<br />
[https://github.com/weechat/weechat/releases/tag/v3.2 3.2]<br />
| [https://github.com/weechat/weechat/issues/1285] [https://specs.weechat.org/specs/001285-follow-xdg-base-dir-spec.html]<br />
|<br />
XDG_CONFIG_HOME/weechat<br />
XDG_CACHE_HOME/weechat<br />
XDG_DATA_HOME/weechat<br />
|-<br />
| [[Wireshark]]<br />
| {{ic|~/.wireshark}}<br />
| [https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=b0b53fa b0b53fa]{{Dead link|2022|09|23|status=domain name not resolved}}<br />
|<br />
|<br />
|-<br />
| [https://wxwidgets.org/ wxWidgets]<br />
| <br />
| [https://trac.wxwidgets.org/ticket/17727]<br />
|<br />
|<br />
|-<br />
| [[Xsettingsd]]<br />
| {{ic|~/.xsettingsd}}<br />
| [https://github.com/derat/xsettingsd/commit/b4999f5 b4999f5]<br />
|<br />
|<br />
|-<br />
| [[xmobar]]<br />
| {{ic|~/.xmobarrc}}<br />
| [https://github.com/jaor/xmobar/commit/7b0d6bf 7b0d6bf]<br />
[https://github.com/jaor/xmobar/commit/9fc6b37 9fc6b37]<br />
[https://github.com/jaor/xmobar/commit/eaccf70 eaccf70]<br />
| [https://github.com/jaor/xmobar/pull/99]<br />
[https://github.com/jaor/xmobar/pull/131]<br />
| {{ic|XDG_CONFIG_HOME/xmobar/xmobarrc}}<br />
|-<br />
| [[xmonad]]<br />
| {{ic|~/.xmonad/}}<br />
| [https://github.com/xmonad/xmonad/commit/40fc10b 40fc10b]<br />
|<br />
[https://github.com/xmonad/xmonad/issues/61]<br />
[https://code.google.com/p/xmonad/issues/detail?id=484]<br />
| All of these must exist, otherwise it gives up and falls back to {{ic|~/.xmonad/}} for each:<br />
XDG_CACHE_HOME/xmonad<br />
XDG_CONFIG_HOME/xmonad<br />
XDG_DATA_HOME/xmonad<br />
Alternatively, it always respects {{ic|XMONAD_CACHE_DIR}}, {{ic|XMONAD_CONFIG_DIR}}, and {{ic|XMONAD_DATA_DIR}}.<br />
|-<br />
| {{Pkg|xournalpp}}<br />
| {{ic|~/.xournalpp}}<br />
|<br />
[https://github.com/xournalpp/xournalpp/commit/20db937f 20db937f]<br />
[https://github.com/xournalpp/xournalpp/releases/tag/1.1.0 1.1.0]<br />
|<br />
[https://github.com/xournalpp/xournalpp/issues/1101]<br />
[https://github.com/xournalpp/xournalpp/pull/1384]<br />
|-<br />
| {{Pkg|xsel}}<br />
| {{ic|~/.xsel.log}}<br />
| [https://github.com/kfish/xsel/commit/ee7b481 ee7b481]<br />
| [https://github.com/kfish/xsel/issues/10]<br />
|<br />
|-<br />
| [[Zim]]<br />
| <br />
| [https://github.com/zim-desktop-wiki/zim-desktop-wiki/commit/e42b8b0 e42b8b0]<br />
| <br />
|<br />
|-<br />
| {{Pkg|zoxide}}<br />
| {{ic|~/.zo}}<br />
| [https://github.com/ajeetdsouza/zoxide/releases/tag/v0.3.0 0.3.0]<br />
| [https://github.com/ajeetdsouza/zoxide/pull/47]<br />
|<br />
|}<br />
<br />
=== Partial ===<br />
<br />
{| class="wikitable sortable" style="width: 100%"<br />
! Application<br />
! Legacy Path<br />
! Supported Since<br />
! Discussion<br />
! Notes<br />
|-<br />
| {{AUR|abook}}<br />
| {{ic|~/.abook}}<br />
|<br />
|<br />
| {{ic|1=abook --config "$XDG_CONFIG_HOME"/abook/abookrc --datafile "$XDG_DATA_HOME"/abook/addressbook}}<br />
|-<br />
| {{Pkg|ack}}<br />
| {{ic|~/.ackrc}}<br />
|<br />
| [https://github.com/beyondgrep/ack2/issues/516]<br />
| {{ic|1=export ACKRC="$XDG_CONFIG_HOME/ack/ackrc"}}<br />
|-<br />
| [[Ansible]]<br />
| {{ic|~/.ansible}}<br />
| [https://github.com/ansible/ansible/pull/76114 2.14]<br />
| [https://github.com/ansible/ansible/issues/52354] [https://github.com/ansible/ansible/issues/68587] [https://github.com/ansible/ansible/issues/75788]<br />
| {{bc|1=export ANSIBLE_HOME="${XDG_CONFIG_HOME}/ansible"<br />
export ANSIBLE_CONFIG="${XDG_CONFIG_HOME}/ansible.cfg"<br />
export ANSIBLE_GALAXY_CACHE_DIR="${XDG_CACHE_HOME}/ansible/galaxy_cache"}} [https://docs.ansible.com/ansible/latest/reference_appendices/config.html]<br />
|-<br />
| {{AUR|asdf-vm}}<br />
| {{ic|~/.asdfrc}}, {{ic|~/.asdf/}}<br />
|<br />
| [https://github.com/asdf-vm/asdf/issues/687]<br />
| {{ic|1=export ASDF_CONFIG_FILE="${XDG_CONFIG_HOME}/asdf/asdfrc"}}, {{ic|1=export ASDF_DATA_DIR="${XDG_DATA_HOME}/asdf"}}<br />
|-<br />
| [[aspell]]<br />
| {{ic|~/.aspell.conf}}<br />
|<br />
| [https://github.com/GNUAspell/aspell/issues/560]<br />
| {{ic|1=export ASPELL_CONF="per-conf $XDG_CONFIG_HOME/aspell/aspell.conf; personal $XDG_CONFIG_HOME/aspell/en.pws; repl $XDG_CONFIG_HOME/aspell/en.prepl"}}<br />
|-<br />
| [[Atom]]<br />
| {{ic|~/.atom}}<br />
|<br />
| [https://github.com/atom/atom/issues/8281]<br />
| {{ic|1=export ATOM_HOME="$XDG_DATA_HOME"/atom}}<br />
|-<br />
| {{Pkg|aws-cli}}<br />
| {{ic|~/.aws}}<br />
| [https://github.com/aws/aws-cli/commit/fc5961ea2cc0b5976ac9f777e20e4236fd7540f5 1.7.45]<br />
| [https://github.com/aws/aws-cli/issues/2433]<br />
| {{ic|1=export AWS_SHARED_CREDENTIALS_FILE="$XDG_CONFIG_HOME"/aws/credentials}}, {{ic|1=export AWS_CONFIG_FILE="$XDG_CONFIG_HOME"/aws/config}}<br />
|-<br />
| {{Pkg|bash-completion}}<br />
| {{ic|~/.bash_completion}}<br />
|<br />
|<br />
| {{ic|1=export BASH_COMPLETION_USER_FILE="$XDG_CONFIG_HOME"/bash-completion/bash_completion}}<br />
|-<br />
| {{AUR|bashdb}}<br />
| {{ic|~/.bashdbinit, ~/.bashdb_hist}}<br />
|<br />
|<br />
| Like documented at [https://bashdb.sourceforge.net/bashdb.html#Command-Files], you can specify a file to run commands from. Thus, move the init file to {{ic|XDG_CONFIG_HOME/bashdb/bashdbinit}} and create an alias {{ic|1=alias bashdb='bashdb -x ${XDG_CONFIG_HOME:-$HOME/.config}/bashdb/bashdbinit'}}. Unfortunately the history file is hardcoded [https://sourceforge.net/p/bashdb/code/ci/bash-5.1/tree/lib/hist.sh#l28].<br />
|-<br />
| [[bazaar]]<br />
| {{ic|~/.bazaar}}, {{ic|~/.bzr.log}}<br />
| [https://bugs.launchpad.net/bzr/+bug/195397/comments/15 2.3.0]<br />
| [https://bugs.launchpad.net/bzr/+bug/195397]<br />
| Discussion in upstream bug states that bazaar will use {{ic|~/.config/bazaar}} if it exists. The logfile {{ic|~/.bzr.log}} might still be written.<br />
|-<br />
| {{pkg|bogofilter}}<br />
| {{ic|~/.bogofilter}}<br />
| [https://gitlab.com/bogofilter/bogofilter/-/blob/main/bogofilter/NEWS.0#L2760 0.7.5]<br />
| [https://sourceforge.net/p/bogofilter/bugs/110/]<br />
| {{ic|1=export BOGOFILTER_DIR="$XDG_DATA_HOME"/bogofilter}}<br />
|-<br />
| {{Aur|btpd-git}}<br />
| {{ic|~/.btpd/}}<br />
|<br />
| [https://github.com/btpd/btpd/issues/55]<br />
| {{ic|1=btpd -d "$XDG_DATA_HOME"/.btpd}}<br />
{{ic|1=HOME="$XDG_DATA_HOME" btcli}}<br />
|-<br />
| {{Pkg|calc}}<br />
| {{ic|~/.calc_history}}<br />
|<br />
|<br />
|<br />
export CALCHISTFILE="$XDG_CACHE_HOME"/calc_history<br />
|-<br />
| [[Rust#Cargo]]<br />
| {{ic|~/.cargo}}<br />
|<br />
| [https://github.com/rust-lang/cargo/issues/1734] [https://github.com/rust-lang/rfcs/pull/1615] [https://github.com/rust-lang/cargo/pull/5183] [https://github.com/rust-lang/cargo/pull/148]<br />
| {{ic|1=export CARGO_HOME="$XDG_DATA_HOME"/cargo}}<br />
|-<br />
| {{Pkg|cataclysm-dda}}<br />
| {{ic|~/.cataclysm-dda}}<br />
|[https://github.com/archlinux/svntogit-community/commit/e81e479cbb02eaf0c9c3475810127f55bd3a7a7e 0.D-1]<br />
|[https://github.com/CleverRaven/Cataclysm-DDA/issues/12315]<br />
| partial support due to required compile time option<br />
|-<br />
| [https://github.com/mollifier/cd-bookmark cd-bookmark]<br />
| {{ic|~/.cdbookmark}}<br />
|<br />
| [https://github.com/mollifier/cd-bookmark/issues/3]<br />
| {{ic|1=export CD_BOOKMARK_FILE=$XDG_CONFIG_HOME/cd-bookmark/bookmarks}}<br />
or use the fork that has native XDG support: [https://github.com/erikw/cd-bookmark/]<br />
|-<br />
| {{pkg|cgdb}}<br />
| {{ic|~/.cgdb}}<br />
| [On master branch, but no release yet]<br />
| [https://github.com/cgdb/cgdb/issues/203] [https://github.com/cgdb/cgdb/blob/master/NEWS]<br />
| Set {{ic|1=export CGDB_DIR=$XDG_CONFIG_HOME/cgdb}} and move the config file to {{ic|XDG_CONFIG_HOME/cgdb/cgdbrc}}<br />
|-<br />
| {{AUR|chez-scheme}}<br />
| {{ic|~/.chezscheme_history}}<br />
|<br />
|<br />
| {{ic|1=petite --eehistory "$XDG_DATA_HOME"/chezscheme/history}}<br />
|-<br />
| [[Chromium]]<br />
| {{ic|~/.chromium}}, {{ic|~/.pki}}<br />
| [https://src.chromium.org/viewvc/chrome?revision=23057&view=revision 23057]<br />
| [https://groups.google.com/forum/#!topic/chromium-dev/QekVQxF3nho] [https://code.google.com/p/chromium/issues/detail?id=16976] [https://bugs.chromium.org/p/chromium/issues/detail?id=1038587]<br />
|<br />
|-<br />
| [https://www.cinelerra-gg.org/ cinelerra]<br />
| {{ic|~/.bcast5}}<br />
|<br />
| [https://cinelerra-gg.org/download/CinelerraGG_Manual/Environment_Variables_Custo.html]<br />
| {{ic|1=export CIN_CONFIG="$XDG_CONFIG_HOME"/bcast5}}<br />
|-<br />
| [[conky]]<br />
| {{ic|~/.conkyrc}}<br />
| [https://github.com/brndnmtthws/conky/commit/00481ee9a97025e8e2acd7303d080af1948f7980 00481ee]<br />
| [https://github.com/brndnmtthws/conky/issues/144]<br />
| {{ic|1=conky --config="$XDG_CONFIG_HOME"/conky/conkyrc}}<br />
|-<br />
| {{Pkg|claws-mail}}<br />
| {{ic|~/.claws-mail}}<br />
|<br />
| [https://lists.claws-mail.org/pipermail/users/2013-April/006087.html]<br />
| {{ic|1=claws-mail --alternate-config-dir "$XDG_DATA_HOME"/claws-mail}}<br />
|-<br />
| [[coreutils]]<br />
| {{ic|~/.dircolors}}<br />
|<br />
|<br />
| {{ic|1=eval $(dircolors "$XDG_CONFIG_HOME"/dircolors)}}<br />
|-<br />
| [http://www.dungeoncrawl.org/ crawl]<br />
| {{ic|~/.crawl}}<br />
|<br />
|<br />
| The trailing slash is required:<br />
<br />
{{ic|1=export CRAWL_DIR="$XDG_DATA_HOME"/crawl/}}<br />
|-<br />
| {{Pkg|clusterssh}}<br />
| {{ic|~/.clusterssh/}}<br />
|<br />
|<br />
| {{ic|1=alias cssh="cssh --config-file '$XDG_CONFIG_HOME/clusterssh/config'" }}<br />
{{hc|$XDG_CONFIG_HOME/clusterssh/config|2=<br />
extra_cluster_file=$HOME/.config/clusterssh/clusters<br />
extra_tag_file=$HOME/.config/clusterssh/tags<br />
}}<br />
Despite this, clusterssh will still create {{ic|~/.clusterssh/}}.<br />
|-<br />
| [[CUDA]]<br />
| {{ic|~/.nv}}<br />
|<br />
|<br />
| {{ic|1=export CUDA_CACHE_PATH="$XDG_CACHE_HOME"/nv}}<br />
|-<br />
| [[dict]]<br />
| {{ic|~/.dictrc}}<br />
|<br />
|<br />
| {{ic|1=dict -c "$XDG_CONFIG_HOME"/dict/dictrc}}<br />
|-<br />
| [[Docker]]<br />
| {{ic|~/.docker}}<br />
|<br />
|<br />
| {{ic|1=export DOCKER_CONFIG="$XDG_CONFIG_HOME"/docker}}<br />
|-<br />
| {{Pkg|docker-machine}}<br />
| {{ic|~/.docker/machine}}<br />
|<br />
|<br />
| {{ic|1=export MACHINE_STORAGE_PATH="$XDG_DATA_HOME"/docker-machine}}<br />
|-<br />
| [[DOSBox]]<br />
| {{ic|~/.dosbox/dosbox-0.74-2.conf}}<br />
|<br />
| [https://www.vogons.org/viewtopic.php?t=29599]<br />
| {{ic|1=dosbox -conf "$XDG_CONFIG_HOME"/dosbox/dosbox.conf}}<br />
|-<br />
| {{Pkg|dub}}<br />
| {{ic|~/.dub}}<br />
| [https://github.com/dlang/dub/pull/2281 v1.30.0-beta.1]<br />
| <br />
| Dub uses the {{ic|~/.dub}} directory for both user settings and caching downloaded packages. The directory can only be moved as a whole, using {{ic|1=export DUB_HOME="path/to/new/dub"}}.<br />
|-<br />
| [https://electrum.org Electrum Bitcoin Wallet]<br />
| {{ic|~/.electrum}}<br />
| [https://github.com/spesmilo/electrum/commit/c121230 c121230]<br />
|<br />
| {{ic|1=export ELECTRUMDIR="$XDG_DATA_HOME/electrum"}}<br />
|-<br />
| [[ELinks]]<br />
| {{ic|~/.elinks}}<br />
|<br />
|<br />
| {{ic|1=export ELINKS_CONFDIR="$XDG_CONFIG_HOME"/elinks}}<br />
|-<br />
| {{Pkg|elixir}}<br />
| {{ic|~/.mix}}<br />
| [https://github.com/elixir-lang/elixir/commit/afaf889 afaf889]<br />
| [https://github.com/elixir-lang/elixir/issues/8818] [https://github.com/elixir-lang/elixir/pull/9937]<br />
| Elixir do not fully conform to XDG specs, it will use XDG only if the environment variables are present, otherwise it will by default use legacy path.<br />
|-<br />
| [https://elm-lang.org/ Elm]<br />
| {{ic|~/.elm}}<br />
| <br />
| <br />
| {{ic|1=export ELM_HOME="$XDG_CONFIG_HOME"/elm}}<br />
|-<br />
| {{Pkg|fceux}}<br />
| {{ic|~/.fceux/}}<br />
|<br />
| [https://github.com/TASEmulators/fceux/issues/412]<br />
| {{ic|1=export FCEUX_HOME="$XDG_CONFIG_HOME"/fceux}}. Fceux will create {{ic|1=.fceux}} directory inside {{ic|1=$FCEUX_HOME}}.<br />
|-<br />
| [[FFmpeg]]<br />
| {{ic|~/.ffmpeg}}<br />
|<br />
|<br />
| {{ic|1=export FFMPEG_DATADIR="$XDG_CONFIG_HOME"/ffmpeg}}<br />
|-<br />
| {{AUR|flutter}}<br />
| {{ic|~/.flutter}}, {{ic|~/.flutter_settings}}, {{ic|~/.flutter_tool_state}}, {{ic|~/.pub-cache}}<br />
|<br />
| [https://github.com/flutter/flutter/issues/59430]<br />
|<br />
|-<br />
| {{AUR|fzf-git}}<br />
| {{ic|~/.fzf.bash, ~/.fzf.zsh}}<br />
| <br />
| [https://github.com/junegunn/fzf/pull/1282]<br />
| The shell init files will be installed to {{ic|XDG_CONFIG_HOME/fzf}} if the installation script is called with {{ic|--xdg}} for example {{ic| /usr/local/opt/fzf/install --xdg}}.<br />
|-<br />
| {{Pkg|emscripten}}<br />
| {{ic|~/.emscripten}}, {{ic|~/.emscripten_sanity}}, {{ic|~/.emscripten_ports}}, {{ic|~/.emscripten_cache__last_clear}}<br />
|<br />
| [https://github.com/kripken/emscripten/issues/3624]<br />
| {{ic|1=export EM_CONFIG="$XDG_CONFIG_HOME"/emscripten/config}}, {{ic|1=export EM_CACHE="$XDG_CACHE_HOME"/emscripten/cache}}, {{ic|1=export EM_PORTS="$XDG_DATA_HOME"/emscripten/cache}}, {{ic|emcc --em-config "$XDG_CONFIG_HOME"/emscripten/config --em-cache "$XDG_CACHE_HOME"/emscripten/cache}}<br />
|-<br />
| {{AUR|get_iplayer}}<br />
| {{ic|~/.get_iplayer}}<br />
|<br />
|<br />
| {{ic|1=export GETIPLAYERUSERPREFS="$XDG_DATA_HOME"/get_iplayer}}<br />
|-<br />
| [[getmail]]<br />
| {{ic|~/.getmail/getmailrc}}<br />
|<br />
|<br />
| {{ic|1=getmail --rcfile="$XDG_CONFIG_HOME/getmail/getmailrc" --getmaildir="$XDG_DATA_HOME/getmail"}}<br />
|-<br />
| {{Pkg|ghc}}<br />
| {{ic|~/.ghci}}<br />
| [https://gitlab.haskell.org/ghc/ghc/-/commit/763d28551de32377a1dca8bdde02979e3686f400]<br />
| [https://ghc.haskell.org/trac/ghc/ticket/6077]<br />
| Supported upstream from 9.4.1 [https://downloads.haskell.org/~ghc/9.4.1/docs/users_guide/9.4.1-notes.html?highlight=xdg], but as of 2022-09-24 Arch package is 9.0.2 and not yet up-to-date.<br />
|-<br />
| {{AUR|ghcup-hs-bin}}<br />
| {{ic|~/.ghcup}}<br />
| [https://gitlab.haskell.org/haskell/ghcup-hs/-/commit/80603662b4fcc42fd936f45608dc3bc924c7e498]<br />
| [https://gitlab.haskell.org/haskell/ghcup-hs/issues/39]<br />
| {{ic|1=export GHCUP_USE_XDG_DIRS=true}}<br />
The environment variable {{ic|GHCUP_USE_XDG_DIRS}} can be set to any non-empty value. See [https://www.haskell.org/ghcup/guide/#xdg-support].<br />
|-<br />
| {{AUR|gliv}}<br />
| {{ic|~/.glivrc}}<br />
|<br />
|<br />
| {{ic|1=gliv --glivrc="$XDG_CONFIG_HOME"/gliv/glivrc}}<br />
|-<br />
| {{Pkg|gnuradio}}<br />
| {{ic|~/.gnuradio}}<br />
|<br />
| [https://github.com/gnuradio/gnuradio/issues/3631]<br />
|<br />
|-<br />
| [[GnuPG]]<br />
| {{ic|~/.gnupg}}<br />
|<br />
| [https://bugs.gnupg.org/gnupg/issue1456] [https://bugs.gnupg.org/gnupg/issue1018]<br />
| {{ic|1=export GNUPGHOME="$XDG_DATA_HOME"/gnupg}}, {{ic|gpg2 --homedir "$XDG_DATA_HOME"/gnupg}}<br />
Note that this currently does not work out-of-the-box using systemd user units and socket-based activation, since the socket directory changes based on the hash of {{ic|$GNUPGHOME}}. You can get the new socket directory using {{ic|gpgconf --dry-run --create-socketdir}} and have to modify the systemd user units to listen on the correct sockets accordingly.<br />
|-<br />
| [[Go]]<br />
| {{ic|~/go}}<br />
| [https://github.com/golang/go/commit/ca8a055f5cc7c1dfa0eb542c60071c7a24350f76]<br />
|<br />
| {{ic|1=export GOPATH="$XDG_DATA_HOME"/go}}, {{ic|1=export GOMODCACHE="$XDG_CACHE_HOME"/go/mod}}<br />
If {{ic|GOMODCACHE}} is not set, it defaults to {{ic|$GOPATH/pkg/mod}} (see [https://go.dev/ref/mod#environment-variables]).<br />
{{ic|GOCACHE}} is supported and defaults to {{ic|$XDG_CACHE_HOME/go-build}} (see [https://pkg.go.dev/cmd/go#hdr-Build_and_test_caching]).<br />
|-<br />
| [[Google Earth]]<br />
| {{ic|~/.googleearth}}<br />
|<br />
|<br />
| Some paths can be changed with the {{ic|KMLPath}} and {{ic|CachePath}} options in {{ic|~/.config/Google/GoogleEarthPlus.conf}}<br />
|-<br />
| {{Pkg|gopass}}<br />
| {{ic|~/.password-store}}<br />
|<br />
|<br />
| Override settings in {{ic|~/.config/gopass/config.yml}}:<br />
{{hc|~/.config/gopass/config.yml|<br />
root:<br />
path: gpgcli-gitcli-fs+file:///home/<userid>/.config/password-store<br />
}}<br />
|-<br />
| {{Pkg|gpodder}}<br />
| {{ic|~/gPodder}}<br />
|<br />
|<br />
| {{ic|1=GPODDER_DOWNLOAD_DIR}} sets the download folder. {{ic|1=GPODDER_HOME}} - where config and database files are stored, downloads also if {{ic|1=GPODDER_DOWNLOAD_DIR}} is not set.<br />
|-<br />
| [https://sourceforge.net/projects/gqclient GQ LDAP client]<br />
| {{ic|~/.gq}}, {{ic|~/.gq-state}}<br />
| [https://sourceforge.net/p/gqclient/mailman/message/2053978 1.51]<br />
|<br />
| {{ic|1=export GQRC="$XDG_CONFIG_HOME"/gqrc}}, {{ic|1=export GQSTATE="$XDG_DATA_HOME"/gq/gq-state}}, {{ic|mkdir -p "$(dirname "$GQSTATE")"}}<br />
|-<br />
| [[Gradle]]<br />
| {{ic|~/.gradle}}<br />
|<br />
| [https://discuss.gradle.org/t/be-a-nice-freedesktop-citizen-move-the-gradle-to-the-appropriate-location-in-linux/2199]<br />
| {{ic|1=export GRADLE_USER_HOME="$XDG_DATA_HOME"/gradle}}<br />
|-<br />
| [[GTK]] 1<br />
| {{ic|~/.gtkrc}}<br />
|<br />
|<br />
| {{ic|1=export GTK_RC_FILES="$XDG_CONFIG_HOME"/gtk-1.0/gtkrc}}<br />
|-<br />
| [[GTK]] 2<br />
| {{ic|~/.gtkrc-2.0}}<br />
|<br />
|<br />
| {{ic|1=export GTK2_RC_FILES="$XDG_CONFIG_HOME"/gtk-2.0/gtkrc}}<br />
|-<br />
| {{Pkg|hledger}}<br />
| {{ic|~/.hledger.journal}}<br />
|<br />
| [https://github.com/simonmichael/hledger/issues/1081]<br />
| {{ic|1=export LEDGER_FILE="$XDG_DATA_HOME"/hledger.journal}}<br />
|-<br />
| [https://www.sidefx.com/products/houdini/ Houdini]<br />
| {{ic|~/houdini''MAJOR''.''MINOR'')}}<br />
|<br />
| [https://forums.odforce.net/topic/43138-changing-home-location/]<br />
[https://www.sidefx.com/docs/houdini/ref/env.html]<br />
| {{ic|1=export HOUDINI_USER_PREF_DIR="$XDG_CACHE_HOME"/houdini__HVER__}}<br />
The value of this variable must include the substring {{ic|__HVER__}}, which will be replaced at run time with the current {{ic|''MAJOR''.''MINOR''}} version string.<br />
|-<br />
| {{AUR|imapfilter}}<br />
| {{ic|~/.imapfilter}}<br />
|<br />
|<br />
| {{ic|1=export IMAPFILTER_HOME="$XDG_CONFIG_HOME/imapfilter"}}<br />
|-<br />
| [[IPFS]]<br />
| {{ic|~/.ipfs}}<br />
|<br />
|<br />
| {{ic|1=export IPFS_PATH="$XDG_DATA_HOME"/ipfs}}<br />
|-<br />
| [https://ruby-doc.org/stdlib/libdoc/irb/rdoc/IRB.html irb]<br />
| {{ic|~/.irbrc}}<br />
|<br />
|<br />
| {{hc|1=~/.profile|2=$ export IRBRC="$XDG_CONFIG_HOME"/irb/irbrc}}<br />
{{hc|1="$XDG_CONFIG_HOME"/irb/irbrc|2=IRB.conf[:SAVE_HISTORY] {{!}}{{!}}= 1000<br />
IRB.conf[:HISTORY_FILE] {{!}}{{!}}= File.join(ENV["XDG_DATA_HOME"], "irb", "history")}}<br />
|-<br />
| [[irssi]]<br />
| {{ic|~/.irssi}}<br />
|<br />
| [https://github.com/irssi/irssi/pull/511]<br />
| {{ic|1=irssi --config="$XDG_CONFIG_HOME"/irssi/config --home="$XDG_DATA_HOME"/irssi}}<br />
|-<br />
| [[isync]]<br />
| {{ic|~/.mbsyncrc}}<br />
|<br />
| [https://sourceforge.net/p/isync/feature-requests/14/]<br />
| {{ic|1=mbsync -c "$XDG_CONFIG_HOME"/isync/mbsyncrc}}<br />
|-<br />
| [[Java#OpenJDK]]<br />
| {{ic|~/.java/.userPrefs}}<br />
|<br />
| [https://bugzilla.redhat.com/show_bug.cgi?id=1154277]<br />
| {{ic|1=export _JAVA_OPTIONS=-Djava.util.prefs.userRoot="$XDG_CONFIG_HOME"/java}}<br />
|-<br />
| [[jupyter]]<br />
| {{ic|~/.jupyter}}<br />
| [https://github.com/jupyter/jupyter_core/releases/tag/5.0.0rc0 5.0.0rc0]<br />
| [https://github.com/jupyter/jupyter_core/issues/185] [https://github.com/jupyter/jupyter_core/pull/292]<br />
| {{Pkg|python-jupyter-core}} < v5.0.0:<br />
<br />
{{ic|1=export JUPYTER_CONFIG_DIR="$XDG_CONFIG_HOME"/jupyter}}<br />
<br />
v5.0.0 <= {{Pkg|python-jupyter-core}} < v6.0.0:<br />
<br />
{{ic|1=export JUPYTER_PLATFORM_DIRS="1"}} (see [https://github.com/jupyter/jupyter_core/blob/3efd00e5804424198285c63ebc6dc6c085d8c857/jupyter_core/paths.py#L176-L181])<br />
<br />
{{Pkg|python-jupyter-core}} >= v6.0.0: full support (via {{Pkg|python-platformdirs}}) enabled by default<br />
|-<br />
| {{Pkg|k9s}}<br />
| {{ic|~/.k9s}}<br />
| [https://github.com/derailed/k9s/releases/tag/v0.20.4 0.20.4]<br />
| [https://github.com/derailed/k9s/issues/743]<br />
| {{ic|1=export K9SCONFIG="$XDG_CONFIG_HOME"/k9s}}<br />
|-<br />
| [[KDE]]<br />
| {{ic|~/.kde}}, {{ic|~/.kde4}}<br />
|<br />
| [https://userbase.kde.org/KDE_System_Administration/KDE_Filesystem_Hierarchy#KDEHOME]<br />
| {{ic|1=export KDEHOME="$XDG_CONFIG_HOME"/kde}}<br />
|-<br />
| {{Pkg|keychain}}<br />
| {{ic|~/.keychain}}<br />
| [https://github.com/funtoo/keychain/commit/d43099bcff315d24a2ca31ae83da85e115d22ef6]<br />
| [https://github.com/funtoo/keychain/issues/8]<br />
| {{ic|1=keychain --absolute --dir "$XDG_RUNTIME_DIR"/keychain}}<br />
|-<br />
| {{Pkg|kodi}}<br />
| {{ic|~/.kodi}}<br />
| [https://github.com/xbmc/xbmc/pull/14460]<br />
| [https://github.com/xbmc/xbmc/pull/6142]<br />
| {{ic|1=KODI_DATA=$XDG_DATA_HOME/kodi}}<br />
|-<br />
| {{AUR|kscript}}<br />
| {{ic|~/.kscript}}<br />
|<br />
| [https://github.com/holgerbrandl/kscript/issues/323]<br />
| {{ic|1=export KSCRIPT_CACHE_DIR="$XDG_CACHE_HOME"/kscript}}<br />
|-<br />
| [[ledger]]<br />
| {{ic|~/.ledgerrc}}, {{ic|~/.pricedb}}<br />
|<br />
| [https://github.com/ledger/ledger/issues/1820]<br />
| {{ic|1=ledger --init-file "$XDG_CONFIG_HOME"/ledgerrc}}<br />
|-<br />
| [[Leiningen]]<br />
| {{ic|~/.lein}}, {{ic|~/.m2}}<br />
|<br />
|<br />
| {{ic|1=export LEIN_HOME="$XDG_DATA_HOME"/lein}}<br />
<br />
to change the m2 repo location used by leiningen look here: [[Leiningen#m2_repo_location]]<br />
|-<br />
| {{Pkg|libdvdcss}}<br />
| {{ic|~/.dvdcss}}<br />
|<br />
| [https://mailman.videolan.org/pipermail/libdvdcss-devel/2014-August/001022.html]<br />
| {{ic|1=export DVDCSS_CACHE="$XDG_DATA_HOME"/dvdcss}}<br />
|-<br />
| {{Pkg|libice}}<br />
| {{ic|~/.ICEauthority}}<br />
|<br />
| [https://gitlab.freedesktop.org/xorg/lib/libice/issues/2]<br />
| {{ic|1=export ICEAUTHORITY="$XDG_CACHE_HOME"/ICEauthority}}<br />
Make sure {{ic|XDG_CACHE_HOME}} is set beforehand to directory user running [[Xorg]] has write access to.<br />
<br />
'''Do not''' use {{ic|XDG_RUNTIME_DIR}} as it is available '''after''' login. Display managers that launch [[Xorg]] (like [[GDM]]) will repeatedly fail otherwise.<br />
|-<br />
| [[Xorg|libx11]]<br />
| {{ic|~/.XCompose}}, {{ic|~/.compose-cache}}<br />
|<br />
|<br />
| {{ic|1=export XCOMPOSEFILE="$XDG_CONFIG_HOME"/X11/xcompose}}, {{ic|1=export XCOMPOSECACHE="$XDG_CACHE_HOME"/X11/xcompose}}<br />
|-<br />
| {{Pkg|ltrace}}<br />
| {{ic|~/.ltrace.conf}}<br />
|<br />
|<br />
| {{ic|1=ltrace -F "$XDG_CONFIG_HOME"/ltrace/ltrace.conf}}<br />
|-<br />
| {{Pkg|lynx}}<br />
| {{ic|/etc/lynx.cfg}}<br />
|<br />
|<br />
| {{ic|1=export LYNX_CFG_PATH="$XDG_CONFIG_HOME"/lynx.cfg}}<br />
|-<br />
| [https://git.savannah.nongnu.org/cgit/m17n/m17n-db.git m17n-db]<br />
| {{ic|~/.m17n.d}}<br />
|<br />
| [https://savannah.nongnu.org/bugs/?63056]<br />
| <br />
|-<br />
| {{AUR|maptool-bin}}<br />
| {{ic|~/.maptool-rptools}}<br />
|<br />
| [https://github.com/RPTools/maptool/issues/2786]<br />
| {{hc|1=/opt/maptool/lib/app/MapTool.cfg|2=[JavaOptions]<br />
-DMAPTOOL_DATADIR=.local/share/maptool-rptools}}<br />
However, no way to change the location of this configuration file.<br />
|-<br />
| {{Pkg|maven}}<br />
| {{ic|~/.m2}}<br />
|<br />
| [https://issues.apache.org/jira/browse/MNG-6603]<br />
| {{ic|1=mvn -gs "$XDG_CONFIG_HOME"/maven/settings.xml}} and set {{ic|<localRepository>}} as appropriate in [https://maven.apache.org/settings.html#Simple_Values settings.xml]<br />
|-<br />
| [[Mathematica]]<br />
| {{ic|~/.Mathematica}}<br />
|<br />
|<br />
| {{ic|1=export MATHEMATICA_USERBASE="$XDG_CONFIG_HOME"/mathematica}}<br />
|-<br />
| {{Pkg|maxima}}<br />
| {{ic|~/.maxima}}<br />
|<br />
|<br />
| {{ic|1=export MAXIMA_USERDIR="$XDG_CONFIG_HOME"/maxima}}<br />
|-<br />
| {{Pkg|mednafen}}<br />
| {{ic|~/.mednafen}}<br />
|<br />
|<br />
| {{ic|1=export MEDNAFEN_HOME="$XDG_CONFIG_HOME"/mednafen}}<br />
|-<br />
| {{Pkg|minikube}}<br />
| {{ic|~/.minikube}}<br />
|<br />
| [https://github.com/kubernetes/minikube/issues/4109]<br />
| {{ic|1=export MINIKUBE_HOME="$XDG_DATA_HOME"/minikube}}<br />
<br />
Creates a further {{ic|.minikube}} directory in {{ic|MINIKUBE_HOME}} for whatever reason.<br />
|-<br />
| {{Pkg|mitmproxy}}<br />
| {{ic|~/.mitmproxy}}<br />
|<br />
|<br />
| {{ic|1=alias mitmproxy="mitmproxy --set confdir=$XDG_CONFIG_HOME/mitmproxy"}}, {{ic|1=alias mitmweb="mitmweb --set confdir=$XDG_CONFIG_HOME/mitmproxy"}}<br />
|-<br />
| [[MOC]]<br />
| {{ic|~/.moc}}<br />
|<br />
|<br />
| {{ic|1=mocp -M "$XDG_CONFIG_HOME"/moc}}, {{ic|1=mocp -O MOCDir="$XDG_CONFIG_HOME"/moc}}<br />
|-<br />
| {{Pkg|monero}}<br />
| {{ic|~/.bitmonero}}<br />
|<br />
|<br />
| {{ic|1=monerod --data-dir "$XDG_DATA_HOME"/bitmonero}}<br />
|-<br />
| {{Pkg|most}}<br />
| {{ic|~/.mostrc}}<br />
|<br />
|<br />
| {{ic|1=export MOST_INITFILE="$XDG_CONFIG_HOME"/mostrc}}<br />
|-<br />
| [[MPlayer]]<br />
| {{ic|~/.mplayer}}<br />
|<br />
|<br />
| {{ic|1=export MPLAYER_HOME="$XDG_CONFIG_HOME"/mplayer}}<br />
|-<br />
| {{Pkg|mypy}}<br />
| {{ic|~/.config/mypy/config}}, {{ic|~/.mypy.ini}}, {{ic|~/.mypy_cache}}<br />
| [https://github.com/python/mypy/pull/6304 v0.670]<br />
| [https://github.com/python/mypy/issues/6065] [https://github.com/python/mypy/issues/8790]<br />
| {{ic|1=XDG_CONFIG_HOME/mypy/config}}, {{ic|1=export MYPY_CACHE_DIR="$XDG_CACHE_HOME"/mypy}}<br />
|-<br />
| [[MySQL]]<br />
| {{ic|~/.mysql_history}}, {{ic|~/.my.cnf }}, {{ic|~/.mylogin.cnf}}<br />
|<br />
|<br />
| {{ic|1=export MYSQL_HISTFILE="$XDG_DATA_HOME"/mysql_history}}<br />
<br />
{{ic|~/.my.cnf}} only supported for mysql-server, not mysql-client [https://dev.mysql.com/doc/refman/8.0/en/option-files.html]<br />
<br />
{{ic|~/.mylogin.cnf}} unsupported<br />
|-<br />
| {{Pkg|mysql-workbench}}<br />
| {{ic|~/.mysql/workbench}}<br />
|<br />
|<br />
| You can run MySQL Workbench with the {{ic|1=---configdir}} flag, such as {{ic|1=mysql-workbench --configdir="$XDG_DATA_HOME/mysql/workbench"}}. The directory needs to be created manually, since MySQL Workbench default location is {{ic|1=$HOME/.mysql/workbench}} .<br />
|-<br />
|-<br />
| {{Pkg|ncurses}}<br />
| {{ic|~/.terminfo}}<br />
|<br />
|<br />
| Precludes system path searching:<br />
<br />
{{ic|1=export TERMINFO="$XDG_DATA_HOME"/terminfo}}, {{ic|1=export TERMINFO_DIRS="$XDG_DATA_HOME"/terminfo:/usr/share/terminfo}}<br />
|-<br />
| [https://github.com/tj/n n]<br />
| {{ic|/usr/local/n}}<br />
|<br />
|<br />
| {{ic|1=export N_PREFIX=$XDG_DATA_HOME/n<br />
}}<br />
|-<br />
| {{Pkg|ncmpc}}<br />
| {{ic|~/.ncmpc}}<br />
|<br />
|<br />
| {{ic|ncmpc -f "$XDG_CONFIG_HOME"/ncmpc/config}}<br />
|-<br />
| [[Netbeans]]<br />
| {{ic|~/.netbeans}}<br />
|<br />
| [https://bz.apache.org/netbeans/show_bug.cgi?id=215961]<br />
| {{ic|1=netbeans --userdir "${XDG_CONFIG_HOME}"/netbeans}}<br />
|-<br />
| [[Node.js]]<br />
| {{ic|~/.node_repl_history}}<br />
|<br />
| [https://nodejs.org/api/repl.html#repl_environment_variable_options]<br />
| {{ic|1=export NODE_REPL_HISTORY="$XDG_DATA_HOME"/node_repl_history}}<br />
|-<br />
| {{Pkg|npm}}<br />
| {{ic|~/.npm}}, {{ic|~/.npmrc}}<br />
|<br />
| [https://github.com/npm/cli/issues/654]<br />
| {{ic|1=export NPM_CONFIG_USERCONFIG=$XDG_CONFIG_HOME/npm/npmrc}}<br />
{{hc|npmrc|<nowiki><br />
prefix=${XDG_DATA_HOME}/npm<br />
cache=${XDG_CACHE_HOME}/npm<br />
init-module=${XDG_CONFIG_HOME}/npm/config/npm-init.js<br />
</nowiki>}}<br />
{{ic|prefix}} is unnecessary (and unsupported) if Node.js is installed by {{AUR|nvm}}.<br />
<br />
If you want to configure this system-wide, the file to edit is {{ic|/usr/etc/npmrc}}, not {{ic|/etc/npmrc}}. You can confirm that the config is loaded by running {{ic|npm config list}}<br />
|-<br />
| {{Pkg|opam}}<br />
| {{ic|~/.opam}}<br />
|<br />
| [https://github.com/ocaml/opam/issues/3766]<br />
| {{ic|1=export OPAMROOT="$XDG_DATA_HOME/opam"}}<br />
Both configuration and state data are stored in {{ic|OPAMROOT}}, so this solution is not fully compliant.<br />
|-PKG_CONFIG_PATH<br />
| {{Aur|pnpm}}<br />
| {{ic|~/.pnpm-store}}<br />
|<br />
|<br />
| Add the line {{ic|1=store-dir=${XDG_DATA_HOME}/pnpm-store}} to your {{ic|npmrc}}.<br />
|-<br />
| [[PuTTY]]<br />
| {{ic|~/.putty/}}<br />
| [https://git.tartarus.org/?p=simon/putty.git;a=commit;h=9952b2d5bd5c8fbac4f5731a805bce10fe4ce47c 9952b2d]<br />
|<br />
| Will use {{ic|$XDG_CONFIG_HOME/putty}} if it already exists. Creates {{ic|~/.putty}} if not. Prioritises {{ic|$XDG_CONFIG_HOME/putty}} if both exist. Tested in 0.74<br />
|-<br />
| {{Pkg|nuget}}<br />
| {{ic|~/.nuget/packages}}<br />
|<br />
| [https://docs.microsoft.com/en-us/nuget/consume-packages/managing-the-global-packages-and-cache-folders]<br />
| {{ic|1=export NUGET_PACKAGES="$XDG_CACHE_HOME"/NuGetPackages}}<br />
|-<br />
| [[NVIDIA]]<br />
| {{ic|~/.nv}}<br />
|<br />
|<br />
| Uses {{ic|XDG_CACHE_HOME}} if set, otherwise improperly falls back to {{ic|~/.nv}} instead of {{ic|~/.cache}}.<br />
|-<br />
| {{Pkg|nvidia-settings}}<br />
| {{ic|~/.nvidia-settings-rc}}<br />
|<br />
|<br />
| {{ic|1=nvidia-settings --config="$XDG_CONFIG_HOME"/nvidia/settings}}<br />
|-<br />
| {{AUR|nvm}}<br />
| {{ic|~/.nvm}}<br />
|<br />
|<br />
| {{ic|1=export NVM_DIR="$XDG_DATA_HOME"/nvm}}<br />
|-<br />
| [[Octave]]<br />
| {{ic|~/octave}}, {{ic|~/.octave_packages}}, {{ic|~/.octave_hist}}<br />
|<br />
|<br />
| {{ic|1=export OCTAVE_HISTFILE="$XDG_CACHE_HOME/octave-hsts"}}, {{ic|1=export OCTAVE_SITE_INITFILE="$XDG_CONFIG_HOME/octave/octaverc"}}<br />
<br />
{{hc|$XDG_CONFIG_HOME/octave/octaverc|<nowiki><br />
source /usr/share/octave/site/m/startup/octaverc;<br />
pkg prefix ~/.local/share/octave/packages ~/.local/share/octave/packages;<br />
pkg local_list /home/<your username>/.local/share/octave/octave_packages;<br />
</nowiki>}}<br />
The {{ic|local_list}} option must be given an absolute path.<br />
|-<br />
| {{Pkg|openscad}}<br />
| {{ic|~/.OpenSCAD}}<br />
| [https://github.com/openscad/openscad/commit/7c3077b0f 7c3077b0f]<br />
| [https://github.com/openscad/openscad/issues/125]<br />
| Does not fully honour XDG Base Directory Specification, see [https://github.com/openscad/openscad/issues/373]<br />
<br />
Currently it [https://github.com/openscad/openscad/blob/master/src/PlatformUtils-posix.cc#L20 hard-codes]{{Dead link|2022|09|23|status=404}} {{ic|~/.local/share}}.<br />
|-<br />
| [[OpenSSL]]<br />
| {{ic|~/.rnd}}<br />
|<br />
|<br />
| Seeding file {{ic|.rnd}}'s location can be set with {{ic|RANDFILE}} environment variable per [https://www.openssl.org/docs/faq.html FAQ].<br />
|-<br />
| {{Pkg|parallel}}<br />
| {{ic|~/.parallel}}<br />
| [https://git.savannah.gnu.org/cgit/parallel.git/commit/?id=685018f532f4e2d24b84eb28d5de3d759f0d1af1 20170422]<br />
|<br />
| {{ic|1=export PARALLEL_HOME="$XDG_CONFIG_HOME"/parallel}}<br />
|-<br />
| [[pass]]<br />
| {{ic|~/.password-store}}<br />
|<br />
|<br />
| {{ic|1=export PASSWORD_STORE_DIR="$XDG_DATA_HOME"/pass}}<br />
|-<br />
| [[Pidgin]]<br />
| {{ic|~/.purple}}<br />
|<br />
| [https://developer.pidgin.im/ticket/4911]<br />
| {{ic|1=pidgin --config="$XDG_DATA_HOME"/purple}}<br />
|-<br />
| [[PostgreSQL]]<br />
| {{ic|~/.psqlrc}}, {{ic|~/.psql_history}}, {{ic|~/.pgpass}}, {{ic|~/.pg_service.conf}}<br />
| 9.2<br />
| [https://www.postgresql.org/docs/current/static/app-psql.html] [https://www.postgresql.org/docs/current/static/libpq-envars.html]<br />
| {{ic|1=export PSQLRC="$XDG_CONFIG_HOME/pg/psqlrc"}}, {{ic|1=export PSQL_HISTORY="$XDG_STATE_HOME/psql_history"}}, {{ic|1=export PGPASSFILE="$XDG_CONFIG_HOME/pg/pgpass"}}, {{ic|1=export PGSERVICEFILE="$XDG_CONFIG_HOME/pg/pg_service.conf"}}<br />
<br />
It is required to create both directories: {{ic|1=mkdir "$XDG_CONFIG_HOME/pg" && mkdir "$XDG_STATE_HOME"}}<br />
|-<br />
| [[PulseAudio]]<br />
| {{ic|~/.esd_auth}}<br />
|<br />
|<br />
| Very likely generated by the {{ic|module-esound-protocol-unix.so}} module. It can be configured to use a different location but it makes much more sense to just comment out this module in {{ic|/etc/pulse/default.pa}} or {{ic|"$XDG_CONFIG_HOME"/pulse/default.pa}}.<br />
|-<br />
| {{Pkg|pyenv}}<br />
| {{ic|~/.pyenv}}<br />
|<br />
| [https://github.com/pyenv/pyenv/issues/139] [https://github.com/pyenv/pyenv/issues/1789]<br />
| {{ic|1=export PYENV_ROOT=$XDG_DATA_HOME/pyenv}}<br />
|-<br />
| {{aur|python-azure-cli}}<br />
| {{ic|~/.azure}}<br />
|<br />
|<br />
| {{ic|1=export AZURE_CONFIG_DIR=$XDG_DATA_HOME/azure}}<br />
|-<br />
| {{AUR|python-grip}}<br />
| {{ic|~/.grip}}<br />
|<br />
|<br />
| {{ic|1=export GRIPHOME="$XDG_CONFIG_HOME/grip"}}<br />
|-<br />
| {{Pkg|python-setuptools}}<br />
| {{ic|~/.python-eggs}}<br />
|<br />
|<br />
| {{ic|1=export PYTHON_EGG_CACHE="$XDG_CACHE_HOME"/python-eggs}}<br />
|-<br />
| {{Pkg|racket}}<br />
| {{ic|~/.racketrc}}, {{ic|~/.racket}}<br />
|<br />
| [https://github.com/racket/racket/issues/2740]<br />
| {{ic|1=export PLTUSERHOME="$XDG_DATA_HOME"/racket}}<br />
|-<br />
| {{AUR|rbenv}}<br />
| {{ic|~/.rbenv}}<br />
|<br />
| [https://github.com/rbenv/rbenv/issues/811] [https://github.com/rbenv/rbenv/issues/1146]<br />
| {{ic|1=export RBENV_ROOT="$XDG_DATA_HOME"/rbenv}}<br />
|-<br />
| {{AUR|nodenv}}<br />
| {{ic|~/.nodenv}}<br />
|<br />
|<br />
| {{ic|1=export NODENV_ROOT="$XDG_DATA_HOME"/nodenv}}<br />
|-<br />
| [[readline]]<br />
| {{ic|~/.inputrc}}<br />
|<br />
|<br />
| {{ic|1=export INPUTRC="$XDG_CONFIG_HOME"/readline/inputrc}}<br />
|-<br />
| {{Pkg|recoll}}<br />
| {{ic|~/.recoll}}<br />
|<br />
|<br />
| {{ic|1=export RECOLL_CONFDIR="$XDG_CONFIG_HOME/recoll"}}<br />
|-<br />
| [[redis]]<br />
| {{ic|~/.rediscli_history}}, {{ic|~/.redisclirc}}<br />
|<br />
|<br />
|{{ic|1=export REDISCLI_HISTFILE="$XDG_DATA_HOME"/redis/rediscli_history}}, {{ic|1=export REDISCLI_RCFILE="$XDG_CONFIG_HOME"/redis/redisclirc}}<br />
|-<br />
| {{Pkg|ripgrep}}<br />
|<br />
|<br />
| [https://github.com/BurntSushi/ripgrep/blob/master/GUIDE.md#configuration-file]<br />
|{{ic|1=export RIPGREP_CONFIG_PATH=$XDG_CONFIG_HOME/ripgrep/config}}<br />
|-<br />
| {{Pkg|rlwrap}}<br />
| {{ic|~/.*_history}}<br />
|<br />
| [https://github.com/hanslub42/rlwrap/issues/25]<br />
| {{ic|1=export RLWRAP_HOME="$XDG_DATA_HOME"/rlwrap}}<br />
|-<br />
| {{Aur|ruby-solargraph}}<br />
| {{ic|~/.solargraph/cache/}}<br />
|<br />
| [https://github.com/castwide/solargraph/blob/master/README.md]<br />
| {{ic|1=export SOLARGRAPH_CACHE=$XDG_CACHE_HOME/solargraph}}<br />
|-<br />
| [[Rust#Rustup]]<br />
| {{ic|~/.rustup}}<br />
|<br />
| [https://github.com/rust-lang-nursery/rustup.rs/issues/247]<br />
| {{ic|1=export RUSTUP_HOME="$XDG_DATA_HOME"/rustup}}<br />
|-<br />
| {{Pkg|sbt}}<br />
| {{ic|~/.sbt}}<br />
{{ic|~/.ivy2}}<br />
|<br />
| [https://github.com/sbt/sbt/issues/3681]<br />
| {{ic|1=sbt -ivy "$XDG_DATA_HOME"/ivy2 -sbt-dir "$XDG_DATA_HOME"/sbt}} (beware [https://github.com/sbt/sbt/issues/3598])<br />
|-<br />
| [[SageMath]]<br />
| {{ic|~/.sage}}<br />
|<br />
|<br />
| {{ic|1=export DOT_SAGE="$XDG_CONFIG_HOME"/sage}}<br />
|-<br />
| [[GNU Screen]]<br />
| {{ic|~/.screenrc}}<br />
|<br />
|<br />
| {{ic|1=export SCREENRC="$XDG_CONFIG_HOME"/screen/screenrc}}<br />
|-<br />
| {{AUR|simplescreenrecorder}}<br />
| {{ic|~/.ssr/}}<br />
| [https://github.com/MaartenBaert/ssr/releases/tag/0.4.3 0.4.3]<br />
| [https://github.com/MaartenBaert/ssr/issues/407]<br />
[https://github.com/MaartenBaert/ssr/issues/813]<br />
| Will use {{ic|$XDG_CONFIG_HOME/simplescreenrecorder/}} ONLY if it already was created otherwise defaults to {{ic|~/.ssr}}<br />
<br />
{{ic|1=mv ~/.ssr "$XDG_CONFIG_HOME"/simplescreenrecorder}}<br />
|-<br />
| [https://www.spacemacs.org/ spacemacs]<br />
| {{ic|~/.spacemacs}}, {{ic|~/.spacemacs.d}}<br />
| [https://github.com/syl20bnr/spacemacs/commit/e1eed07c30ea395fb9cfebc8ec3376dcffbace11]<br />
| [https://github.com/syl20bnr/spacemacs/issues/3589]<br />
| Move the {{ic|~/.spacemacs}} file.<br />
<br />
{{ic|1=export SPACEMACSDIR="$XDG_CONFIG_HOME"/spacemacs}}, {{ic|mv ~/.spacemacs "$SPACEMACSDIR"/init.el}}<br />
<br />
Other files need to be configured like Emacs.<br />
|-<br />
| [[Haskell#Stack]]<br />
| {{ic|~/.stack}}<br />
|<br />
| [https://github.com/commercialhaskell/stack/issues/342]<br />
| {{ic|1=export STACK_ROOT="$XDG_DATA_HOME"/stack}}<br />
|-<br />
| {{Pkg|starship}}<br />
| {{ic|~/.config/starship}}, {{ic|~/.cache/starship}}<br />
| [https://github.com/starship/starship/pull/86] ([https://github.com/starship/starship/releases/tag/v0.2.0 v0.2.0]), [https://github.com/starship/starship/pull/1576] ([https://github.com/starship/starship/releases/tag/v0.45.0 v0.45.0])<br />
| [https://github.com/starship/starship/issues/896#issuecomment-952402978]<br />
| {{ic|1=export STARSHIP_CONFIG="$XDG_CONFIG_HOME"/starship.toml}}, {{ic|1=export STARSHIP_CACHE="$XDG_CACHE_HOME"/starship}}<br />
|-<br />
| [[subversion]]<br />
| {{ic|~/.subversion}}<br />
|<br />
| [https://issues.apache.org/jira/browse/SVN-4599] [https://mail-archives.apache.org/mod_mbox/subversion-users/201204.mbox/%3c4F8FBCC6.4080205@ritsuka.org%3e][https://mail-archives.apache.org/mod_mbox/subversion-dev/201509.mbox/%3C20150917222954.GA20331@teapot%3E]<br />
| {{ic|1=alias svn="svn --config-dir \"$XDG_CONFIG_HOME\"/subversion"}}<br />
|-<br />
| {{Pkg|sudo}}<br />
| {{ic|~/.sudo_as_admin_successful}}<br />
| [https://www.sudo.ws/stable.html#1.9.6 1.9.6]<br />
| [https://github.com/sudo-project/sudo/issues/56] [https://www.sudo.ws/repos/sudo/rev/d77c3876fa95]<br />
| Only present when activated at compile-time (default none). An admin_flag parameter can be used in /etc/sudoers since 1.9.6.<br />
|-<br />
| {{Pkg|task}}<br />
| {{ic|~/.task}}, {{ic|~/.taskrc}}<br />
|<br />
|<br />
| {{ic|1=export TASKDATA="$XDG_DATA_HOME"/task}}, {{ic|1=export TASKRC="$XDG_CONFIG_HOME"/task/taskrc}}}}, {{ic|[https://github.com/GothenburgBitFactory/taskwarrior/pull/2316 Fully supported in version 2.6] (note $XDG_CONFIG_HOME/task/taskrc ''must'' exist, otherwise taskwarrior will offer to create sample config in legacy $HOME/.taskrc location, even if $XDG_CONFIG_HOME is set [https://github.com/GothenburgBitFactory/taskwarrior/pull/2316#issuecomment-732821437][https://github.com/GothenburgBitFactory/taskwarrior/blob/112ac54a57adfb3cc2e6e60dbbb1f5c7d9db3e18/doc/man/task.1.in#L1451])<br />
|-<br />
| Local [[TeX Live]] TeXmf tree, TeXmf caches and config<br />
| {{ic|~/texmf}}, {{ic|~/.texlive/texmf-var}}, {{ic|~/.texlive/texmf-config}}<br />
|<br />
|<br />
| {{ic|1=export TEXMFHOME=$XDG_DATA_HOME/texmf}}, {{ic|1=export TEXMFVAR=$XDG_CACHE_HOME/texlive/texmf-var}}, {{ic|1=export TEXMFCONFIG=$XDG_CONFIG_HOME/texlive/texmf-config}}<br />
|-<br />
| [https://www.texmacs.org/ TeXmacs]<br />
| {{ic|~/.TeXmacs}}<br />
|<br />
|<br />
| {{ic|1=export TEXMACS_HOME_PATH=$XDG_STATE_HOME/texmacs}}<br />
|-<br />
| {{AUR|tiptop}}<br />
| {{ic|~/.tiptoprc}}<br />
|<br />
|<br />
| This will still expect the {{ic|.tiptoprc}} file.<br />
{{ic|tiptop -W "$XDG_CONFIG_HOME"/tiptop}}<br />
|-<br />
| {{AUR|ruby-travis}}<br />
| {{ic|~/.travis/}}<br />
|<br />
| [https://github.com/travis-ci/travis.rb/issues/219]<br />
| {{ic|1=export TRAVIS_CONFIG_PATH=$XDG_CONFIG_HOME/travis}}<br />
|-<br />
| {{Pkg|uncrustify}}<br />
| {{ic|~/.uncrustify.cfg}}<br />
|<br />
|<br />
| {{ic|1=export UNCRUSTIFY_CONFIG="$XDG_CONFIG_HOME"/uncrustify/uncrustify.cfg}}<br />
|-<br />
| [[Unison]]<br />
| {{ic|~/.unison}}<br />
|<br />
|<br />
| {{ic|1=export UNISON="$XDG_DATA_HOME"/unison}}<br />
|-<br />
| {{AUR|units}}<br />
| {{ic|~/.units_history}}<br />
|<br />
|<br />
| {{ic|1=units --history "$XDG_CACHE_HOME"/units_history}}<br />
|-<br />
| [[rxvt-unicode/Tips and tricks#Daemon-client|urxvtd]]<br />
| {{ic|~/.urxvt/urxvtd-hostname}}<br />
|<br />
|<br />
| {{ic|1=export RXVT_SOCKET="$XDG_RUNTIME_DIR"/urxvtd}}<br />
|-<br />
| [[Vagrant]]<br />
| {{ic|~/.vagrant.d}}, {{ic|~/.vagrant.d/aliases}}<br />
|<br />
| [https://www.vagrantup.com/docs/other/environmental-variables.html]<br />
| {{ic|1=export VAGRANT_HOME="$XDG_DATA_HOME"/vagrant}}, {{ic|1=export VAGRANT_ALIAS_FILE="$XDG_DATA_HOME"/vagrant/aliases}}<br />
|-<br />
| [[virtualenv]]<br />
| {{ic|~/.virtualenvs}}<br />
|<br />
|<br />
| {{ic|1=export WORKON_HOME="$XDG_DATA_HOME/virtualenvs"}}<br />
|-<br />
| [[Visual Studio Code]]<br />
| {{ic|~/.vscode-oss/}}<br />
|<br />
| [https://github.com/Microsoft/vscode/issues/3884]<br />
| You can use {{ic|1=export VSCODE_PORTABLE="$XDG_DATA_HOME"/vscode}}, which is not documented and might break unexpectedly.<br />
Setting this makes the editor look for the contents of {{ic|1=.config/Code - OSS}} in {{ic|1=$VSCODE_PORTABLE/user-data}}.<br />
<br />
You can also run Visual Studio with the {{ic|1=--extensions-dir}} flag, such as {{ic|1=code --extensions-dir "$XDG_DATA_HOME/vscode"}}. This is documented and probably will not break as unexpectedly, as it is {{ic|[https://github.com/microsoft/vscode/issues/329 has other use cases]}}.<br />
|-<br />
| {{AUR|VSCodium}}<br />
| {{ic|~/.vscode-oss/}}<br />
|<br />
| [https://github.com/VSCodium/vscodium/issues/561] [https://github.com/VSCodium/vscodium/issues/671]<br />
| You can run VSCodium with the {{ic|1=--extensions-dir}} flag, such as {{ic|1=vscodium --extensions-dir "$XDG_DATA_HOME/vscode"}}. This however won't prevent the creation of {{ic|1=~/.vscode-oss/}} directory.<br />
|-<br />
| {{Pkg|w3m}}<br />
| {{ic|~/.w3m}}<br />
| [https://github.com/tats/w3m/commit/26284ff62781cbc14ff18593a8251409ca730098 26284ff]<br />
| [https://sourceforge.net/p/w3m/feature-requests/31/] [https://github.com/tats/w3m/issues/130]<br />
| {{ic|1=export W3M_DIR="$XDG_STATE_HOME/w3m"}}<br />
|-<br />
| {{Pkg|wakatime}}<br />
| {{ic|~/.wakatime.cfg}}, {{ic|~/.wakatime.data}}, {{ic|~/.wakatime.db}}, {{ic|~/.wakatime.log}}<br />
|<br />
|<br />
| {{ic|1=export WAKATIME_HOME="$XDG_CONFIG_HOME/wakatime"}}<br />
<br />
The directory needs to be created manually<br />
<br />
{{ic|1=mkdir "$XDG_CONFIG_HOME/wakatime"}}<br />
<br />
|-<br />
| [[wget]]<br />
| {{ic|~/.wgetrc}}, {{ic|~/.wget-hsts}}<br />
|<br />
|<br />
| {{ic|1=export WGETRC="$XDG_CONFIG_HOME/wgetrc"}} and add the following as an alias for wget: {{ic|1=wget --hsts-file="$XDG_CACHE_HOME/wget-hsts"}}, or set the {{ic|1=hsts-file}} variable with an absolute path as wgetrc does not support environment variables: {{ic|1=echo hsts-file \= "$XDG_CACHE_HOME"/wget-hsts >> "$XDG_CONFIG_HOME/wgetrc"}}<br />
|-<br />
| [[wine]]<br />
| {{ic|~/.wine}}<br />
|<br />
| [https://bugs.winehq.org/show_bug.cgi?id=20888]<br />
| [[Wine#Winetricks|Winetricks]] uses XDG-alike location below for [[Wine#WINEPREFIX|WINEPREFIX]] management:<br />
{{ic|1=mkdir -p "$XDG_DATA_HOME"/wineprefixes}}, {{ic|1=export WINEPREFIX="$XDG_DATA_HOME"/wineprefixes/default}}<br />
|-<br />
| [[xbindkeys]]<br />
| {{ic|~/.xbindkeysrc}}<br />
|<br />
|<br />
| {{ic|1=xbindkeys -f "$XDG_CONFIG_HOME"/xbindkeys/config}}<br />
|-<br />
| {{Pkg|xorg-xauth}}<br />
| {{ic|~/.Xauthority}}<br />
|<br />
|<br />
| {{ic|1=export XAUTHORITY="$XDG_RUNTIME_DIR"/Xauthority}}<br />
<br />
Note that [[LightDM]] does not allow you to change this variable. If you change it nonetheless, you will not be able to login. Use [[startx]] instead or [https://askubuntu.com/a/961459 configure LightDM]. According to [https://unix.stackexchange.com/a/175331] [[SLiM]] has {{ic|~/.Xauthority}} hardcoded.<br />
<br />
The [[SDDM]] Xauthority path can be changed in its own configuration files as shown below. Unfortunately, it is relative to the home directory.<br />
{{hc|1=/etc/sddm.conf.d/xauth-path.conf|2=[X11]<br />
UserAuthFile=.Xauthority}}<br />
<br />
On Wayland, overriding this may cause Xorg programs to fail to connect to the Xwayland server. For example, both {{pkg|kwin}} and {{pkg|mutter}} use a randomized name, so it cannot be set to a static value.<br />
|-<br />
| [[xinit]]<br />
| {{ic|~/.xinitrc}}, {{ic|~/.xserverrc}}<br />
|<br />
| [https://gitlab.freedesktop.org/xorg/app/xinit/issues/14]<br />
| {{ic|1=export XINITRC="$XDG_CONFIG_HOME"/X11/xinitrc}}, {{ic|1=export XSERVERRC="$XDG_CONFIG_HOME"/X11/xserverrc}}<br />
|-<br />
| {{Pkg|xorg-xrdb}}<br />
| {{ic|~/.Xresources}}, {{ic|~/.Xdefaults}}<br />
|<br />
|<br />
| Ultimately you [https://superuser.com/questions/243914/xresources-or-xdefaults should be] using {{ic|Xresources}} and since these resources are loaded via {{ic|xrdb}} you can specify a path such as {{ic|1=xrdb -load ~/.config/X11/xresources}}.<br />
|-<br />
| [[Xorg]]<br />
| {{ic|~/.xsession}}, {{ic|~/.xsessionrc}}, {{ic|~/.Xsession}}, {{ic|~/.xsession-errors}}<br />
|<br />
|<br />
| These can be added as part of your Xorg init script ({{ic|~/.xinitrc}}) or Xsession start script (which will often be based on {{ic|/etc/X11/Xsession}}).<br />
Depending on where you have configured your {{ic|$XDG_CACHE_HOME}}, you might need to expand the paths yourself.<br />
{{hc|# xsession start script|<nowiki><br />
USERXSESSION="$XDG_CACHE_HOME/X11/xsession"<br />
USERXSESSIONRC="$XDG_CACHE_HOME/X11/xsessionrc"<br />
ALTUSERXSESSION="$XDG_CACHE_HOME/X11/Xsession"<br />
ERRFILE="$XDG_CACHE_HOME/X11/xsession-errors"<br />
</nowiki>}}<br />
Unlike most other examples in this table, actual X11 init scripts will vary a lot between installations.<br />
|-<br />
| {{Pkg|z}}<br />
| {{ic|~/.z}}<br />
|<br />
| [https://github.com/rupa/z/issues/267]<br />
| {{ic|1=export _Z_DATA="$XDG_DATA_HOME/z"}}<br />
|-<br />
| {{Pkg|yarn}}<br />
| {{ic|~/.yarnrc}}, {{ic|~/.yarn/}}, {{ic|~/.yarncache/}}, {{ic|~/.yarn-config/}}<br />
| [https://github.com/yarnpkg/yarn/commit/2d454b5 2d454b5]<br />
| [https://github.com/yarnpkg/yarn/pull/5336] [https://github.com/yarnpkg/yarn/issues/2334]<br />
| {{ic|1=alias yarn='yarn --use-yarnrc "$XDG_CONFIG_HOME/yarn/config"'}}<br />
|-<br />
|}<br />
<br />
=== Hardcoded ===<br />
<br />
{| class="wikitable sortable" style="width: 100%"<br />
! Application<br />
! Legacy Path<br />
! Discussion<br />
! Notes<br />
|-<br />
| [[adb]] & [https://developer.android.com/studio/index.html Android Studio]<br />
| {{ic|~/.android/}}<br />
|<br />
| Despite [https://android.googlesource.com/platform/system/core/+/d5fcafaf41f8ec90986c813f75ec78402096af2d%5E%21/ appearances otherwise], adb will ''always'' generate {{ic|~/.android/adbkeys}}, though it will try keys in {{ic|ADB_VENDOR_KEYS}} as well.<br />
|-<br />
| {{Pkg|aegisub}}<br />
| {{ic|~/.aegisub/}}<br />
| [https://github.com/Aegisub/Aegisub/issues/226]<br />
|<br />
|-<br />
| [[alpine]]<br />
| {{ic|~/.pinerc}}, {{ic|~/.addressbook}}, {{ic|~/.pine-debug[1-4]}}, {{ic|~/.newsrc}}, {{ic|~/.mailcap}}, {{ic|~/.mime.types}}, {{ic|~/.pine-interrupted-mail}}<br />
| <br />
| {{ic|1=alias alpine="alpine -p $XDG_CONFIG_HOME/alpine/pinerc"}}<br />
In the above config file, some locations can be customized using options like {{ic|1=newsrc-path=}} and {{ic|1=address-book=}}.<br />
|-<br />
| [[aMule]]<br />
| {{ic|~/.aMule}}<br />
| [https://bugs.amule.org/view.php?id=1308] [http://forum.amule.org/index.php?topic=18056] [https://github.com/amule-project/amule/issues/254]<br />
|<br />
|-<br />
| [https://osdn.net/projects/anthy/ anthy]<br />
| {{ic|~/.anthy}}<br />
| [https://osdn.net/ticket/browse.php?group_id=14&tid=28397]<br />
|<br />
|-<br />
| [https://directory.apache.org/studio/ Apache Directory Studio]<br />
| {{ic|~/.ApacheDirectoryStudio}}<br />
|<br />
|<br />
|-<br />
| [https://christian.amsuess.com/tools/arandr/ ARandR]<br />
| {{ic|~/.screenlayout}}<br />
| [https://gitlab.com/arandr/arandr/-/issues/45]<br />
|<br />
|-<br />
| [[Arduino]]<br />
| {{ic|~/.arduino15}}, {{ic|~/.jssc}}<br />
| [https://github.com/arduino/Arduino/issues/3915 won't fix]<br />
|<br />
|-<br />
| {{Pkg|arduino-cli}}<br />
| {{ic|~.arduino15/}}<br />
| [https://github.com/arduino/arduino-cli/pull/140]<br />
| {{ic|1=mv ~/.arduino15 $XDG_CONFIG_HOME/arduino15}}<br />
Specify the new directories used by Arduino CLI in arduino-cli.yaml as mentioned in the documentation [https://arduino.github.io/arduino-cli/latest/configuration/ here].<br />
{{ic|1=alias arduino-cli='arduino-cli --config-file $XDG_CONFIG_HOME/arduino15/arduino-cli.yaml'}}<br />
|-<br />
| [http://fixounet.free.fr/avidemux/ Avidemux]<br />
| {{ic|~/.avidemux6}}<br />
| [https://avidemux.org/smif/index.php/topic,19596.0.html]<br />
|<br />
|-<br />
| [[Bash]]<br />
| {{ic|~/.bashrc}}, {{ic|~/.bash_history}}, {{ic|~/.bash_profile}}, {{ic|~/.bash_login}}, {{ic|~/.bash_logout}}<br />
| [https://savannah.gnu.org/support/?108134 won't fix]<br />
| {{ic|1=mkdir -p "$XDG_STATE_HOME"/bash}}<br />
{{ic|1=export HISTFILE="$XDG_STATE_HOME"/bash/history}}<br />
<br />
{{ic|bashrc}} can be sourced from a different location in {{ic|/etc/bash.bashrc}}.<br />
Specify {{ic|--init-file <file>}} as an alternative to {{ic|~/.bashrc}} for interactive shells.<br />
|-<br />
| [[Chef|Berkshelf]]<br />
| {{ic|~/.berkshelf/}}<br />
|<br />
|<br />
|-<br />
| {{AUR|chatty}}<br />
| {{ic|~/.chatty/}}<br />
| [https://github.com/chatty/chatty/issues/273]<br />
|<br />
|-<br />
| {{Pkg|cmake}}<br />
| {{ic|~/.cmake/}}<br />
| [https://gitlab.kitware.com/cmake/cmake/-/issues/22480]<br />
| Used for the user package registry {{ic|~/.cmake/packages/<package>}}, detailed in {{man|7|cmake-packages|User Package Registry}} and [https://gitlab.kitware.com/cmake/community/wikis/doc/tutorials/Package-Registry the Package registry wiki page]. Looks like it's hardcoded, for example in [https://gitlab.kitware.com/cmake/cmake/blob/v3.12.1/Source/cmFindPackageCommand.cxx#L1221 cmFindPackageCommand.cxx].<br />
|-<br />
| [[Cinnamon]]<br />
| {{ic|~/.cinnamon/}}<br />
| [https://github.com/linuxmint/Cinnamon/issues/7807]<br />
|<br />
|-<br />
| {{AUR|conan}}<br />
| {{ic|~/.conan/}}<br />
| [https://github.com/conan-io/conan/issues/2526]<br />
| {{ic|1=export CONAN_USER_HOME="$XDG_CONFIG_HOME"}} will set the directory in which {{ic|.conan/}} is created. It was [https://docs.conan.io/en/latest/reference/env_vars.html#conan-user-home designed to simplify CI], but can be used here too.<br />
|-<br />
| {{AUR|cryptomator}}<br />
| {{ic|~/.Cryptomator}}<br />
| [https://github.com/cryptomator/cryptomator/issues/710]<br />
|<br />
|-<br />
| {{Pkg|ctags}} (universial-ctags)<br />
| {{ic|~/.ctagsrc, .ctags.d}}<br />
| [https://github.com/universal-ctags/ctags/issues/89]<br />
|<br />
|-<br />
| [https://chrome.google.com/webstore/detail/cvim/ihlenndgcmojhcghmfjfneahoeklbjjh cVim]{{Dead link|2022|09|23|status=404}}<br />
| {{ic|~/.cvimrc}}<br />
| [https://github.com/1995eaton/chromium-vim/issues/750]<br />
|<br />
|-<br />
| [[darcs]]<br />
| {{ic|~/.darcs/}}<br />
| [http://bugs.darcs.net/issue2453]<br />
|<br />
|-<br />
| {{Pkg|dart}}<br />
| {{ic|~/.dart}}, {{ic|~/.dartServer}}<br />
| [https://github.com/dart-lang/sdk/issues/41560]<br />
|<br />
|-<br />
| [[dbus]]<br />
| {{ic|~/.dbus/}}<br />
| [https://gitlab.freedesktop.org/dbus/dbus/issues/46]<br />
| Consider using {{pkg|dbus-broker}}, as it does not create or use this directory.<br />
|-<br />
| {{Pkg|devede}}<br />
| {{ic|~/.devedeng}}<br />
|<br />
| Hardcoded [https://gitlab.com/rastersoft/devedeng/blob/f0893b3ff7b14723bd148db35bdfe2d284156d19/src/devedeng/configuration_data.py#L111 here]<br />
|-<br />
| [https://wiki.gnome.org/Apps/Dia Dia]<br />
| {{ic|~/.dia/}}<br />
|<br />
|<br />
|-<br />
| {{Pkg|dotnet-sdk}}<br />
| {{ic|~/.dotnet/}}<br />
| [https://github.com/dotnet/cli/issues/7569]<br />
|<br />
|-<br />
| [[dropbox]]<br />
| {{ic|~/.dropbox/}}<br />
|<br />
|<br />
|-<br />
| [[Eclipse]]<br />
| {{ic|~/.eclipse/}}<br />
| [https://bugs.eclipse.org/bugs/show_bug.cgi?id=200809]<br />
| Option {{ic|1=-Dosgi.configuration.area=@user.home/.config/..}} overrides but must be added to {{ic|"$ECLIPSE_HOME"/eclipse.ini"}} rather than command line which means you must have write access to {{ic|$ECLIPSE_HOME}}. (Arch Linux hard-codes {{ic|$ECLIPSE_HOME}} in {{ic|/usr/bin/eclipse}})<br />
|-<br />
| {{AUR|equalx}}<br />
| {{ic|~/.equalx/}}<br />
| [https://bugs.launchpad.net/equalx/+bug/2014460]<br />
| <br />
|-<br />
| [https://www.fetchmail.info/ Fetchmail]<br />
| {{ic|~/.fetchmailrc}}<br />
|<br />
|<br />
|-<br />
| [[Firefox]]<br />
| {{ic|~/.mozilla/}}<br />
| [https://bugzil.la/259356] [https://phabricator.services.mozilla.com/D6995]<br />
|<br />
|-<br />
| [[Flatpak]]<br />
| {{ic|~/.var/}}<br />
| [https://github.com/flatpak/flatpak/issues/46] [https://github.com/flatpak/flatpak.github.io/issues/191] [https://github.com/flatpak/flatpak/issues/1651 won't fix]<br />
|<br />
|-<br />
| [https://github.com/rwestlund/freesweep freesweep]<br />
| {{ic|~/.sweeprc}}<br />
| [https://github.com/rwestlund/freesweep/issues/9]<br />
|<br />
|-<br />
| {{AUR|gftp}}<br />
| {{ic|~/.gftp/}}<br />
| [https://github.com/masneyb/gftp/issues/99#issuecomment-735030824]<br />
| Following the XDG spec is planned for gftp.<br />
|-<br />
| {{Pkg|ghidra}}<br />
|<br />
| [https://github.com/NationalSecurityAgency/ghidra/issues/908]<br />
|<br />
|-<br />
|-<br />
| {{AUR|gitkraken}}<br />
| {{ic|~/.gitkraken/}}<br />
| [https://feedback.gitkraken.com/suggestions/197923/support-for-moving-the-config-directory-on-linux]<br />
|<br />
|-<br />
| [[GoldenDict]]<br />
| {{ic|~/.goldendict/}}<br />
| [https://github.com/goldendict/goldendict/issues/151]<br />
|<br />
|-<br />
| {{Pkg|gphoto2}}<br />
| {{ic|~/.gphoto}}<br />
| [https://github.com/gphoto/gphoto2/issues/249]<br />
|<br />
|-<br />
| {{Pkg|gramps}}<br />
| {{ic|~/.gramps/}}<br />
| [https://gramps-project.org/bugs/view.php?id=8025]<br />
| 2022 Support XDG base directory specification (for next release Gramps 5.2 ) - Patch https://github.com/gramps-project/gramps/pull/1368<br />
|-<br />
| {{Pkg|groovy}}<br />
| {{ic|~/.groovy/}}<br />
|<br />
|<br />
|-<br />
| {{Pkg|grsync}}<br />
| {{ic|~/.grsync/}}<br />
| [https://sourceforge.net/p/grsync/feature-requests/15/]<br />
|<br />
|-<br />
| {{AUR|google-cloud-cli}}<br />
| {{ic|~/.gsutil/}}<br />
| [https://github.com/GoogleCloudPlatform/gsutil/issues/991]<br />
|<br />
|-<br />
| [http://recordmydesktop.sourceforge.net/about.php gtk-recordMyDesktop]<br />
| {{ic|~/.gtk-recordmydesktop}}<br />
|<br />
|<br />
|-<br />
| {{Pkg|hplip}}<br />
| {{ic|~/.hplip/}}<br />
| [https://bugs.launchpad.net/hplip/+bug/307152]<br />
|<br />
|-<br />
| {{Pkg|hydrogen}}<br />
| {{ic|~/.hydrogen/}}<br />
| [https://github.com/hydrogen-music/hydrogen/issues/643]<br />
|<br />
|-<br />
| [https://www.idris-lang.org/ idris]<br />
| {{ic|~/.idris}}<br />
| [https://github.com/idris-lang/Idris-dev/pull/3456]<br />
|<br />
|-<br />
| {{AUR|itch-setup-bin}}<br />
| {{ic|~/.itch}}<br />
| [https://github.com/itchio/itch/issues/2356 won't fix]<br />
| You can move the Game install location in the app settings.<br />
|-<br />
| [https://sourceforge.net/projects/jmol/ Jmol]<br />
| {{ic|~/.jmol/}}<br />
| [https://sourceforge.net/p/jmol/feature-requests/261/]<br />
|<br />
|-<br />
| {{Aur|lbdb}}<br />
| {{ic|~/.lbdbrc, ~/.lbdb/}}<br />
| [https://github.com/RolandRosenfeld/lbdb/blob/eb162aa9da36f699cf821c6487210c7979fcd8ee/TODO#L18]<br />
|<br />
|-<br />
| [[llpp]]<br />
| {{ic|~/.config/llpp.conf}}<br />
| [https://github.com/moosotc/llpp/issues/180]{{Dead link|2022|09|23|status=404}}<br />
| Added in [https://repo.or.cz/w/llpp.git/commit/3ab86f0 3ab86f0] but subsequently reverted in [https://github.com/moosotc/llpp/commit/e253c9f1 e253c9f1]{{Dead link|2022|09|23|status=404}}<br />
|-<br />
| [[Java]] OpenJDK<br />
| {{ic|~/.java/fonts}}<br />
| [https://bugzilla.redhat.com/show_bug.cgi?id=1154277]<br />
| {{ic|1=export _JAVA_OPTIONS=-Djava.util.prefs.userRoot="$XDG_CONFIG_HOME"/java}}<br />
|-<br />
| [[Java]] OpenJFX<br />
| {{ic|~/.java/webview}}<br />
|<br />
|<br />
|-<br />
| {{Pkg|jgmenu}}<br />
| {{ic|~/.jgmenu-lockfile}}<br />
| [https://github.com/johanmalm/jgmenu/blob/3e48121dc28d06efb23c7901b7e138c2de167a84/src/lockfile.c#L11] [https://github.com/johanmalm/jgmenu/blob/4e45d04502fc5f77392bef0ff33b7bada0cf07d1/src/jgmenu_run#L7]<br />
|<br />
|-<br />
| [https://julialang.org/ julia]<br />
| {{ic|~/.juliarc.jl}}, {{ic|~/.julia_history}}, {{ic|~/.julia}}<br />
| [https://github.com/JuliaLang/julia/issues/4630] [https://github.com/JuliaLang/julia/issues/10016]<br />
| The trailing {{ic|:$JULIA_DEPOT_PATH}} is necessary. See [https://docs.julialang.org/en/v1/manual/environment-variables/#JULIA_DEPOT_PATH]<br />
{{ic|1=export JULIA_DEPOT_PATH="$XDG_DATA_HOME/julia:$JULIA_DEPOT_PATH"}}<br />
|-<br />
| {{AUR|kite}}<br />
| {{ic|~/.kite/}}<br />
| [https://github.com/kiteco/issue-tracker/issues/242]<br />
|<br />
|-<br />
| {{Pkg|kotlin}}<br />
| {{ic|~/.kotlinc_history}}<br />
|<br />
| Related Konan issue: [https://youtrack.jetbrains.com/issue/KT-40763]<br />
|-<br />
| [[Kubernetes]]<br />
| {{ic|~/.kube/}}<br />
| [https://github.com/kubernetes/kubectl/issues/942][https://github.com/kubernetes/kubernetes/issues/56402]<br />
|<br />
|-<br />
| {{AUR|librewolf}}<br />
| {{ic|~/.mozilla}}<br />
{{ic|~/.librewolf}}<br />
| [https://gitlab.com/librewolf-community/browser/linux/-/issues/129]<br />
|<br />
|-<br />
| [https://lldb.llvm.org/ lldb]<br />
| {{ic|~/.lldb}}, {{ic|~/.lldbinit}}<br />
|<br />
|<br />
|-<br />
| [[LMMS]]<br />
| {{ic|~/.lmmsrc.xml}}<br />
| [https://github.com/LMMS/lmms/issues/5869]<br />
|<br />
|-<br />
| [https://www.mathomatic.org/ mathomatic]<br />
| {{ic|~/.mathomaticrc}}, {{ic|~/.matho_history}}<br />
|<br />
| History can be moved by using {{ic|rlwrap mathomatic -r}} with the {{ic|RLWRAP_HOME}} environment set appropriately.<br />
|-<br />
| [[Minecraft]]<br />
| {{ic|~/.minecraft/}}<br />
| [https://bugs.mojang.com/browse/MCL-2563 won't fix]<br />
|<br />
|-<br />
| [[Minetest]]<br />
| {{ic|~/.minetest/}}<br />
| [https://github.com/minetest/minetest/issues/864 won't fix] [https://github.com/minetest/minetest/issues/8151]<br />
|<br />
|-<br />
| {{Pkg|minicom}}<br />
| {{ic|~/.minirc.dfl}}<br />
|<br />
| Upstream has a TODO entry for supporting configuration files under {{ic|~/.config/minicom}}. [https://salsa.debian.org/minicom-team/minicom/-/blob/fe9ff103/TODO#L27]<br />
|-<br />
|-<br />
| [[Mono]]<br />
| {{ic|~/.mono/}}<br />
| [https://github.com/mono/mono/pull/12764]<br />
|<br />
|-<br />
| [https://www.mongodb.org/ mongodb]<br />
| {{ic|~/.mongorc.js}}, {{ic|~/.dbshell}}<br />
| [https://jira.mongodb.org/browse/DOCS-5652?jql=text%20~%20%22.mongorc.js%22]<br />
| [https://stackoverflow.com/questions/22348604/the-mongorc-js-is-not-found-but-there-is-one/22349050#22349050 This Stack Overflow thread] suggests a partial workaround using command-line switch {{ic|--norc}}.<br />
|-<br />
|<br />
| {{ic|~/.netrc}}<br />
|<br />
| Like {{ic|~/.ssh}}, many programs expect this file to be here. These include projects like curl ({{ic|CURLOPT_NETRC_FILE}}), [[ftp]] ({{ic|NETRC}}), [[s-nail]] ({{ic|NETRC}}), etc. While some of them offer alternative configurable locations, many do not such as w3m, wget and lftp.<br />
|-<br />
| [[NetworkManager|nmcli]]<br />
| {{ic|~/.nmcli-history}}<br />
| [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/64]<br />
| Hardcoded to {{ic|g_get_home_dir()}}[https://developer.gnome.org/glib/stable/glib-Miscellaneous-Utility-Functions.html#g-get-home-dir] [https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/main/src/nmcli/connections.c#L6598]<br />
|-<br />
| [[Networkmanager-openvpn]]<br />
| {{ic|~/.cert/nm-openvpn}}<br />
| [https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/issues/35]<br />
|<br />
|-<br />
| {{Aur|ocaml-utop}}<br />
| {{ic|~/.utop-history}}<br />
| [https://github.com/ocaml-community/utop/issues/361]<br />
| There's an open PR to move {{ic|~/.utop-hostory}} to {{ic|$XDG_CACHE_HOME}} [https://github.com/ocaml-community/utop/pull/362]<br />
|-<br />
| [[OpenSSH]]<br />
| {{ic|~/.ssh}}<br />
| [https://bugzilla.mindrot.org/show_bug.cgi?id=2050 won't fix]<br />
| Assumed to be present by many ssh daemons and clients such as DropBear and OpenSSH.<br />
|-<br />
| [https://www.palemoon.org/ palemoon]<br />
| {{ic|~/.moonchild productions}}<br />
| [https://forum.palemoon.org/viewtopic.php?f=5&t=9639]<br />
|<br />
|-<br />
| {{AUR|parsec-bin}}<br />
| {{ic|~/.parsec}}<br />
|<br />
|<br />
|-<br />
| {{AUR|pcsxr}}<br />
| {{ic|~/.pcsxr}}<br />
|<br />
| A {{ic|-cfg}} flag exists, but can only be set relative to {{ic|~/.pcsxr}}.<br />
|-<br />
| [https://perf.wiki.kernel.org/index.php/Main_Page perf]<br />
| {{ic|~/.debug}}<br />
|<br />
| Hardcoded in [https://github.com/torvalds/linux/blob/7d42e98182586f57f376406d033f05fe135edb75/tools/perf/util/config.c#L35 tools/perf/util/config.c]. Commit: [https://github.com/torvalds/linux/commit/45de34bbe3e1b8f4c8bc8ecaf6c915b4b4c545f8]<br />
|-<br />
| [[perl]]<br />
| {{ic|~/.cpan}}, {{ic|~/perl5}}<br />
| [https://github.com/andk/cpanpm/issues/149]<br />
| Perl5's [https://github.com/andk/cpanpm CPAN] expects {{ic|~/.cpan}}<br />
|-<br />
| {{AUR|phoronix-test-suite}}<br />
| {{ic|~/.phoronix-test-suite}}<br />
| [https://github.com/phoronix-test-suite/phoronix-test-suite/issues/453]<br />
|-<br />
| {{AUR|portfolio-performance-bin}}<br />
| {{ic|~/.PortfolioPerformance/}}<br />
| [https://github.com/buchen/portfolio/issues/1922]<br />
| <br />
|-<br />
| various [[shell]]s and [[display manager]]s<br />
| {{ic|~/.profile}}<br />
|<br />
|<br />
|-<br />
| {{Pkg|psensor}}<br />
| {{ic|~/.psensor}}<br />
| [https://gitlab.com/jeanfi/psensor/-/issues/38]<br />
|<br />
|-<br />
| [[python]]<br />
| {{ic|~/.python_history}}<br />
| [https://bugs.python.org/issue29779] [https://bugs.python.org/issue20886] [https://github.com/python/cpython/pull/13208]<br />
| All history from interactive sessions is saved to {{ic|~/.python_history}} by default since [https://bugs.python.org/issue5845 version 3.4]. This can still be customized the same way as in older versions (see [https://docs.python.org/3/library/readline.html?highlight=readline#example this example]), including to [https://bugs.python.org/msg318437 use a custom path] or [https://bugs.python.org/msg265568 disable history saving].<br />
<br />
[https://docs.python.org/3/using/cmdline.html#envvar-PYTHONPYCACHEPREFIX PYTHONPYCACHEPREFIX]: {{ic|1=export PYTHONPYCACHEPREFIX=$XDG_CACHE_HOME/python<br />
}}<br />
[https://docs.python.org/3/using/cmdline.html#envvar-PYTHONUSERBASE PYTHONUSERBASE]: {{ic|1=export PYTHONUSERBASE=$XDG_DATA_HOME/python<br />
}}<br />
|-<br />
| {{Pkg|python-tensorflow}}<br />
| {{ic|~/.keras}}<br />
| [https://github.com/tensorflow/tensorflow/issues/38831]<br />
| The issues is for {{ic|tf.keras}} module<br />
|-<br />
| {{Pkg|qmmp}}<br />
| {{ic|~/.qmmp}}<br />
| [https://sourceforge.net/p/qmmp-dev/tickets/776]<br />
|<br />
|-<br />
| [https://doc.qt.io/qt-5/qtdesigner-manual.html Qt Designer]<br />
| {{ic|~/.designer}}<br />
| [https://bugreports.qt.io/browse/QTCREATORBUG-26093]<br />
|<br />
|-<br />
| [http://rednotebook.sourceforge.net/ RedNotebook]<br />
| {{ic|~/.rednotebook}}<br />
| [https://github.com/jendrikseipp/rednotebook/issues/404]<br />
|<br />
|-<br />
| [https://remarkableapp.github.io/linux.html Remarkable]<br />
| {{ic|~/.remarkable}}<br />
|<br />
|<br />
|-<br />
| {{AUR|renderdoc}}<br />
| {{ic|~/.renderdoc}}<br />
| [https://github.com/baldurk/renderdoc/pull/1741 won't fix]<br />
|<br />
|-<br />
| [https://www.renpy.org/ Ren'Py]<br />
| {{ic|~/.renpy}}<br />
| [https://github.com/renpy/renpy/issues/1377#issuecomment-370118555 won't fix]<br />
|<br />
|-<br />
| [https://gerrit.googlesource.com/git-repo/ repo]<br />
| {{ic|~/.repoconfig}}<br />
| [https://bugs.chromium.org/p/gerrit/issues/detail?id=13997]<br />
|<br />
|-<br />
| {{Pkg|ripgrep-all}}<br />
| {{ic|~/.cache/rga}}<br />
| [https://github.com/phiresky/ripgrep-all/issues/87] [https://github.com/phiresky/ripgrep-all/issues/102] [https://github.com/phiresky/ripgrep-all/issues/129]<br />
| Support for writing the cache at {{ic|$XDG_CACHE_HOME/ripgrep-all}} (+ reading configuration from {{ic|$XDG_CONFIG_HOME/ripgrep-all/config.jsonc}}) was implemented in commit [https://github.com/phiresky/ripgrep-all/commit/963524bbf5ec861cc1d9d2b57e119eb60125751a 963524b], which has not yet been included in a release (as of v0.9.6).<br />
|-<br />
| [[rpm]]<br />
| {{ic|~/.rpmrc}} {{ic|~/.rpmmacros}}<br />
| [https://github.com/rpm-software-management/rpm/issues/2153 Backlog]<br />
| Workaround is to use --rcfile and --macros however this come with sideeffects.<br />
|<br />
|-<br />
| [[SANE]]<br />
| {{ic|~/.sane/}}<br />
|<br />
| {{ic|scanimage}} creates a {{ic|.cal}} file there<br />
|-<br />
| {{Pkg|sbcl}}<br />
| {{ic|~/.sbclrc}}<br />
|<br />
| {{hc|/etc/sbclrc|<br />
(require :asdf)<br />
(setf sb-ext:*userinit-pathname-function*<br />
(lambda () (uiop:xdg-config-home #P"sbcl/sbclrc")))<br />
}}<br />
<br />
Note that this requires root privileges and will change the location of {{ic|~/.sbclrc}} for all users. This can be mitigated by checking for an existing {{ic|~/.sbclrc}} inside the {{ic|lambda}} form.<br />
|-<br />
| [https://www.seamonkey-project.org/ SeaMonkey]<br />
| {{ic|~/.mozilla/seamonkey}}<br />
| [https://bugzil.la/726939]<br />
|<br />
|-<br />
| [https://signal.org/ Signal Desktop]<br />
| <br />
| [https://github.com/signalapp/Signal-Desktop/issues/4975]<br />
| Currently keeps messages in {{ic|~/.config/Signal}}<br />
|-<br />
| [[Snap]]<br />
| {{ic|~/snap/}}<br />
| [https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1575053]<br />
|<br />
|-<br />
| [https://www.gnu.org/software/solfege/solfege.html Solfege]<br />
| {{ic|~/.solfege}}, {{ic|~/.solfegerc}}, {{ic|~/lessonfiles}}<br />
| [https://savannah.gnu.org/bugs/index.php?50251]<br />
|<br />
|-<br />
| [https://spamassassin.apache.org/ SpamAssassin]<br />
| {{ic|~/.spamassassin}}<br />
|<br />
|<br />
|-<br />
| [[SQLite]]<br />
| {{ic|~/.sqlite_history}}, {{ic|~/.sqliterc}}<br />
| [https://www.sqlite.org/src/info/696e82f7c82d1720]<br />
| {{ic|1=export SQLITE_HISTORY=$XDG_DATA_HOME/sqlite_history}}, {{ic|sqlite3 -init "$XDG_CONFIG_HOME"/sqlite3/sqliterc}}<br />
|-<br />
| [[Steam]]<br />
| {{ic|~/.steam}}, {{ic|~/.steampath}}, {{ic|~/.steampid}}<br />
| [https://github.com/ValveSoftware/steam-for-linux/issues/1890]<br />
| Many game engines (Unity 3D, Unreal) follow the specification, but then individual game publishers hardcode the paths in [https://www.ctrl.blog/entry/flatpak-steamcloud-xdg Steam Auto-Cloud] causing game-saves to sync to the wrong directory.<br />
|-<br />
| {{AUR|python-streamlit}}<br />
| {{ic|~/.streamlit}}<br />
| [https://github.com/streamlit/streamlit/issues/2068]<br />
| <br />
|-<br />
| [[TeamSpeak]]<br />
| {{ic|~/.ts3client}}<br />
|<br />
| {{ic|1=export TS3_CONFIG_DIR="$XDG_CONFIG_HOME/ts3client"}}<br />
|-<br />
| {{Pkg|terraform}}<br />
| {{ic|~/.terraform.d/}}<br />
| [https://github.com/hashicorp/terraform/issues/15389]<br />
|<br />
|-<br />
| {{pkg|texinfo}}<br />
| {{ic|~/.infokey}}<br />
|<br />
| {{ic|info --init-file "$XDG_CONFIG_HOME/infokey"}}<br />
|-<br />
| [[Thunderbird]]<br />
| {{ic|~/.thunderbird/}}<br />
| [https://bugzil.la/735285]<br />
|<br />
|-<br />
| [[TigerVNC]]<br />
| {{ic|~/.vnc}}<br />
| [https://github.com/TigerVNC/tigervnc/issues/1195]<br />
|<br />
|-<br />
| [https://gitlab.archlinux.org/remy/texlive-localmanager tllocalmgr]<br />
| {{ic|~/.texlive}}<br />
|<br />
|<br />
|-<br />
| {{Aur|urlview}}<br />
| {{ic|~/.urlview}}<br />
|<br />
| Use fork {{Aur|urlview-xdg-git}} instead. The fork will use {{ic|XDG_CONFIG_HOME/urlview/config}}<br />
|-<br />
| {{AUR|vale}}<br />
| {{ic|~/.vale.ini}}<br />
| [https://github.com/errata-ai/vale/issues/152 won't fix]<br />
| {{ic|vale --config "$XDG_CONFIG_HOME/vale/config.ini"}}<br />
|-<br />
| [[vim]]<br />
| {{ic|~/.vim}}, {{ic|~/.vimrc}}, {{ic|~/.viminfo}}<br />
| [https://github.com/vim/vim/issues/2034]<br />
| Since [https://github.com/vim/vim/commit/6a459902592e2a4ba68 7.3.1178] vim will search for {{ic|~/.vim/vimrc}} if {{ic|~/.vimrc}} is not found.<br />
<br />
{{hc|"$XDG_CONFIG_HOME"/vim/vimrc|<nowiki><br />
set runtimepath^=$XDG_CONFIG_HOME/vim<br />
set runtimepath+=$XDG_DATA_HOME/vim<br />
set runtimepath+=$XDG_CONFIG_HOME/vim/after<br />
<br />
set packpath^=$XDG_DATA_HOME/vim,$XDG_CONFIG_HOME/vim<br />
set packpath+=$XDG_CONFIG_HOME/vim/after,$XDG_DATA_HOME/vim/after<br />
<br />
let g:netrw_home = $XDG_DATA_HOME."/vim"<br />
call mkdir($XDG_DATA_HOME."/vim/spell", 'p')<br />
<br />
set backupdir=$XDG_STATE_HOME/vim/backup | call mkdir(&backupdir, 'p')<br />
set directory=$XDG_STATE_HOME/vim/swap | call mkdir(&directory, 'p')<br />
set undodir=$XDG_STATE_HOME/vim/undo | call mkdir(&undodir, 'p')<br />
set viewdir=$XDG_STATE_HOME/vim/view | call mkdir(&viewdir, 'p')<br />
<br />
if !has('nvim') | set viminfofile=$XDG_STATE_HOME/vim/viminfo | endif<br />
</nowiki>}}<br />
<br />
{{hc|~/.profile|2=<br />
export GVIMINIT='let $MYGVIMRC="$XDG_CONFIG_HOME/vim/gvimrc" {{!}} source $MYGVIMRC'<br />
export VIMINIT='let $MYVIMRC="$XDG_CONFIG_HOME/vim/vimrc" {{!}} source $MYVIMRC'<br />
}}<br />
<br />
{{ic|[G]VIMINIT}} environment variable will also affect Neovim. If separate configs for Vim and Neovim are desired then the following will be a better choice:<br />
export GVIMINIT='let $MYGVIMRC = !has("nvim") ? "$XDG_CONFIG_HOME/vim/gvimrc" : "$XDG_CONFIG_HOME/nvim/init.gvim" | so $MYGVIMRC'<br />
export VIMINIT='let $MYVIMRC = !has("nvim") ? "$XDG_CONFIG_HOME/vim/vimrc" : "$XDG_CONFIG_HOME/nvim/init.vim" | so $MYVIMRC'<br />
<br />
* https://blog.joren.ga/vim-xdg<br />
* https://tlvince.com/vim-respect-xdg<br />
|-<br />
| [http://www.vimperator.org/ vimperator]<br />
| {{ic|~/.vimperatorrc}}<br />
| [https://web.archive.org/web/20200514081339/http://www.mozdev.org/pipermail/vimperator/2009-October/004848.html]<br />
| {{ic|1=export VIMPERATOR_INIT=":source $XDG_CONFIG_HOME/vimperator/vimperatorrc"}}<br />
<br />
{{ic|1=export VIMPERATOR_RUNTIME="$XDG_CONFIG_HOME"/vimperator}}<br />
|-<br />
| {{Pkg|visidata}}<br />
| {{ic|~/.visidata}}<br />
| [https://github.com/saulpw/visidata/issues/487]<br />
|<br />
|-<br />
| [https://w1.fi/ wpa_cli]<br />
| {{ic|~/.wpa_cli_history}}<br />
|<br />
|<br />
|-<br />
| {{Aur|wego}}<br />
| {{ic|~/.wegorc}}<br />
| [https://github.com/schachmat/wego/issues/116]<br />
|<br />
|-<br />
| {{AUR|x2goclient}}<br />
| {{ic|~/.x2goclient}}<br />
|<br />
| {{ic|1=alias x2goclient="x2goclient --home=$HOME/.config"}}<br />
|-<br />
| {{Pkg|xdg-utils}}<br />
| {{ic|~/.gnome}}<br />
| [https://bugs.freedesktop.org/show_bug.cgi?id=90775] [https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/81] [https://gitlab.freedesktop.org/xdg/xdg-utils/-/merge_requests/22]<br />
| For some reason the script {{ic|xdg-desktop-menu}} hard-codes {{ic|1=gnome_user_dir="$HOME/.gnome/apps"}}. This is used by [[chromium]] among others. Bug discussion has moved to gitlab and PR with fix exists, however it is not merged yet.<br />
|-<br />
| {{Pkg|xpdf}}<br />
| {{ic|~/.xpdfrc}}<br />
|<br />
|<br />
|-<br />
| {{AUR|xrdp}}<br />
| {{ic|~/thinclient_drives}}<br />
|<br />
| For the directory {{ic|~/thinclient_drives}}, you may consider editing {{ic|/etc/xrdp/sesman.ini}} and modifying the section {{ic|[Chansrv]}} following the example config.<br />
|-<br />
| [https://github.com/XVimProject/XVim2 XVim2]<br />
| {{ic|~/.xvimrc}}<br />
| [https://github.com/XVimProject/XVim2/issues/389]<br />
|<br />
|-<br />
| [https://yardoc.org YARD]<br />
| {{ic|~/.yard}}<br />
| [https://github.com/lsegal/yard/issues/1230]<br />
| Would accept Pull Request if anyone want to implement it.<br />
|-<br />
| [https://nmap.org/zenmap/ zenmap] {{Pkg|nmap}}<br />
| {{ic|~/.zenmap}}<br />
| [https://seclists.org/nmap-dev/2012/q2/163] [https://github.com/nmap/nmap/issues/590]<br />
|<br />
|-<br />
| {{AUR|zoom}}<br />
| {{ic|~/.zoom}}<br />
|<br />
| Unrecommended: setting the following variable moves the contents of .zoom but the directory itself always gets created. Moreover, it breaks some functionalities eg. being able to start a meeting. {{ic|1=export SSB_HOME="$XDG_DATA_HOME"/zoom}}<br />
|-<br />
| {{AUR|zotero-bin}}<br />
| {{ic|~/.zotero}} {{ic|~/Zotero}}<br />
| [https://github.com/zotero/zotero/issues/1203]<br />
|<br />
|-<br />
| [[zsh]]<br />
| {{ic|~/.zshrc}}, {{ic|~/.zprofile}}, {{ic|~/.zshenv}}, {{ic|~/.zlogin}}, {{ic|~/.zlogout}}, {{ic|~/.histfile}}, {{ic|~/.zcompdump}}, {{ic|~/.zcompcache}}<br />
| [https://www.zsh.org/mla/workers/2013/msg00692.html]<br />
| Consider exporting {{ic|1=ZDOTDIR=$HOME/.config/zsh}} in {{ic|~/.zshenv}} (this is hardcoded due to the bootstrap problem). You could also add this to {{ic|/etc/zsh/zshenv}} and avoid the need for any dotfiles in your {{ic|HOME}}. Doing this however requires root privilege which may not be viable and is system-wide.<br />
<br />
{{ic|1=export HISTFILE="$XDG_STATE_HOME"/zsh/history}}<br />
<br />
{{ic|compinit -d $XDG_CACHE_HOME/zsh/zcompdump-$ZSH_VERSION}} [https://unix.stackexchange.com/questions/391641/separate-path-for-zcompdump-files] /!\ The folder needs to exist<br />
<br />
{{ic|zstyle ':completion:*' cache-path $XDG_CACHE_HOME/zsh/zcompcache}}<br />
<br />
|}<br />
<br />
== Tools ==<br />
<br />
The tool {{aur|xdg-ninja}} detects unwanted files/directories in {{ic|$HOME}} which can be moved to XDG base directories. See [https://github.com/b3nj5m1n/xdg-ninja#xdg-ninja README] for examples.<br />
<br />
== Libraries ==<br />
<br />
; C<br />
: [https://github.com/Jorengarenar/libXDGdirs libXDGdirs]<br />
: [https://github.com/devnev/libxdg-basedir libxdg-basedir]<br />
: [https://github.com/Cloudef/chck/tree/master/chck/xdg C99: Cloudef's simple implementation].<br />
<br />
; C++<br />
: [https://github.com/azubieta/xdg-utils-cxx xdg-utils-cxx]<br />
: [https://sr.ht/~danyspin97/xdgpp xdgpp]<br />
<br />
; Go<br />
: [https://github.com/adrg/xdg adrg/xdg]<br />
: [https://github.com/ProtonMail/go-appdir go-appdir] (deprecated, archived)<br />
: [https://github.com/shibukawa/configdir configdir] (deprecated, abandoned)<br />
: [https://github.com/kyoh86/xdg kyoh86/xdg] (deprecated, archived)<br />
<br />
; Haskell<br />
: Officially in [https://hackage.haskell.org/package/directory directory] since 1.2.3.0 [https://github.com/haskell/directory/commit/ab9d0810ce ab9d0810ce].<br />
: [https://hackage.haskell.org/package/xdg-basedir xdg-basedir]<br />
<br />
; JVM: Java, Kotlin, Clojure, Scala, ...<br />
: [https://github.com/soc/directories-jvm directories-jvm]<br />
<br />
; Perl<br />
: [https://search.cpan.org/dist/File-BaseDir/lib/File/BaseDir.pm File-BaseDir]<br />
<br />
; Python<br />
: [https://freedesktop.org/wiki/Software/pyxdg/ pyxdg]<br />
<br />
; Ruby<br />
: [https://github.com/bkuhlmann/xdg bkuhlmann/xdg]<br />
: [https://github.com/rubyworks/xdg rubyworks/xdg] (deprecated, abandoned)<br />
<br />
; Rust<br />
: [https://github.com/soc/directories-rs directories-rs]<br />
: [https://github.com/whitequark/rust-xdg rust-xdg]<br />
<br />
; Swift<br />
: [https://github.com/Frizlab/swift-xdg swift-xdg]<br />
<br />
; Vala<br />
: Builtin support via [https://valadoc.org/#!api=glib-2.0/GLib.Environment GLib.Environment].<br />
: See {{ic|get_user_cache_dir}}, {{ic|get_user_data_dir}}, {{ic|get_user_config_dir}}, etc.<br />
<br />
== See also ==<br />
<br />
* [https://wiki.gnome.org/Initiatives/GnomeGoals/XDGConfigFolders GNOME Goal: XDG Base Directory Specification Usage]<br />
* [https://web.archive.org/web/20180827160401/plus.google.com/+RobPikeTheHuman/posts/R58WgWwN9jp Rob Pike: "Dotfiles" being hidden is a UNIXv2 mistake].<br />
* {{man|1|systemd-path}}<br />
* {{man|7|file-hierarchy}}<br />
* [https://github.com/grawity/dotfiles/blob/master/.dotfiles.notes Grawity's notes on dotfiles].<br />
* [https://github.com/grawity/dotfiles/blob/master/.environ.notes Grawity's notes on environment variables].<br />
* [https://ploum.net/207-modify-your-application-to-use-xdg-folders/ ploum.net: Modify Your Application to use XDG Folders].<br />
* The [https://pcgamingwiki.com/wiki/Home PCGamingWiki] attempts to document whether or not Linux PC games follow the XDG Base Directory Specification.</div>Baerbeisserhttps://wiki.archlinux.org/index.php?title=Dash&diff=769573Dash2023-02-27T19:21:00Z<p>Baerbeisser: forgot the rdo command in there</p>
<hr />
<div>[[Category:Command-line shells]]<br />
[[ja:Dash]]<br />
{{Related articles start}}<br />
{{Related|Command-line shell}}<br />
{{Related|Bash}}<br />
{{Related articles end}}<br />
<br />
[[wikipedia:Debian_Almquist_shell|Dash (Debian Almquist shell)]] is a modern POSIX-compliant implementation of {{ic|/bin/sh}} [[wikipedia:Bourne shell|(sh, Bourne shell)]].<br />
<br />
Dash is not [[Bash]] compatible, but Bash tries to be mostly compatible with POSIX, and thus Dash.<br />
<br />
Dash shines in:<br />
* Speed of execution. Roughly [https://unix.stackexchange.com/questions/148035/is-dash-or-some-other-shell-faster-than-bash 4x times faster] than Bash and others.<br />
* Very limited resources (disk space, RAM or CPU). As minimalistic as possible - much smaller (134.1 kB vs 6.5 MB installed, 13 kSLOC vs 176 kSLOC) than Bash and others.<br />
* Security. Dash is a long-established, tiny project with simple and long-established functionality; one that is still very much [https://git.kernel.org/cgit/utils/dash/dash.git/log/ alive], and with [https://git.kernel.org/cgit/utils/dash/dash.git/stats/?period=q&ofs=10 many] active developers. Thus, Dash has a much smaller attack surface, while still having many eyes on its code.<br />
* If classic {{ic|/bin/sh}} needed only.<br />
<br />
== Installation ==<br />
<br />
[[Install]] {{Pkg|dash}} or {{AUR|dash-static-musl}}.<br />
<br />
== Use Dash as /bin/sh ==<br />
<br />
Most POSIX compliant scripts specify {{ic|/bin/sh}} at the first line of the script, which means it will run {{ic|/bin/sh}} as the shell, which by default in Arch is a symlink to {{ic|/bin/bash}}.<br />
<br />
You can re-symlink {{ic|/bin/sh}} to {{ic|/bin/dash}}, which can improve system performance, but first you must verify that none of the scripts that are not explicitly {{ic|#!/bin/bash}} require any of Bash's features and that all {{ic|/bin/sh}} scripts are safely POSIX compliant.<br />
<br />
=== Identifying bashisms ===<br />
<br />
Features of bash that are not included in Dash ('bashisms') will not work without being explicitly pointed to {{ic|/bin/bash}}. The following instructions will allow you to find any scripts that may need modification.<br />
<br />
Install {{Pkg|checkbashisms}}.<br />
<br />
==== Common places to check ====<br />
<br />
* All scripts in PATH with a {{ic|#!/bin/sh}} shebang:<br />
$ IFS=:; grep -Irl '#!/bin/sh' $PATH |xargs -r checkbashisms<br />
<br />
* {{ic|pacman -Qlq}} can be used to list all pacman-installed files.<br />
<br />
=== Relinking /bin/sh ===<br />
<br />
Once you have verified that it will not break any functionality, it should be safe to relink {{ic|/bin/sh}}. To do so use the following command:<br />
# ln -sfT dash /usr/bin/sh<br />
Updates of Bash will overwrite {{ic|/bin/sh}} with the default symlink. To prevent this, use the following [[pacman hook]], which will relink {{ic|/bin/sh}} after every affected update:<br />
<br />
[Trigger]<br />
Type = Package<br />
Operation = Install<br />
Operation = Upgrade<br />
Target = bash<br />
<br />
[Action]<br />
Description = Re-pointing /bin/sh symlink to dash...<br />
When = PostTransaction<br />
Exec = /usr/bin/ln -sfT dash /usr/bin/sh<br />
Depends = dash<br />
<br />
This is provided by {{AUR|dashbinsh}}.<br />
<br />
== See also ==<br />
<br />
* https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.org/thread/5XCHETNECFDGMOJ4CXSS535ZMZ4UFYLZ/<br />
* https://launchpad.net/ubuntu/+spec/dash-as-bin-sh<br />
* https://wiki.ubuntu.com/DashAsBinSh</div>Baerbeisserhttps://wiki.archlinux.org/index.php?title=Dash&diff=769251Dash2023-02-24T21:13:52Z<p>Baerbeisser: I argue this chain is nicer.</p>
<hr />
<div>[[Category:Command-line shells]]<br />
[[ja:Dash]]<br />
{{Related articles start}}<br />
{{Related|Command-line shell}}<br />
{{Related|Bash}}<br />
{{Related articles end}}<br />
<br />
[[wikipedia:Debian_Almquist_shell|Dash (Debian Almquist shell)]] is a modern POSIX-compliant implementation of {{ic|/bin/sh}} [[wikipedia:Bourne shell|(sh, Bourne shell)]].<br />
<br />
Dash is not [[Bash]] compatible, but Bash tries to be mostly compatible with POSIX, and thus Dash.<br />
<br />
Dash shines in:<br />
* Speed of execution. Roughly [https://unix.stackexchange.com/questions/148035/is-dash-or-some-other-shell-faster-than-bash 4x times faster] than Bash and others.<br />
* Very limited resources (disk space, RAM or CPU). As minimalistic as possible - much smaller (134.1 kB vs 6.5 MB installed, 13 kSLOC vs 176 kSLOC) than Bash and others.<br />
* Security. Dash is a long-established, tiny project with simple and long-established functionality; one that is still very much [https://git.kernel.org/cgit/utils/dash/dash.git/log/ alive], and with [https://git.kernel.org/cgit/utils/dash/dash.git/stats/?period=q&ofs=10 many] active developers. Thus, Dash has a much smaller attack surface, while still having many eyes on its code.<br />
* If classic {{ic|/bin/sh}} needed only.<br />
<br />
== Installation ==<br />
<br />
[[Install]] {{Pkg|dash}} or {{AUR|dash-static-musl}}.<br />
<br />
== Use Dash as /bin/sh ==<br />
<br />
Most POSIX compliant scripts specify {{ic|/bin/sh}} at the first line of the script, which means it will run {{ic|/bin/sh}} as the shell, which by default in Arch is a symlink to {{ic|/bin/bash}}.<br />
<br />
You can re-symlink {{ic|/bin/sh}} to {{ic|/bin/dash}}, which can improve system performance, but first you must verify that none of the scripts that are not explicitly {{ic|#!/bin/bash}} require any of Bash's features and that all {{ic|/bin/sh}} scripts are safely POSIX compliant.<br />
<br />
=== Identifying bashisms ===<br />
<br />
Features of bash that are not included in Dash ('bashisms') will not work without being explicitly pointed to {{ic|/bin/bash}}. The following instructions will allow you to find any scripts that may need modification.<br />
<br />
Install {{Pkg|checkbashisms}}.<br />
<br />
==== Common places to check ====<br />
<br />
* All scripts in PATH with a {{ic|#!/bin/sh}} shebang:<br />
$ IFS=:; rdo grep -Irl '#!/bin/sh' $PATH |xargs -r checkbashisms<br />
<br />
* {{ic|pacman -Qlq}} can be used to list all pacman-installed files.<br />
<br />
=== Relinking /bin/sh ===<br />
<br />
Once you have verified that it will not break any functionality, it should be safe to relink {{ic|/bin/sh}}. To do so use the following command:<br />
# ln -sfT dash /usr/bin/sh<br />
Updates of Bash will overwrite {{ic|/bin/sh}} with the default symlink. To prevent this, use the following [[pacman hook]], which will relink {{ic|/bin/sh}} after every affected update:<br />
<br />
[Trigger]<br />
Type = Package<br />
Operation = Install<br />
Operation = Upgrade<br />
Target = bash<br />
<br />
[Action]<br />
Description = Re-pointing /bin/sh symlink to dash...<br />
When = PostTransaction<br />
Exec = /usr/bin/ln -sfT dash /usr/bin/sh<br />
Depends = dash<br />
<br />
This is provided by {{AUR|dashbinsh}}.<br />
<br />
== See also ==<br />
<br />
* https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.org/thread/5XCHETNECFDGMOJ4CXSS535ZMZ4UFYLZ/<br />
* https://launchpad.net/ubuntu/+spec/dash-as-bin-sh<br />
* https://wiki.ubuntu.com/DashAsBinSh</div>Baerbeisserhttps://wiki.archlinux.org/index.php?title=Xinit&diff=759166Xinit2022-12-06T15:26:27Z<p>Baerbeisser: startx is a script, not a binary</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Xorg commands]]<br />
[[de:Xinitrc]]<br />
[[es:Xinit]]<br />
[[fr:Xinit]]<br />
[[ja:Xinit]]<br />
[[pt:Xinit]]<br />
[[ru:Xinit]]<br />
[[zh-hans:Xinit]]<br />
{{Related articles start}}<br />
{{Related|Display manager}}<br />
{{Related|Xorg}}<br />
{{Related|xprofile}}<br />
{{Related|Xresources}}<br />
{{Related articles end}}<br />
From [[Wikipedia:xinit|Wikipedia]]:<br />
:The '''xinit''' program allows a user to manually start an [[Xorg]] display server. The {{man|1|startx}} script is a front-end for {{man|1|xinit}}.<br />
<br />
''xinit'' is typically used to start [[window manager]]s or [[desktop environment]]s. While you can also use ''xinit'' to run GUI applications without a window manager, many graphical applications expect an [[Wikipedia:Extended Window Manager Hints|EWMH]] compliant window manager. [[Display manager]]s start [[Xorg]] for you and generally source [[xprofile]].<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|xorg-xinit}} package.<br />
<br />
== Configuration ==<br />
<br />
''xinit'' and ''startx'' take an optional client program argument, see [[#Override xinitrc]]. If you do not provide one they will look for {{ic|~/.xinitrc}} to run as a shell script to start up client programs.<br />
<br />
=== xinitrc ===<br />
<br />
{{ic|~/.xinitrc}} is handy to run programs depending on X and set environment variables on X server startup. If it is present in a user's home directory, ''startx'' and ''xinit'' execute it. Otherwise ''startx'' will run the default {{ic|/etc/X11/xinit/xinitrc}}.<br />
<br />
{{note|''Xinit'' has its own default behaviour instead of executing the file. See {{man|1|xinit}} for details.}}<br />
<br />
This default xinitrc will start a basic environment with [[Twm]], {{Pkg|xorg-xclock}} and [[Xterm]] (assuming that the necessary packages are installed). Therefore, to start a different window manager or desktop environment, first create a copy of the default {{ic|xinitrc}} in your home directory:<br />
<br />
$ cp /etc/X11/xinit/xinitrc ~/.xinitrc<br />
<br />
Then [[Help:Reading#Append, add, create, edit|edit]] the file and replace the default programs with desired commands. Remember that lines following a command using {{ic|exec}} would be ignored. For example, to start {{ic|xscreensaver}} in the background and then start [[Openbox#Standalone|openbox]], use the following:<br />
<br />
{{hc|~/.xinitrc|<br />
...<br />
xscreensaver &<br />
exec openbox-session}}<br />
<br />
{{Note|At the very least, ensure that the last {{ic|if}} block in {{ic|/etc/X11/xinit/xinitrc}} is present in your {{ic|~/.xinitrc}} file to ensure that the scripts in {{ic|/etc/X11/xinit/xinitrc.d}} are sourced.}} <br />
<br />
Long-running programs started before the window manager, such as a screensaver and wallpaper application, must either fork themselves or be run in the background by appending an {{ic|&}} sign. Otherwise, the script would halt and wait for each program to exit before executing the window manager or desktop environment. Note that some programs should instead not be forked, to avoid race bugs, as is the case of [[xrdb]]. Prepending {{ic|exec}} will replace the script process with the window manager process, so that X does not exit even if this process forks to the background.<br />
<br />
=== xserverrc ===<br />
<br />
The {{ic|xserverrc}} file is a shell script responsible for starting up the X server. Both ''startx'' and ''xinit'' execute {{ic|~/.xserverrc}} if it exists, ''startx'' will use {{ic|/etc/X11/xinit/xserverrc}} otherwise.<br />
<br />
In order to maintain an [[General troubleshooting#Session permissions|authenticated session]] with {{ic|logind}} and to prevent bypassing the screen locker by switching terminals, [[Xorg]] has to be started on the same virtual terminal where the login occurred [http://blog.falconindy.com/articles/back-to-basics-with-x-and-systemd.html]. Therefore it is recommended to specify {{ic|vt$XDG_VTNR}} in the {{ic|~/.xserverrc}} file:<br />
<br />
{{hc|~/.xserverrc|<br />
#!/bin/sh<br />
<br />
exec /usr/bin/Xorg -nolisten tcp "$@" vt$XDG_VTNR<br />
}}<br />
<br />
See {{man|1|Xserver}} for a list of all command line options.<br />
<br />
{{Tip|{{ic|-nolisten local}} can be added after {{ic|-nolisten tcp}} to disable abstract sockets of X11 to help with isolation. There is a [https://tstarling.com/blog/2016/06/x11-security-isolation/ quick background] on how this potentially affects X11 security.}}<br />
<br />
Alternatively, if you wish to have the X display on a separate console from the one where the server is invoked, you can do so by using the X server wrapper provided by {{ic|/usr/lib/systemd/systemd-multi-seat-x}}. For convenience, ''xinit'' and ''startx'' can be set up to use this wrapper by modifying your {{ic|~/.xserverrc}}.<br />
<br />
{{Note|To re-enable redirection of the output from X session into the Xorg log file, add the {{ic|-keeptty}} option. See [[Xorg#Session log redirection]] for details.}}<br />
<br />
== Usage ==<br />
<br />
To run Xorg as a regular user, issue:<br />
<br />
$ startx<br />
<br />
Or if [[#xserverrc]] is configured:<br />
<br />
$ xinit -- :1<br />
<br />
{{Note|''xinit'' does not handle multiple displays when another X server is already started. For that you must specify the display by appending {{ic|-- :''display_number''}}, where {{ic|''display_number''}} is {{ic|1}} or more.}}<br />
<br />
Your window manager (or desktop environment) of choice should now start correctly.<br />
<br />
To quit X, run your window manager's exit function (assuming it has one). If it lacks such functionality, run:<br />
<br />
$ pkill -15 Xorg<br />
<br />
{{Note|''pkill'' will kill all running X instances. To specifically kill the window manager on the current virtual terminal, run:<br />
<br />
$ pkill -15 -t tty"$XDG_VTNR" Xorg<br />
}}<br />
<br />
See also {{man|7|signal}}.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Override xinitrc ===<br />
<br />
If you have a working {{ic|~/.xinitrc}} but just want to try other window manager or desktop environment, you can run it by issuing ''startx'' followed by the path to the window manager, for example:<br />
<br />
$ startx /usr/bin/i3<br />
<br />
If the script takes arguments, they need to be quoted to be recognized as part of the first parameter of ''startx'':<br />
<br />
$ startx "/usr/bin/''application'' --''key value''"<br />
<br />
Note that the full path is '''required'''. You can also specify custom options for the [[#xserverrc]] script by appending them after the double dash {{ic|--}} sign:<br />
<br />
$ startx /usr/bin/enlightenment -- -br +bs -dpi 96<br />
<br />
See also {{man|1|startx}}.<br />
<br />
{{Note|1=Since the scripts under {{ic|/etc/X11/xinit/xinitrc.d/}} are skipped, the environment variable {{ic|DISPLAY}} may need be to set. You can try out ''i3'' on the desired display by executing {{ic|1=DISPLAY=:''display_number'' startx /usr/bin/i3}}.}}<br />
<br />
{{Tip|This can be used to start regular GUI programs but without any of the basic window manager features. See also [[#Starting applications without a window manager]] and [[Running program in separate X display]].}}<br />
<br />
=== Autostart X at login ===<br />
<br />
Make sure that ''startx'' is properly [[#Configuration|configured]].<br />
<br />
Place the following in your [[login shell]] initialization file (e.g. {{ic|~/.bash_profile}} for [[Bash]] or {{ic|~/.zprofile}} for [[Zsh]]):<br />
<br />
{{bc|1=<nowiki><br />
if [ -z "${DISPLAY}" ] && [ "${XDG_VTNR}" -eq 1 ]; then<br />
exec startx<br />
fi<br />
</nowiki>}}<br />
<br />
You can replace the {{ic|-eq}} comparison with one like {{ic|-le 3}} (for vt1 to vt3) if you want to use graphical logins on more than one virtual terminal.<br />
<br />
Alternative conditions to detect the virtual terminal include {{ic|<nowiki>"$(tty)" = "/dev/tty1"</nowiki>}}, which does not allow comparison with {{ic|-le}}, and {{ic|<nowiki>"$(fgconsole 2>/dev/null || echo -1)" -eq 1</nowiki>}}, which does not work in [[serial console]]s.<br />
<br />
The {{ic|exec}} command ensures that the user is logged out when the X server exits, crashes or is killed by an attacker. If you want to take the risk and remain logged in when the X session ends, remove {{ic|exec}}.<br />
<br />
See also [[Fish#Start X at login]] and [[Systemd/User#Automatic login into Xorg without display manager]].<br />
<br />
{{Tip|This method can be combined with [[automatic login to virtual console]].}}<br />
<br />
=== Switching between desktop environments/window managers ===<br />
<br />
If you are frequently switching between different desktop environments or window managers, it is convenient to either use a [[display manager]] or expand {{ic|~/.xinitrc}} to make the switching possible.<br />
<br />
The following example shows how to start a particular desktop environment or window manager with an argument:<br />
<br />
{{hc|~/.xinitrc|<nowiki><br />
...<br />
<br />
# Here Xfce is kept as default<br />
session=${1:-xfce}<br />
<br />
case $session in<br />
i3|i3wm ) exec i3;;<br />
kde ) exec startplasma-x11;;<br />
xfce|xfce4 ) exec startxfce4;;<br />
# No known session, try to run it as command<br />
* ) exec $1;;<br />
esac<br />
</nowiki>}}<br />
<br />
To pass the argument ''session'':<br />
<br />
$ xinit ''session''<br />
<br />
or<br />
<br />
$ startx ~/.xinitrc ''session''<br />
<br />
=== Starting applications without a window manager ===<br />
<br />
It is possible to start only specific applications without a window manager, although most likely this is only useful with a single application shown in full-screen mode. For example:<br />
<br />
{{hc|~/.xinitrc|<br />
...<br />
<br />
exec chromium<br />
}}<br />
<br />
Alternatively the binary can be called directly from the command prompt as described in [[#Override xinitrc]].<br />
<br />
With this method you need to set each application's window geometry through its own configuration files (if possible at all).<br />
<br />
{{Tip|This can be useful to launch graphical games, where excluding the overhead of a compositor can help improve the game's performance.}}<br />
<br />
See also [[Display manager#Starting applications without a window manager]].<br />
<br />
=== Output redirection using startx ===<br />
<br />
See [[Xorg#Session log redirection]] for details.</div>Baerbeisserhttps://wiki.archlinux.org/index.php?title=Talk:XDG_Base_Directory&diff=690993Talk:XDG Base Directory2021-08-06T07:38:30Z<p>Baerbeisser: /* Where to put workarounds? */</p>
<hr />
<div>== emacs ==<br />
Has anyone looked at [http://technical-hobbyist.blogspot.com/2014/01/xdg-directories-for-emacs.html? XDG Directories for emacs]? [[User:Ben Creasy|Ben Creasy]] ([[User talk:Ben Creasy|talk]]) 02:40, 15 July 2015 (UTC)<br />
:It seems that still needs an {{ic|~/.emacs}}, so I'm unsure it's a great improvement over a single {{ic|~/.emacs.d}}. That said, you could try to start emacs with the {{ic|--load}} or {{ic|--directory}} argument. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:15, 1 September 2015 (UTC)<br />
<br />
Emacs should be XDG-aware in the first 27.* release [https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=4118297ae2fab4886b20d193ba511a229637aea3 (see this commit)]. Not sure if this warrants updating the table yet. [[User:Odnir|Odnir]] ([[User talk:Odnir|talk]]) 22:00, 28 August 2019 (UTC)<br />
<br />
== Abuse of XDG_CONFIG_HOME ==<br />
<br />
I've just revised the VCS management of my config files and had to put configs of practically all graphical programs to {{ic|.gitignore}}, because they all abuse the {{ic|$XDG_CONFIG_HOME}} path for the purpose of persistent cache, which is {{ic|$XDG_CACHE_HOME}}. A typical config file of a [[Qt]] programs looks [https://gist.github.com/lahwaacz/8a806d9c248cff10ffe0 like this], notice especially the {{ic|recentFileList}}, {{ic|geometry}} and {{ic|windowState}} keys -- IMHO this is exactly the stuff that belongs to {{ic|$XDG_CACHE_HOME}} or {{ic|$XDG_DATA_HOME}}. The [[Qt]] programs are notorious, I suspect the toolkit itself is responsible. But there is more: inkscape puts there {{ic|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... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:12, 21 August 2015 (UTC)<br />
<br />
: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.<br />
: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. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:08, 1 September 2015 (UTC)<br />
<br />
::This is why adding {{ic|*}} to {{ic|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... [[User:Earnest|Earnest]] ([[User talk:Earnest|talk]]) 15:31, 12 September 2015 (UTC)<br />
<br />
== Should command-line history be data or cache? ==<br />
<br />
Should they be placed in {{ic|XDG_DATA_HOME}}, or {{ic|XDG_CACHE_HOME}}? --[[User:Franklin Yu|Franklin Yu]] ([[User talk:Franklin Yu|talk]]) 20:07, 16 May 2017 (UTC)<br />
<br />
: 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 {{ic|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 {{ic|XDG_DATA_HOME}}. —[[User:Ayekat|Ayekat]] ([[User talk:Ayekat|talk]]) 22:30, 16 May 2017 (UTC)<br />
<br />
:: Should it not be XDG_STATE_HOME ($HOME/.local/state) now? [[User:Baerbeisser|Baerbeisser]] ([[User talk:Baerbeisser|talk]]) 07:29, 6 August 2021 (UTC)<br />
<br />
== nvidia uses XDG_CACHE_HOME, how to test CUDA? ==<br />
<br />
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.<br />
<br />
[[User:Cyant|Cyant]] ([[User talk:Cyant|talk]]) 11:55, 25 February 2018 (UTC)<br />
<br />
== Add description of support categories ==<br />
<br />
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:<br />
* app that use a hardcoded {{ic|~/.config}}, not using the XDG variables<br />
* app that use the {{ic|XDG_CONFIG_HOME}} for ''everything''<br />
* app where we can use alternative methods (environment variable, option, ...) for specific files<br />
* app where we can use alternative methods, freeing {{ic|$HOME}}, but not using the correct path for each file (config vs cache vs data) (for example, [[GnuPG]])<br />
<br />
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)?<br />
<br />
[[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 13:58, 14 March 2019 (UTC)<br />
<br />
:''#Partial'' meaning is implied in the [[{{BASEPAGENAME}}#Support]] section:<br />
::''For those not currently supporting the Base Directory Specification, workarounds will be demonstrated to emulate it instead.''<br />
::''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.''<br />
: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''.<br />
:I also propose using fields to describe how different programs work with the spec, instead of just having 3 categories:<br />
:{| class="wikitable sortable"<br />
! Application<br />
! Legacy paths<br />
! Dir split<br />
! XDG variables<br />
! XDG fallback<br />
! Legacy fallback<br />
! Legacy files moved<br />
! Notes<br />
|-<br />
| Cool-utils<br />
| .cool-utils/<br />
| {{No|http://example.com/bug/1}}<br />
| {{Yes|http://example.com/cool-utils/commit/1234567}}<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{No}}<br />
| {{-}}<br />
|-<br />
| git-xmonad<br />
| .git-xmonad<br />
| {{No}}<br />
| {{Y|[http://example.com/bug/1 After legacy]}}<br />
| {{No|http://example.com/bug/1}}<br />
| {{Yes}}<br />
| {{No|http://example.com/bug/1}}<br />
| {{-}}<br />
|-<br />
| Dumper<br />
| .dumper/<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{No}}<br />
| {{Y|Old copies left}}<br />
| {{-}}<br />
|-<br />
| Hostile-app<br />
| .hostileapp/<br />
| {{No|http://example.com/bug/1}}<br />
| {{R|[http://example.com/bug/1 No, WONTFIX]}}<br />
| {{No}}<br />
| {{Yes}}<br />
| {{No}}<br />
| {{ic|1=$ export GARBAGEBIN="$XDG_DATA_HOME"/hostile-app}}<br />
|}<br />
:-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 01:55, 23 April 2020 (UTC)<br />
<br />
::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.<br />
::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.<br />
:: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 12:09, 23 April 2020 (UTC)<br />
<br />
:::I think its definitely confusing/annoying: [https://github.com/xmonad/xmonad/issues/164]. Documenting these particularities would avoid confusion. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 11:27, 25 April 2020 (UTC)<br />
<br />
::::As long as the column title meanings are explained, I think it would certainly be an improvement over the current tables. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:24, 28 April 2020 (UTC)<br />
<br />
== Should Organizations/DEs be mentioned? ==<br />
<br />
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.<br />
<br />
[[User:Hobyamnlyzfsr|Hobyamnlyzfsr]] ([[User talk:Hobyamnlyzfsr|talk]]) 21:35, 9 September 2019 (UTC)<br />
<br />
: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... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:54, 23 April 2020 (UTC)<br />
<br />
== MPV removing XDG support ==<br />
<br />
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<br />
<br />
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).<br />
<br />
{{unsigned|11:45, 9 July 2020|Vash63}}<br />
<br />
: For the record, this change never made it to a release version. It was reverted 2020-10-15.[https://github.com/mpv-player/mpv/pull/8177] [[User:Comic-paralyze-image|Comic-paralyze-image]] ([[User talk:Comic-paralyze-image|talk]]) 22:09, 29 December 2020 (UTC)<br />
<br />
== Android ==<br />
<br />
I updated the android paths, but these might also be valid alternatives:<br />
<br />
$ export ANDROID_EMULATOR_HOME="$ANDROID_PREFS_ROOT"/emulator<br />
$ export ANDROID_AVD_HOME="$XDG_DATA_HOME"/android/avd<br />
<br />
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.<br />
<br />
{{Unsigned|10:55, 23 December 2020 (UTC)|Xerus}}<br />
<br />
Tried the android configuration suggested, as well as `ADB_VENDOR_KEYS` (as suggested by `adb --help`). None of these had any effect.<br />
<br />
[[User:Gesh|Gesh]] ([[User talk:Gesh|talk]]) 19:46, 3 February 2021 (UTC)<br />
<br />
== Vim/Neovim ==<br />
<br />
Hi,<br />
<br />
somehow the suggested way to set up the {{ic|VIMINIT}} environment variable in case you want to use separate configs for Vim and Neovim<br />
<br />
export VIMINIT='if !has('nvim') | source "$XDG_CONFIG_HOME/vim/vimrc" | endif'<br />
<br />
does not work for me. I had to change it to:<br />
<br />
export VIMINIT='if !has("nvim") | let $MYVIMRC="$XDG_CONFIG_HOME/vim/vimrc" | else | let $MYVIMRC="$XDG_CONFIG_HOME/nvim/init.vim" | endif | source $MYVIMRC'<br />
<br />
Besides some minor fixes to the first line, that were necessary to make the first line work in Vim (e.g. double quotes around {{ic|nvim}}), with the first line Neovim didn't load my {{ic|~/.config/nvim/init.vim}}. The second line fixes this issue.<br />
<br />
I'm using Vim version 8.2.1989 and Neovim version 0.4.4.<br />
<br />
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?<br />
<br />
[[User:Schuam|Schuam]] ([[User talk:Schuam|talk]]) 07:41, 29 December 2020 (UTC)<br />
<br />
== Firefox ==<br />
<br />
Mozilla Firefox puts the default profile in {{ic|~/.mozilla/}}. There is a workaround for "moving" it out of the home directory, though — Firefox has the command line option {{ic|--profile}} (I can't actually find documentation on this online, and there's no Firefox man page, but it's in the {{ic|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 {{ic|firefox}} to use a profile from, say, {{ic|$XDG_DATA_HOME/mozilla/firefox}}, then {{ic|~/.mozilla/}} basically becomes useless.<br />
<br />
Note that even when specifying a different profile directory, {{ic|~/.mozilla/}} <i>still</i> 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 {{ic|~/.mozilla/}} directory immediately after its creation.<br />
<br />
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.<br />
<br />
[[User:Inco|Inco]] ([[User talk:Inco|talk]]) 20:52, 20 April 2021 (UTC)<br />
<br />
:It should be added to the [[Firefox]] page and then linked from the notes column. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:58, 20 April 2021 (UTC)<br />
<br />
:The {{ic|~/.mozilla}} directory gets recreated during the runtime of Firefox. I wrote a wrapper which solves this issue: [https://github.com/Jorengarenar/MozXDG MozXDG] -- [[User:Jorengarenar|Jorengarenar]] ([[User talk:Jorengarenar|talk]]) 09:05, 21 April 2021 (UTC)<br />
<br />
== Obscure software ==<br />
<br />
Was wondering how much sense it would make to add obscure/rare software to the list, such as games. I was specifically thinking about [https://aur.archlinux.org/packages/maptool-bin/ MapTool] which places files in the home directory but can be configured not to.<br />
[[User:Maze|Maze]] ([[User talk:Maze|talk]]) 03:04, 24 June 2021 (UTC)<br />
<br />
:80% of this page is already for obscure software, so I don't see how it would make a difference. -- [[User:MrX|MrX]] ([[User talk:MrX|talk]]) 11:47, 24 June 2021 (UTC)<br />
<br />
== Where to put workarounds? ==<br />
<br />
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.<br />
<br />
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/...).<br />
<br />
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? <br />
<br />
[[User:Baerbeisser|Baerbeisser]] ([[User talk:Baerbeisser|talk]]) 07:23, 6 August 2021 (UTC)</div>Baerbeisserhttps://wiki.archlinux.org/index.php?title=Talk:XDG_Base_Directory&diff=690992Talk:XDG Base Directory2021-08-06T07:38:05Z<p>Baerbeisser: /* Where to put workarounds? */</p>
<hr />
<div>== emacs ==<br />
Has anyone looked at [http://technical-hobbyist.blogspot.com/2014/01/xdg-directories-for-emacs.html? XDG Directories for emacs]? [[User:Ben Creasy|Ben Creasy]] ([[User talk:Ben Creasy|talk]]) 02:40, 15 July 2015 (UTC)<br />
:It seems that still needs an {{ic|~/.emacs}}, so I'm unsure it's a great improvement over a single {{ic|~/.emacs.d}}. That said, you could try to start emacs with the {{ic|--load}} or {{ic|--directory}} argument. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:15, 1 September 2015 (UTC)<br />
<br />
Emacs should be XDG-aware in the first 27.* release [https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=4118297ae2fab4886b20d193ba511a229637aea3 (see this commit)]. Not sure if this warrants updating the table yet. [[User:Odnir|Odnir]] ([[User talk:Odnir|talk]]) 22:00, 28 August 2019 (UTC)<br />
<br />
== Abuse of XDG_CONFIG_HOME ==<br />
<br />
I've just revised the VCS management of my config files and had to put configs of practically all graphical programs to {{ic|.gitignore}}, because they all abuse the {{ic|$XDG_CONFIG_HOME}} path for the purpose of persistent cache, which is {{ic|$XDG_CACHE_HOME}}. A typical config file of a [[Qt]] programs looks [https://gist.github.com/lahwaacz/8a806d9c248cff10ffe0 like this], notice especially the {{ic|recentFileList}}, {{ic|geometry}} and {{ic|windowState}} keys -- IMHO this is exactly the stuff that belongs to {{ic|$XDG_CACHE_HOME}} or {{ic|$XDG_DATA_HOME}}. The [[Qt]] programs are notorious, I suspect the toolkit itself is responsible. But there is more: inkscape puts there {{ic|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... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:12, 21 August 2015 (UTC)<br />
<br />
: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.<br />
: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. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:08, 1 September 2015 (UTC)<br />
<br />
::This is why adding {{ic|*}} to {{ic|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... [[User:Earnest|Earnest]] ([[User talk:Earnest|talk]]) 15:31, 12 September 2015 (UTC)<br />
<br />
== Should command-line history be data or cache? ==<br />
<br />
Should they be placed in {{ic|XDG_DATA_HOME}}, or {{ic|XDG_CACHE_HOME}}? --[[User:Franklin Yu|Franklin Yu]] ([[User talk:Franklin Yu|talk]]) 20:07, 16 May 2017 (UTC)<br />
<br />
: 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 {{ic|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 {{ic|XDG_DATA_HOME}}. —[[User:Ayekat|Ayekat]] ([[User talk:Ayekat|talk]]) 22:30, 16 May 2017 (UTC)<br />
<br />
:: Should it not be XDG_STATE_HOME ($HOME/.local/state) now? [[User:Baerbeisser|Baerbeisser]] ([[User talk:Baerbeisser|talk]]) 07:29, 6 August 2021 (UTC)<br />
<br />
== nvidia uses XDG_CACHE_HOME, how to test CUDA? ==<br />
<br />
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.<br />
<br />
[[User:Cyant|Cyant]] ([[User talk:Cyant|talk]]) 11:55, 25 February 2018 (UTC)<br />
<br />
== Add description of support categories ==<br />
<br />
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:<br />
* app that use a hardcoded {{ic|~/.config}}, not using the XDG variables<br />
* app that use the {{ic|XDG_CONFIG_HOME}} for ''everything''<br />
* app where we can use alternative methods (environment variable, option, ...) for specific files<br />
* app where we can use alternative methods, freeing {{ic|$HOME}}, but not using the correct path for each file (config vs cache vs data) (for example, [[GnuPG]])<br />
<br />
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)?<br />
<br />
[[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 13:58, 14 March 2019 (UTC)<br />
<br />
:''#Partial'' meaning is implied in the [[{{BASEPAGENAME}}#Support]] section:<br />
::''For those not currently supporting the Base Directory Specification, workarounds will be demonstrated to emulate it instead.''<br />
::''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.''<br />
: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''.<br />
:I also propose using fields to describe how different programs work with the spec, instead of just having 3 categories:<br />
:{| class="wikitable sortable"<br />
! Application<br />
! Legacy paths<br />
! Dir split<br />
! XDG variables<br />
! XDG fallback<br />
! Legacy fallback<br />
! Legacy files moved<br />
! Notes<br />
|-<br />
| Cool-utils<br />
| .cool-utils/<br />
| {{No|http://example.com/bug/1}}<br />
| {{Yes|http://example.com/cool-utils/commit/1234567}}<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{No}}<br />
| {{-}}<br />
|-<br />
| git-xmonad<br />
| .git-xmonad<br />
| {{No}}<br />
| {{Y|[http://example.com/bug/1 After legacy]}}<br />
| {{No|http://example.com/bug/1}}<br />
| {{Yes}}<br />
| {{No|http://example.com/bug/1}}<br />
| {{-}}<br />
|-<br />
| Dumper<br />
| .dumper/<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{No}}<br />
| {{Y|Old copies left}}<br />
| {{-}}<br />
|-<br />
| Hostile-app<br />
| .hostileapp/<br />
| {{No|http://example.com/bug/1}}<br />
| {{R|[http://example.com/bug/1 No, WONTFIX]}}<br />
| {{No}}<br />
| {{Yes}}<br />
| {{No}}<br />
| {{ic|1=$ export GARBAGEBIN="$XDG_DATA_HOME"/hostile-app}}<br />
|}<br />
:-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 01:55, 23 April 2020 (UTC)<br />
<br />
::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.<br />
::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.<br />
:: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 12:09, 23 April 2020 (UTC)<br />
<br />
:::I think its definitely confusing/annoying: [https://github.com/xmonad/xmonad/issues/164]. Documenting these particularities would avoid confusion. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 11:27, 25 April 2020 (UTC)<br />
<br />
::::As long as the column title meanings are explained, I think it would certainly be an improvement over the current tables. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:24, 28 April 2020 (UTC)<br />
<br />
== Should Organizations/DEs be mentioned? ==<br />
<br />
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.<br />
<br />
[[User:Hobyamnlyzfsr|Hobyamnlyzfsr]] ([[User talk:Hobyamnlyzfsr|talk]]) 21:35, 9 September 2019 (UTC)<br />
<br />
: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... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:54, 23 April 2020 (UTC)<br />
<br />
== MPV removing XDG support ==<br />
<br />
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<br />
<br />
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).<br />
<br />
{{unsigned|11:45, 9 July 2020|Vash63}}<br />
<br />
: For the record, this change never made it to a release version. It was reverted 2020-10-15.[https://github.com/mpv-player/mpv/pull/8177] [[User:Comic-paralyze-image|Comic-paralyze-image]] ([[User talk:Comic-paralyze-image|talk]]) 22:09, 29 December 2020 (UTC)<br />
<br />
== Android ==<br />
<br />
I updated the android paths, but these might also be valid alternatives:<br />
<br />
$ export ANDROID_EMULATOR_HOME="$ANDROID_PREFS_ROOT"/emulator<br />
$ export ANDROID_AVD_HOME="$XDG_DATA_HOME"/android/avd<br />
<br />
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.<br />
<br />
{{Unsigned|10:55, 23 December 2020 (UTC)|Xerus}}<br />
<br />
Tried the android configuration suggested, as well as `ADB_VENDOR_KEYS` (as suggested by `adb --help`). None of these had any effect.<br />
<br />
[[User:Gesh|Gesh]] ([[User talk:Gesh|talk]]) 19:46, 3 February 2021 (UTC)<br />
<br />
== Vim/Neovim ==<br />
<br />
Hi,<br />
<br />
somehow the suggested way to set up the {{ic|VIMINIT}} environment variable in case you want to use separate configs for Vim and Neovim<br />
<br />
export VIMINIT='if !has('nvim') | source "$XDG_CONFIG_HOME/vim/vimrc" | endif'<br />
<br />
does not work for me. I had to change it to:<br />
<br />
export VIMINIT='if !has("nvim") | let $MYVIMRC="$XDG_CONFIG_HOME/vim/vimrc" | else | let $MYVIMRC="$XDG_CONFIG_HOME/nvim/init.vim" | endif | source $MYVIMRC'<br />
<br />
Besides some minor fixes to the first line, that were necessary to make the first line work in Vim (e.g. double quotes around {{ic|nvim}}), with the first line Neovim didn't load my {{ic|~/.config/nvim/init.vim}}. The second line fixes this issue.<br />
<br />
I'm using Vim version 8.2.1989 and Neovim version 0.4.4.<br />
<br />
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?<br />
<br />
[[User:Schuam|Schuam]] ([[User talk:Schuam|talk]]) 07:41, 29 December 2020 (UTC)<br />
<br />
== Firefox ==<br />
<br />
Mozilla Firefox puts the default profile in {{ic|~/.mozilla/}}. There is a workaround for "moving" it out of the home directory, though — Firefox has the command line option {{ic|--profile}} (I can't actually find documentation on this online, and there's no Firefox man page, but it's in the {{ic|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 {{ic|firefox}} to use a profile from, say, {{ic|$XDG_DATA_HOME/mozilla/firefox}}, then {{ic|~/.mozilla/}} basically becomes useless.<br />
<br />
Note that even when specifying a different profile directory, {{ic|~/.mozilla/}} <i>still</i> 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 {{ic|~/.mozilla/}} directory immediately after its creation.<br />
<br />
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.<br />
<br />
[[User:Inco|Inco]] ([[User talk:Inco|talk]]) 20:52, 20 April 2021 (UTC)<br />
<br />
:It should be added to the [[Firefox]] page and then linked from the notes column. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:58, 20 April 2021 (UTC)<br />
<br />
:The {{ic|~/.mozilla}} directory gets recreated during the runtime of Firefox. I wrote a wrapper which solves this issue: [https://github.com/Jorengarenar/MozXDG MozXDG] -- [[User:Jorengarenar|Jorengarenar]] ([[User talk:Jorengarenar|talk]]) 09:05, 21 April 2021 (UTC)<br />
<br />
== Obscure software ==<br />
<br />
Was wondering how much sense it would make to add obscure/rare software to the list, such as games. I was specifically thinking about [https://aur.archlinux.org/packages/maptool-bin/ MapTool] which places files in the home directory but can be configured not to.<br />
[[User:Maze|Maze]] ([[User talk:Maze|talk]]) 03:04, 24 June 2021 (UTC)<br />
<br />
:80% of this page is already for obscure software, so I don't see how it would make a difference. -- [[User:MrX|MrX]] ([[User talk:MrX|talk]]) 11:47, 24 June 2021 (UTC)<br />
<br />
== Where to put workarounds? ==<br />
<br />
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.<br />
<br />
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/...).<br />
<br />
But the global settings? Should they go to /etc/X11/xinit/xinitrc.d/? And things like bahs HISTFILE to /etc/profile.d and .../Xsession edited to load /etc/profile? <br />
<br />
[[User:Baerbeisser|Baerbeisser]] ([[User talk:Baerbeisser|talk]]) 07:23, 6 August 2021 (UTC)</div>Baerbeisserhttps://wiki.archlinux.org/index.php?title=Talk:XDG_Base_Directory&diff=690990Talk:XDG Base Directory2021-08-06T07:29:29Z<p>Baerbeisser: /* Should command-line history be data or cache? */</p>
<hr />
<div>== emacs ==<br />
Has anyone looked at [http://technical-hobbyist.blogspot.com/2014/01/xdg-directories-for-emacs.html? XDG Directories for emacs]? [[User:Ben Creasy|Ben Creasy]] ([[User talk:Ben Creasy|talk]]) 02:40, 15 July 2015 (UTC)<br />
:It seems that still needs an {{ic|~/.emacs}}, so I'm unsure it's a great improvement over a single {{ic|~/.emacs.d}}. That said, you could try to start emacs with the {{ic|--load}} or {{ic|--directory}} argument. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:15, 1 September 2015 (UTC)<br />
<br />
Emacs should be XDG-aware in the first 27.* release [https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=4118297ae2fab4886b20d193ba511a229637aea3 (see this commit)]. Not sure if this warrants updating the table yet. [[User:Odnir|Odnir]] ([[User talk:Odnir|talk]]) 22:00, 28 August 2019 (UTC)<br />
<br />
== Abuse of XDG_CONFIG_HOME ==<br />
<br />
I've just revised the VCS management of my config files and had to put configs of practically all graphical programs to {{ic|.gitignore}}, because they all abuse the {{ic|$XDG_CONFIG_HOME}} path for the purpose of persistent cache, which is {{ic|$XDG_CACHE_HOME}}. A typical config file of a [[Qt]] programs looks [https://gist.github.com/lahwaacz/8a806d9c248cff10ffe0 like this], notice especially the {{ic|recentFileList}}, {{ic|geometry}} and {{ic|windowState}} keys -- IMHO this is exactly the stuff that belongs to {{ic|$XDG_CACHE_HOME}} or {{ic|$XDG_DATA_HOME}}. The [[Qt]] programs are notorious, I suspect the toolkit itself is responsible. But there is more: inkscape puts there {{ic|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... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:12, 21 August 2015 (UTC)<br />
<br />
: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.<br />
: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. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:08, 1 September 2015 (UTC)<br />
<br />
::This is why adding {{ic|*}} to {{ic|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... [[User:Earnest|Earnest]] ([[User talk:Earnest|talk]]) 15:31, 12 September 2015 (UTC)<br />
<br />
== Should command-line history be data or cache? ==<br />
<br />
Should they be placed in {{ic|XDG_DATA_HOME}}, or {{ic|XDG_CACHE_HOME}}? --[[User:Franklin Yu|Franklin Yu]] ([[User talk:Franklin Yu|talk]]) 20:07, 16 May 2017 (UTC)<br />
<br />
: 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 {{ic|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 {{ic|XDG_DATA_HOME}}. —[[User:Ayekat|Ayekat]] ([[User talk:Ayekat|talk]]) 22:30, 16 May 2017 (UTC)<br />
<br />
:: Should it not be XDG_STATE_HOME ($HOME/.local/state) now? [[User:Baerbeisser|Baerbeisser]] ([[User talk:Baerbeisser|talk]]) 07:29, 6 August 2021 (UTC)<br />
<br />
== nvidia uses XDG_CACHE_HOME, how to test CUDA? ==<br />
<br />
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.<br />
<br />
[[User:Cyant|Cyant]] ([[User talk:Cyant|talk]]) 11:55, 25 February 2018 (UTC)<br />
<br />
== Add description of support categories ==<br />
<br />
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:<br />
* app that use a hardcoded {{ic|~/.config}}, not using the XDG variables<br />
* app that use the {{ic|XDG_CONFIG_HOME}} for ''everything''<br />
* app where we can use alternative methods (environment variable, option, ...) for specific files<br />
* app where we can use alternative methods, freeing {{ic|$HOME}}, but not using the correct path for each file (config vs cache vs data) (for example, [[GnuPG]])<br />
<br />
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)?<br />
<br />
[[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 13:58, 14 March 2019 (UTC)<br />
<br />
:''#Partial'' meaning is implied in the [[{{BASEPAGENAME}}#Support]] section:<br />
::''For those not currently supporting the Base Directory Specification, workarounds will be demonstrated to emulate it instead.''<br />
::''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.''<br />
: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''.<br />
:I also propose using fields to describe how different programs work with the spec, instead of just having 3 categories:<br />
:{| class="wikitable sortable"<br />
! Application<br />
! Legacy paths<br />
! Dir split<br />
! XDG variables<br />
! XDG fallback<br />
! Legacy fallback<br />
! Legacy files moved<br />
! Notes<br />
|-<br />
| Cool-utils<br />
| .cool-utils/<br />
| {{No|http://example.com/bug/1}}<br />
| {{Yes|http://example.com/cool-utils/commit/1234567}}<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{No}}<br />
| {{-}}<br />
|-<br />
| git-xmonad<br />
| .git-xmonad<br />
| {{No}}<br />
| {{Y|[http://example.com/bug/1 After legacy]}}<br />
| {{No|http://example.com/bug/1}}<br />
| {{Yes}}<br />
| {{No|http://example.com/bug/1}}<br />
| {{-}}<br />
|-<br />
| Dumper<br />
| .dumper/<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{No}}<br />
| {{Y|Old copies left}}<br />
| {{-}}<br />
|-<br />
| Hostile-app<br />
| .hostileapp/<br />
| {{No|http://example.com/bug/1}}<br />
| {{R|[http://example.com/bug/1 No, WONTFIX]}}<br />
| {{No}}<br />
| {{Yes}}<br />
| {{No}}<br />
| {{ic|1=$ export GARBAGEBIN="$XDG_DATA_HOME"/hostile-app}}<br />
|}<br />
:-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 01:55, 23 April 2020 (UTC)<br />
<br />
::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.<br />
::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.<br />
:: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 12:09, 23 April 2020 (UTC)<br />
<br />
:::I think its definitely confusing/annoying: [https://github.com/xmonad/xmonad/issues/164]. Documenting these particularities would avoid confusion. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 11:27, 25 April 2020 (UTC)<br />
<br />
::::As long as the column title meanings are explained, I think it would certainly be an improvement over the current tables. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:24, 28 April 2020 (UTC)<br />
<br />
== Should Organizations/DEs be mentioned? ==<br />
<br />
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.<br />
<br />
[[User:Hobyamnlyzfsr|Hobyamnlyzfsr]] ([[User talk:Hobyamnlyzfsr|talk]]) 21:35, 9 September 2019 (UTC)<br />
<br />
: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... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:54, 23 April 2020 (UTC)<br />
<br />
== MPV removing XDG support ==<br />
<br />
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<br />
<br />
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).<br />
<br />
{{unsigned|11:45, 9 July 2020|Vash63}}<br />
<br />
: For the record, this change never made it to a release version. It was reverted 2020-10-15.[https://github.com/mpv-player/mpv/pull/8177] [[User:Comic-paralyze-image|Comic-paralyze-image]] ([[User talk:Comic-paralyze-image|talk]]) 22:09, 29 December 2020 (UTC)<br />
<br />
== Android ==<br />
<br />
I updated the android paths, but these might also be valid alternatives:<br />
<br />
$ export ANDROID_EMULATOR_HOME="$ANDROID_PREFS_ROOT"/emulator<br />
$ export ANDROID_AVD_HOME="$XDG_DATA_HOME"/android/avd<br />
<br />
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.<br />
<br />
{{Unsigned|10:55, 23 December 2020 (UTC)|Xerus}}<br />
<br />
Tried the android configuration suggested, as well as `ADB_VENDOR_KEYS` (as suggested by `adb --help`). None of these had any effect.<br />
<br />
[[User:Gesh|Gesh]] ([[User talk:Gesh|talk]]) 19:46, 3 February 2021 (UTC)<br />
<br />
== Vim/Neovim ==<br />
<br />
Hi,<br />
<br />
somehow the suggested way to set up the {{ic|VIMINIT}} environment variable in case you want to use separate configs for Vim and Neovim<br />
<br />
export VIMINIT='if !has('nvim') | source "$XDG_CONFIG_HOME/vim/vimrc" | endif'<br />
<br />
does not work for me. I had to change it to:<br />
<br />
export VIMINIT='if !has("nvim") | let $MYVIMRC="$XDG_CONFIG_HOME/vim/vimrc" | else | let $MYVIMRC="$XDG_CONFIG_HOME/nvim/init.vim" | endif | source $MYVIMRC'<br />
<br />
Besides some minor fixes to the first line, that were necessary to make the first line work in Vim (e.g. double quotes around {{ic|nvim}}), with the first line Neovim didn't load my {{ic|~/.config/nvim/init.vim}}. The second line fixes this issue.<br />
<br />
I'm using Vim version 8.2.1989 and Neovim version 0.4.4.<br />
<br />
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?<br />
<br />
[[User:Schuam|Schuam]] ([[User talk:Schuam|talk]]) 07:41, 29 December 2020 (UTC)<br />
<br />
== Firefox ==<br />
<br />
Mozilla Firefox puts the default profile in {{ic|~/.mozilla/}}. There is a workaround for "moving" it out of the home directory, though — Firefox has the command line option {{ic|--profile}} (I can't actually find documentation on this online, and there's no Firefox man page, but it's in the {{ic|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 {{ic|firefox}} to use a profile from, say, {{ic|$XDG_DATA_HOME/mozilla/firefox}}, then {{ic|~/.mozilla/}} basically becomes useless.<br />
<br />
Note that even when specifying a different profile directory, {{ic|~/.mozilla/}} <i>still</i> 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 {{ic|~/.mozilla/}} directory immediately after its creation.<br />
<br />
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.<br />
<br />
[[User:Inco|Inco]] ([[User talk:Inco|talk]]) 20:52, 20 April 2021 (UTC)<br />
<br />
:It should be added to the [[Firefox]] page and then linked from the notes column. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:58, 20 April 2021 (UTC)<br />
<br />
:The {{ic|~/.mozilla}} directory gets recreated during the runtime of Firefox. I wrote a wrapper which solves this issue: [https://github.com/Jorengarenar/MozXDG MozXDG] -- [[User:Jorengarenar|Jorengarenar]] ([[User talk:Jorengarenar|talk]]) 09:05, 21 April 2021 (UTC)<br />
<br />
== Obscure software ==<br />
<br />
Was wondering how much sense it would make to add obscure/rare software to the list, such as games. I was specifically thinking about [https://aur.archlinux.org/packages/maptool-bin/ MapTool] which places files in the home directory but can be configured not to.<br />
[[User:Maze|Maze]] ([[User talk:Maze|talk]]) 03:04, 24 June 2021 (UTC)<br />
<br />
:80% of this page is already for obscure software, so I don't see how it would make a difference. -- [[User:MrX|MrX]] ([[User talk:MrX|talk]]) 11:47, 24 June 2021 (UTC)<br />
<br />
== Where to put workarounds? ==<br />
<br />
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.<br />
<br />
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/...).<br />
<br />
But the global settings? Varibles are somehow not all set if put in /etc/profile.d, even if loaded from .../Xsession. Should they go to /etc/X11/xinit/xinitrc.d/?<br />
<br />
[[User:Baerbeisser|Baerbeisser]] ([[User talk:Baerbeisser|talk]]) 07:23, 6 August 2021 (UTC)</div>Baerbeisserhttps://wiki.archlinux.org/index.php?title=Talk:XDG_Base_Directory&diff=690989Talk:XDG Base Directory2021-08-06T07:29:08Z<p>Baerbeisser: /* Should command-line history be data or cache? */</p>
<hr />
<div>== emacs ==<br />
Has anyone looked at [http://technical-hobbyist.blogspot.com/2014/01/xdg-directories-for-emacs.html? XDG Directories for emacs]? [[User:Ben Creasy|Ben Creasy]] ([[User talk:Ben Creasy|talk]]) 02:40, 15 July 2015 (UTC)<br />
:It seems that still needs an {{ic|~/.emacs}}, so I'm unsure it's a great improvement over a single {{ic|~/.emacs.d}}. That said, you could try to start emacs with the {{ic|--load}} or {{ic|--directory}} argument. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:15, 1 September 2015 (UTC)<br />
<br />
Emacs should be XDG-aware in the first 27.* release [https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=4118297ae2fab4886b20d193ba511a229637aea3 (see this commit)]. Not sure if this warrants updating the table yet. [[User:Odnir|Odnir]] ([[User talk:Odnir|talk]]) 22:00, 28 August 2019 (UTC)<br />
<br />
== Abuse of XDG_CONFIG_HOME ==<br />
<br />
I've just revised the VCS management of my config files and had to put configs of practically all graphical programs to {{ic|.gitignore}}, because they all abuse the {{ic|$XDG_CONFIG_HOME}} path for the purpose of persistent cache, which is {{ic|$XDG_CACHE_HOME}}. A typical config file of a [[Qt]] programs looks [https://gist.github.com/lahwaacz/8a806d9c248cff10ffe0 like this], notice especially the {{ic|recentFileList}}, {{ic|geometry}} and {{ic|windowState}} keys -- IMHO this is exactly the stuff that belongs to {{ic|$XDG_CACHE_HOME}} or {{ic|$XDG_DATA_HOME}}. The [[Qt]] programs are notorious, I suspect the toolkit itself is responsible. But there is more: inkscape puts there {{ic|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... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:12, 21 August 2015 (UTC)<br />
<br />
: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.<br />
: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. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:08, 1 September 2015 (UTC)<br />
<br />
::This is why adding {{ic|*}} to {{ic|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... [[User:Earnest|Earnest]] ([[User talk:Earnest|talk]]) 15:31, 12 September 2015 (UTC)<br />
<br />
== Should command-line history be data or cache? ==<br />
<br />
Should they be placed in {{ic|XDG_DATA_HOME}}, or {{ic|XDG_CACHE_HOME}}? --[[User:Franklin Yu|Franklin Yu]] ([[User talk:Franklin Yu|talk]]) 20:07, 16 May 2017 (UTC)<br />
<br />
: 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 {{ic|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 {{ic|XDG_DATA_HOME}}. —[[User:Ayekat|Ayekat]] ([[User talk:Ayekat|talk]]) 22:30, 16 May 2017 (UTC)<br />
<br />
:: Should it not be XDG_STATE_HOME ($HOME/.local/state) now?<br />
[[User:Baerbeisser|Baerbeisser]] ([[User talk:Baerbeisser|talk]]) 07:29, 6 August 2021 (UTC)<br />
<br />
== nvidia uses XDG_CACHE_HOME, how to test CUDA? ==<br />
<br />
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.<br />
<br />
[[User:Cyant|Cyant]] ([[User talk:Cyant|talk]]) 11:55, 25 February 2018 (UTC)<br />
<br />
== Add description of support categories ==<br />
<br />
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:<br />
* app that use a hardcoded {{ic|~/.config}}, not using the XDG variables<br />
* app that use the {{ic|XDG_CONFIG_HOME}} for ''everything''<br />
* app where we can use alternative methods (environment variable, option, ...) for specific files<br />
* app where we can use alternative methods, freeing {{ic|$HOME}}, but not using the correct path for each file (config vs cache vs data) (for example, [[GnuPG]])<br />
<br />
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)?<br />
<br />
[[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 13:58, 14 March 2019 (UTC)<br />
<br />
:''#Partial'' meaning is implied in the [[{{BASEPAGENAME}}#Support]] section:<br />
::''For those not currently supporting the Base Directory Specification, workarounds will be demonstrated to emulate it instead.''<br />
::''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.''<br />
: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''.<br />
:I also propose using fields to describe how different programs work with the spec, instead of just having 3 categories:<br />
:{| class="wikitable sortable"<br />
! Application<br />
! Legacy paths<br />
! Dir split<br />
! XDG variables<br />
! XDG fallback<br />
! Legacy fallback<br />
! Legacy files moved<br />
! Notes<br />
|-<br />
| Cool-utils<br />
| .cool-utils/<br />
| {{No|http://example.com/bug/1}}<br />
| {{Yes|http://example.com/cool-utils/commit/1234567}}<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{No}}<br />
| {{-}}<br />
|-<br />
| git-xmonad<br />
| .git-xmonad<br />
| {{No}}<br />
| {{Y|[http://example.com/bug/1 After legacy]}}<br />
| {{No|http://example.com/bug/1}}<br />
| {{Yes}}<br />
| {{No|http://example.com/bug/1}}<br />
| {{-}}<br />
|-<br />
| Dumper<br />
| .dumper/<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{No}}<br />
| {{Y|Old copies left}}<br />
| {{-}}<br />
|-<br />
| Hostile-app<br />
| .hostileapp/<br />
| {{No|http://example.com/bug/1}}<br />
| {{R|[http://example.com/bug/1 No, WONTFIX]}}<br />
| {{No}}<br />
| {{Yes}}<br />
| {{No}}<br />
| {{ic|1=$ export GARBAGEBIN="$XDG_DATA_HOME"/hostile-app}}<br />
|}<br />
:-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 01:55, 23 April 2020 (UTC)<br />
<br />
::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.<br />
::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.<br />
:: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 12:09, 23 April 2020 (UTC)<br />
<br />
:::I think its definitely confusing/annoying: [https://github.com/xmonad/xmonad/issues/164]. Documenting these particularities would avoid confusion. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 11:27, 25 April 2020 (UTC)<br />
<br />
::::As long as the column title meanings are explained, I think it would certainly be an improvement over the current tables. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:24, 28 April 2020 (UTC)<br />
<br />
== Should Organizations/DEs be mentioned? ==<br />
<br />
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.<br />
<br />
[[User:Hobyamnlyzfsr|Hobyamnlyzfsr]] ([[User talk:Hobyamnlyzfsr|talk]]) 21:35, 9 September 2019 (UTC)<br />
<br />
: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... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:54, 23 April 2020 (UTC)<br />
<br />
== MPV removing XDG support ==<br />
<br />
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<br />
<br />
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).<br />
<br />
{{unsigned|11:45, 9 July 2020|Vash63}}<br />
<br />
: For the record, this change never made it to a release version. It was reverted 2020-10-15.[https://github.com/mpv-player/mpv/pull/8177] [[User:Comic-paralyze-image|Comic-paralyze-image]] ([[User talk:Comic-paralyze-image|talk]]) 22:09, 29 December 2020 (UTC)<br />
<br />
== Android ==<br />
<br />
I updated the android paths, but these might also be valid alternatives:<br />
<br />
$ export ANDROID_EMULATOR_HOME="$ANDROID_PREFS_ROOT"/emulator<br />
$ export ANDROID_AVD_HOME="$XDG_DATA_HOME"/android/avd<br />
<br />
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.<br />
<br />
{{Unsigned|10:55, 23 December 2020 (UTC)|Xerus}}<br />
<br />
Tried the android configuration suggested, as well as `ADB_VENDOR_KEYS` (as suggested by `adb --help`). None of these had any effect.<br />
<br />
[[User:Gesh|Gesh]] ([[User talk:Gesh|talk]]) 19:46, 3 February 2021 (UTC)<br />
<br />
== Vim/Neovim ==<br />
<br />
Hi,<br />
<br />
somehow the suggested way to set up the {{ic|VIMINIT}} environment variable in case you want to use separate configs for Vim and Neovim<br />
<br />
export VIMINIT='if !has('nvim') | source "$XDG_CONFIG_HOME/vim/vimrc" | endif'<br />
<br />
does not work for me. I had to change it to:<br />
<br />
export VIMINIT='if !has("nvim") | let $MYVIMRC="$XDG_CONFIG_HOME/vim/vimrc" | else | let $MYVIMRC="$XDG_CONFIG_HOME/nvim/init.vim" | endif | source $MYVIMRC'<br />
<br />
Besides some minor fixes to the first line, that were necessary to make the first line work in Vim (e.g. double quotes around {{ic|nvim}}), with the first line Neovim didn't load my {{ic|~/.config/nvim/init.vim}}. The second line fixes this issue.<br />
<br />
I'm using Vim version 8.2.1989 and Neovim version 0.4.4.<br />
<br />
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?<br />
<br />
[[User:Schuam|Schuam]] ([[User talk:Schuam|talk]]) 07:41, 29 December 2020 (UTC)<br />
<br />
== Firefox ==<br />
<br />
Mozilla Firefox puts the default profile in {{ic|~/.mozilla/}}. There is a workaround for "moving" it out of the home directory, though — Firefox has the command line option {{ic|--profile}} (I can't actually find documentation on this online, and there's no Firefox man page, but it's in the {{ic|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 {{ic|firefox}} to use a profile from, say, {{ic|$XDG_DATA_HOME/mozilla/firefox}}, then {{ic|~/.mozilla/}} basically becomes useless.<br />
<br />
Note that even when specifying a different profile directory, {{ic|~/.mozilla/}} <i>still</i> 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 {{ic|~/.mozilla/}} directory immediately after its creation.<br />
<br />
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.<br />
<br />
[[User:Inco|Inco]] ([[User talk:Inco|talk]]) 20:52, 20 April 2021 (UTC)<br />
<br />
:It should be added to the [[Firefox]] page and then linked from the notes column. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:58, 20 April 2021 (UTC)<br />
<br />
:The {{ic|~/.mozilla}} directory gets recreated during the runtime of Firefox. I wrote a wrapper which solves this issue: [https://github.com/Jorengarenar/MozXDG MozXDG] -- [[User:Jorengarenar|Jorengarenar]] ([[User talk:Jorengarenar|talk]]) 09:05, 21 April 2021 (UTC)<br />
<br />
== Obscure software ==<br />
<br />
Was wondering how much sense it would make to add obscure/rare software to the list, such as games. I was specifically thinking about [https://aur.archlinux.org/packages/maptool-bin/ MapTool] which places files in the home directory but can be configured not to.<br />
[[User:Maze|Maze]] ([[User talk:Maze|talk]]) 03:04, 24 June 2021 (UTC)<br />
<br />
:80% of this page is already for obscure software, so I don't see how it would make a difference. -- [[User:MrX|MrX]] ([[User talk:MrX|talk]]) 11:47, 24 June 2021 (UTC)<br />
<br />
== Where to put workarounds? ==<br />
<br />
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.<br />
<br />
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/...).<br />
<br />
But the global settings? Varibles are somehow not all set if put in /etc/profile.d, even if loaded from .../Xsession. Should they go to /etc/X11/xinit/xinitrc.d/?<br />
<br />
[[User:Baerbeisser|Baerbeisser]] ([[User talk:Baerbeisser|talk]]) 07:23, 6 August 2021 (UTC)</div>Baerbeisserhttps://wiki.archlinux.org/index.php?title=Talk:XDG_Base_Directory&diff=690988Talk:XDG Base Directory2021-08-06T07:28:50Z<p>Baerbeisser: /* Should command-line history be data or cache? */</p>
<hr />
<div>== emacs ==<br />
Has anyone looked at [http://technical-hobbyist.blogspot.com/2014/01/xdg-directories-for-emacs.html? XDG Directories for emacs]? [[User:Ben Creasy|Ben Creasy]] ([[User talk:Ben Creasy|talk]]) 02:40, 15 July 2015 (UTC)<br />
:It seems that still needs an {{ic|~/.emacs}}, so I'm unsure it's a great improvement over a single {{ic|~/.emacs.d}}. That said, you could try to start emacs with the {{ic|--load}} or {{ic|--directory}} argument. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:15, 1 September 2015 (UTC)<br />
<br />
Emacs should be XDG-aware in the first 27.* release [https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=4118297ae2fab4886b20d193ba511a229637aea3 (see this commit)]. Not sure if this warrants updating the table yet. [[User:Odnir|Odnir]] ([[User talk:Odnir|talk]]) 22:00, 28 August 2019 (UTC)<br />
<br />
== Abuse of XDG_CONFIG_HOME ==<br />
<br />
I've just revised the VCS management of my config files and had to put configs of practically all graphical programs to {{ic|.gitignore}}, because they all abuse the {{ic|$XDG_CONFIG_HOME}} path for the purpose of persistent cache, which is {{ic|$XDG_CACHE_HOME}}. A typical config file of a [[Qt]] programs looks [https://gist.github.com/lahwaacz/8a806d9c248cff10ffe0 like this], notice especially the {{ic|recentFileList}}, {{ic|geometry}} and {{ic|windowState}} keys -- IMHO this is exactly the stuff that belongs to {{ic|$XDG_CACHE_HOME}} or {{ic|$XDG_DATA_HOME}}. The [[Qt]] programs are notorious, I suspect the toolkit itself is responsible. But there is more: inkscape puts there {{ic|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... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:12, 21 August 2015 (UTC)<br />
<br />
: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.<br />
: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. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:08, 1 September 2015 (UTC)<br />
<br />
::This is why adding {{ic|*}} to {{ic|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... [[User:Earnest|Earnest]] ([[User talk:Earnest|talk]]) 15:31, 12 September 2015 (UTC)<br />
<br />
== Should command-line history be data or cache? ==<br />
<br />
Should they be placed in {{ic|XDG_DATA_HOME}}, or {{ic|XDG_CACHE_HOME}}? --[[User:Franklin Yu|Franklin Yu]] ([[User talk:Franklin Yu|talk]]) 20:07, 16 May 2017 (UTC)<br />
<br />
: 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 {{ic|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 {{ic|XDG_DATA_HOME}}. —[[User:Ayekat|Ayekat]] ([[User talk:Ayekat|talk]]) 22:30, 16 May 2017 (UTC)<br />
<br />
:: Should it not be XDG_STATE_HOME ($HOME/.local/state) now?<br />
<br />
== nvidia uses XDG_CACHE_HOME, how to test CUDA? ==<br />
<br />
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.<br />
<br />
[[User:Cyant|Cyant]] ([[User talk:Cyant|talk]]) 11:55, 25 February 2018 (UTC)<br />
<br />
== Add description of support categories ==<br />
<br />
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:<br />
* app that use a hardcoded {{ic|~/.config}}, not using the XDG variables<br />
* app that use the {{ic|XDG_CONFIG_HOME}} for ''everything''<br />
* app where we can use alternative methods (environment variable, option, ...) for specific files<br />
* app where we can use alternative methods, freeing {{ic|$HOME}}, but not using the correct path for each file (config vs cache vs data) (for example, [[GnuPG]])<br />
<br />
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)?<br />
<br />
[[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 13:58, 14 March 2019 (UTC)<br />
<br />
:''#Partial'' meaning is implied in the [[{{BASEPAGENAME}}#Support]] section:<br />
::''For those not currently supporting the Base Directory Specification, workarounds will be demonstrated to emulate it instead.''<br />
::''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.''<br />
: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''.<br />
:I also propose using fields to describe how different programs work with the spec, instead of just having 3 categories:<br />
:{| class="wikitable sortable"<br />
! Application<br />
! Legacy paths<br />
! Dir split<br />
! XDG variables<br />
! XDG fallback<br />
! Legacy fallback<br />
! Legacy files moved<br />
! Notes<br />
|-<br />
| Cool-utils<br />
| .cool-utils/<br />
| {{No|http://example.com/bug/1}}<br />
| {{Yes|http://example.com/cool-utils/commit/1234567}}<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{No}}<br />
| {{-}}<br />
|-<br />
| git-xmonad<br />
| .git-xmonad<br />
| {{No}}<br />
| {{Y|[http://example.com/bug/1 After legacy]}}<br />
| {{No|http://example.com/bug/1}}<br />
| {{Yes}}<br />
| {{No|http://example.com/bug/1}}<br />
| {{-}}<br />
|-<br />
| Dumper<br />
| .dumper/<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{No}}<br />
| {{Y|Old copies left}}<br />
| {{-}}<br />
|-<br />
| Hostile-app<br />
| .hostileapp/<br />
| {{No|http://example.com/bug/1}}<br />
| {{R|[http://example.com/bug/1 No, WONTFIX]}}<br />
| {{No}}<br />
| {{Yes}}<br />
| {{No}}<br />
| {{ic|1=$ export GARBAGEBIN="$XDG_DATA_HOME"/hostile-app}}<br />
|}<br />
:-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 01:55, 23 April 2020 (UTC)<br />
<br />
::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.<br />
::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.<br />
:: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 12:09, 23 April 2020 (UTC)<br />
<br />
:::I think its definitely confusing/annoying: [https://github.com/xmonad/xmonad/issues/164]. Documenting these particularities would avoid confusion. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 11:27, 25 April 2020 (UTC)<br />
<br />
::::As long as the column title meanings are explained, I think it would certainly be an improvement over the current tables. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:24, 28 April 2020 (UTC)<br />
<br />
== Should Organizations/DEs be mentioned? ==<br />
<br />
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.<br />
<br />
[[User:Hobyamnlyzfsr|Hobyamnlyzfsr]] ([[User talk:Hobyamnlyzfsr|talk]]) 21:35, 9 September 2019 (UTC)<br />
<br />
: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... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:54, 23 April 2020 (UTC)<br />
<br />
== MPV removing XDG support ==<br />
<br />
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<br />
<br />
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).<br />
<br />
{{unsigned|11:45, 9 July 2020|Vash63}}<br />
<br />
: For the record, this change never made it to a release version. It was reverted 2020-10-15.[https://github.com/mpv-player/mpv/pull/8177] [[User:Comic-paralyze-image|Comic-paralyze-image]] ([[User talk:Comic-paralyze-image|talk]]) 22:09, 29 December 2020 (UTC)<br />
<br />
== Android ==<br />
<br />
I updated the android paths, but these might also be valid alternatives:<br />
<br />
$ export ANDROID_EMULATOR_HOME="$ANDROID_PREFS_ROOT"/emulator<br />
$ export ANDROID_AVD_HOME="$XDG_DATA_HOME"/android/avd<br />
<br />
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.<br />
<br />
{{Unsigned|10:55, 23 December 2020 (UTC)|Xerus}}<br />
<br />
Tried the android configuration suggested, as well as `ADB_VENDOR_KEYS` (as suggested by `adb --help`). None of these had any effect.<br />
<br />
[[User:Gesh|Gesh]] ([[User talk:Gesh|talk]]) 19:46, 3 February 2021 (UTC)<br />
<br />
== Vim/Neovim ==<br />
<br />
Hi,<br />
<br />
somehow the suggested way to set up the {{ic|VIMINIT}} environment variable in case you want to use separate configs for Vim and Neovim<br />
<br />
export VIMINIT='if !has('nvim') | source "$XDG_CONFIG_HOME/vim/vimrc" | endif'<br />
<br />
does not work for me. I had to change it to:<br />
<br />
export VIMINIT='if !has("nvim") | let $MYVIMRC="$XDG_CONFIG_HOME/vim/vimrc" | else | let $MYVIMRC="$XDG_CONFIG_HOME/nvim/init.vim" | endif | source $MYVIMRC'<br />
<br />
Besides some minor fixes to the first line, that were necessary to make the first line work in Vim (e.g. double quotes around {{ic|nvim}}), with the first line Neovim didn't load my {{ic|~/.config/nvim/init.vim}}. The second line fixes this issue.<br />
<br />
I'm using Vim version 8.2.1989 and Neovim version 0.4.4.<br />
<br />
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?<br />
<br />
[[User:Schuam|Schuam]] ([[User talk:Schuam|talk]]) 07:41, 29 December 2020 (UTC)<br />
<br />
== Firefox ==<br />
<br />
Mozilla Firefox puts the default profile in {{ic|~/.mozilla/}}. There is a workaround for "moving" it out of the home directory, though — Firefox has the command line option {{ic|--profile}} (I can't actually find documentation on this online, and there's no Firefox man page, but it's in the {{ic|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 {{ic|firefox}} to use a profile from, say, {{ic|$XDG_DATA_HOME/mozilla/firefox}}, then {{ic|~/.mozilla/}} basically becomes useless.<br />
<br />
Note that even when specifying a different profile directory, {{ic|~/.mozilla/}} <i>still</i> 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 {{ic|~/.mozilla/}} directory immediately after its creation.<br />
<br />
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.<br />
<br />
[[User:Inco|Inco]] ([[User talk:Inco|talk]]) 20:52, 20 April 2021 (UTC)<br />
<br />
:It should be added to the [[Firefox]] page and then linked from the notes column. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:58, 20 April 2021 (UTC)<br />
<br />
:The {{ic|~/.mozilla}} directory gets recreated during the runtime of Firefox. I wrote a wrapper which solves this issue: [https://github.com/Jorengarenar/MozXDG MozXDG] -- [[User:Jorengarenar|Jorengarenar]] ([[User talk:Jorengarenar|talk]]) 09:05, 21 April 2021 (UTC)<br />
<br />
== Obscure software ==<br />
<br />
Was wondering how much sense it would make to add obscure/rare software to the list, such as games. I was specifically thinking about [https://aur.archlinux.org/packages/maptool-bin/ MapTool] which places files in the home directory but can be configured not to.<br />
[[User:Maze|Maze]] ([[User talk:Maze|talk]]) 03:04, 24 June 2021 (UTC)<br />
<br />
:80% of this page is already for obscure software, so I don't see how it would make a difference. -- [[User:MrX|MrX]] ([[User talk:MrX|talk]]) 11:47, 24 June 2021 (UTC)<br />
<br />
== Where to put workarounds? ==<br />
<br />
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.<br />
<br />
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/...).<br />
<br />
But the global settings? Varibles are somehow not all set if put in /etc/profile.d, even if loaded from .../Xsession. Should they go to /etc/X11/xinit/xinitrc.d/?<br />
<br />
[[User:Baerbeisser|Baerbeisser]] ([[User talk:Baerbeisser|talk]]) 07:23, 6 August 2021 (UTC)</div>Baerbeisserhttps://wiki.archlinux.org/index.php?title=Talk:XDG_Base_Directory&diff=690987Talk:XDG Base Directory2021-08-06T07:25:15Z<p>Baerbeisser: /* Where to put workarounds? */</p>
<hr />
<div>== emacs ==<br />
Has anyone looked at [http://technical-hobbyist.blogspot.com/2014/01/xdg-directories-for-emacs.html? XDG Directories for emacs]? [[User:Ben Creasy|Ben Creasy]] ([[User talk:Ben Creasy|talk]]) 02:40, 15 July 2015 (UTC)<br />
:It seems that still needs an {{ic|~/.emacs}}, so I'm unsure it's a great improvement over a single {{ic|~/.emacs.d}}. That said, you could try to start emacs with the {{ic|--load}} or {{ic|--directory}} argument. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:15, 1 September 2015 (UTC)<br />
<br />
Emacs should be XDG-aware in the first 27.* release [https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=4118297ae2fab4886b20d193ba511a229637aea3 (see this commit)]. Not sure if this warrants updating the table yet. [[User:Odnir|Odnir]] ([[User talk:Odnir|talk]]) 22:00, 28 August 2019 (UTC)<br />
<br />
== Abuse of XDG_CONFIG_HOME ==<br />
<br />
I've just revised the VCS management of my config files and had to put configs of practically all graphical programs to {{ic|.gitignore}}, because they all abuse the {{ic|$XDG_CONFIG_HOME}} path for the purpose of persistent cache, which is {{ic|$XDG_CACHE_HOME}}. A typical config file of a [[Qt]] programs looks [https://gist.github.com/lahwaacz/8a806d9c248cff10ffe0 like this], notice especially the {{ic|recentFileList}}, {{ic|geometry}} and {{ic|windowState}} keys -- IMHO this is exactly the stuff that belongs to {{ic|$XDG_CACHE_HOME}} or {{ic|$XDG_DATA_HOME}}. The [[Qt]] programs are notorious, I suspect the toolkit itself is responsible. But there is more: inkscape puts there {{ic|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... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:12, 21 August 2015 (UTC)<br />
<br />
: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.<br />
: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. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:08, 1 September 2015 (UTC)<br />
<br />
::This is why adding {{ic|*}} to {{ic|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... [[User:Earnest|Earnest]] ([[User talk:Earnest|talk]]) 15:31, 12 September 2015 (UTC)<br />
<br />
== Should command-line history be data or cache? ==<br />
<br />
Should they be placed in {{ic|XDG_DATA_HOME}}, or {{ic|XDG_CACHE_HOME}}? --[[User:Franklin Yu|Franklin Yu]] ([[User talk:Franklin Yu|talk]]) 20:07, 16 May 2017 (UTC)<br />
<br />
: 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 {{ic|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 {{ic|XDG_DATA_HOME}}. —[[User:Ayekat|Ayekat]] ([[User talk:Ayekat|talk]]) 22:30, 16 May 2017 (UTC)<br />
<br />
== nvidia uses XDG_CACHE_HOME, how to test CUDA? ==<br />
<br />
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.<br />
<br />
[[User:Cyant|Cyant]] ([[User talk:Cyant|talk]]) 11:55, 25 February 2018 (UTC)<br />
<br />
== Add description of support categories ==<br />
<br />
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:<br />
* app that use a hardcoded {{ic|~/.config}}, not using the XDG variables<br />
* app that use the {{ic|XDG_CONFIG_HOME}} for ''everything''<br />
* app where we can use alternative methods (environment variable, option, ...) for specific files<br />
* app where we can use alternative methods, freeing {{ic|$HOME}}, but not using the correct path for each file (config vs cache vs data) (for example, [[GnuPG]])<br />
<br />
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)?<br />
<br />
[[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 13:58, 14 March 2019 (UTC)<br />
<br />
:''#Partial'' meaning is implied in the [[{{BASEPAGENAME}}#Support]] section:<br />
::''For those not currently supporting the Base Directory Specification, workarounds will be demonstrated to emulate it instead.''<br />
::''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.''<br />
: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''.<br />
:I also propose using fields to describe how different programs work with the spec, instead of just having 3 categories:<br />
:{| class="wikitable sortable"<br />
! Application<br />
! Legacy paths<br />
! Dir split<br />
! XDG variables<br />
! XDG fallback<br />
! Legacy fallback<br />
! Legacy files moved<br />
! Notes<br />
|-<br />
| Cool-utils<br />
| .cool-utils/<br />
| {{No|http://example.com/bug/1}}<br />
| {{Yes|http://example.com/cool-utils/commit/1234567}}<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{No}}<br />
| {{-}}<br />
|-<br />
| git-xmonad<br />
| .git-xmonad<br />
| {{No}}<br />
| {{Y|[http://example.com/bug/1 After legacy]}}<br />
| {{No|http://example.com/bug/1}}<br />
| {{Yes}}<br />
| {{No|http://example.com/bug/1}}<br />
| {{-}}<br />
|-<br />
| Dumper<br />
| .dumper/<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{No}}<br />
| {{Y|Old copies left}}<br />
| {{-}}<br />
|-<br />
| Hostile-app<br />
| .hostileapp/<br />
| {{No|http://example.com/bug/1}}<br />
| {{R|[http://example.com/bug/1 No, WONTFIX]}}<br />
| {{No}}<br />
| {{Yes}}<br />
| {{No}}<br />
| {{ic|1=$ export GARBAGEBIN="$XDG_DATA_HOME"/hostile-app}}<br />
|}<br />
:-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 01:55, 23 April 2020 (UTC)<br />
<br />
::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.<br />
::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.<br />
:: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 12:09, 23 April 2020 (UTC)<br />
<br />
:::I think its definitely confusing/annoying: [https://github.com/xmonad/xmonad/issues/164]. Documenting these particularities would avoid confusion. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 11:27, 25 April 2020 (UTC)<br />
<br />
::::As long as the column title meanings are explained, I think it would certainly be an improvement over the current tables. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:24, 28 April 2020 (UTC)<br />
<br />
== Should Organizations/DEs be mentioned? ==<br />
<br />
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.<br />
<br />
[[User:Hobyamnlyzfsr|Hobyamnlyzfsr]] ([[User talk:Hobyamnlyzfsr|talk]]) 21:35, 9 September 2019 (UTC)<br />
<br />
: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... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:54, 23 April 2020 (UTC)<br />
<br />
== MPV removing XDG support ==<br />
<br />
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<br />
<br />
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).<br />
<br />
{{unsigned|11:45, 9 July 2020|Vash63}}<br />
<br />
: For the record, this change never made it to a release version. It was reverted 2020-10-15.[https://github.com/mpv-player/mpv/pull/8177] [[User:Comic-paralyze-image|Comic-paralyze-image]] ([[User talk:Comic-paralyze-image|talk]]) 22:09, 29 December 2020 (UTC)<br />
<br />
== Android ==<br />
<br />
I updated the android paths, but these might also be valid alternatives:<br />
<br />
$ export ANDROID_EMULATOR_HOME="$ANDROID_PREFS_ROOT"/emulator<br />
$ export ANDROID_AVD_HOME="$XDG_DATA_HOME"/android/avd<br />
<br />
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.<br />
<br />
{{Unsigned|10:55, 23 December 2020 (UTC)|Xerus}}<br />
<br />
Tried the android configuration suggested, as well as `ADB_VENDOR_KEYS` (as suggested by `adb --help`). None of these had any effect.<br />
<br />
[[User:Gesh|Gesh]] ([[User talk:Gesh|talk]]) 19:46, 3 February 2021 (UTC)<br />
<br />
== Vim/Neovim ==<br />
<br />
Hi,<br />
<br />
somehow the suggested way to set up the {{ic|VIMINIT}} environment variable in case you want to use separate configs for Vim and Neovim<br />
<br />
export VIMINIT='if !has('nvim') | source "$XDG_CONFIG_HOME/vim/vimrc" | endif'<br />
<br />
does not work for me. I had to change it to:<br />
<br />
export VIMINIT='if !has("nvim") | let $MYVIMRC="$XDG_CONFIG_HOME/vim/vimrc" | else | let $MYVIMRC="$XDG_CONFIG_HOME/nvim/init.vim" | endif | source $MYVIMRC'<br />
<br />
Besides some minor fixes to the first line, that were necessary to make the first line work in Vim (e.g. double quotes around {{ic|nvim}}), with the first line Neovim didn't load my {{ic|~/.config/nvim/init.vim}}. The second line fixes this issue.<br />
<br />
I'm using Vim version 8.2.1989 and Neovim version 0.4.4.<br />
<br />
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?<br />
<br />
[[User:Schuam|Schuam]] ([[User talk:Schuam|talk]]) 07:41, 29 December 2020 (UTC)<br />
<br />
== Firefox ==<br />
<br />
Mozilla Firefox puts the default profile in {{ic|~/.mozilla/}}. There is a workaround for "moving" it out of the home directory, though — Firefox has the command line option {{ic|--profile}} (I can't actually find documentation on this online, and there's no Firefox man page, but it's in the {{ic|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 {{ic|firefox}} to use a profile from, say, {{ic|$XDG_DATA_HOME/mozilla/firefox}}, then {{ic|~/.mozilla/}} basically becomes useless.<br />
<br />
Note that even when specifying a different profile directory, {{ic|~/.mozilla/}} <i>still</i> 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 {{ic|~/.mozilla/}} directory immediately after its creation.<br />
<br />
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.<br />
<br />
[[User:Inco|Inco]] ([[User talk:Inco|talk]]) 20:52, 20 April 2021 (UTC)<br />
<br />
:It should be added to the [[Firefox]] page and then linked from the notes column. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:58, 20 April 2021 (UTC)<br />
<br />
:The {{ic|~/.mozilla}} directory gets recreated during the runtime of Firefox. I wrote a wrapper which solves this issue: [https://github.com/Jorengarenar/MozXDG MozXDG] -- [[User:Jorengarenar|Jorengarenar]] ([[User talk:Jorengarenar|talk]]) 09:05, 21 April 2021 (UTC)<br />
<br />
== Obscure software ==<br />
<br />
Was wondering how much sense it would make to add obscure/rare software to the list, such as games. I was specifically thinking about [https://aur.archlinux.org/packages/maptool-bin/ MapTool] which places files in the home directory but can be configured not to.<br />
[[User:Maze|Maze]] ([[User talk:Maze|talk]]) 03:04, 24 June 2021 (UTC)<br />
<br />
:80% of this page is already for obscure software, so I don't see how it would make a difference. -- [[User:MrX|MrX]] ([[User talk:MrX|talk]]) 11:47, 24 June 2021 (UTC)<br />
<br />
== Where to put workarounds? ==<br />
<br />
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.<br />
<br />
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/...).<br />
<br />
But the global settings? Varibles are somehow not all set if put in /etc/profile.d, even if loaded from .../Xsession. Should they go to /etc/X11/xinit/xinitrc.d/?<br />
<br />
[[User:Baerbeisser|Baerbeisser]] ([[User talk:Baerbeisser|talk]]) 07:23, 6 August 2021 (UTC)</div>Baerbeisserhttps://wiki.archlinux.org/index.php?title=Talk:XDG_Base_Directory&diff=690986Talk:XDG Base Directory2021-08-06T07:23:16Z<p>Baerbeisser: /* Where to put workarounds? */</p>
<hr />
<div>== emacs ==<br />
Has anyone looked at [http://technical-hobbyist.blogspot.com/2014/01/xdg-directories-for-emacs.html? XDG Directories for emacs]? [[User:Ben Creasy|Ben Creasy]] ([[User talk:Ben Creasy|talk]]) 02:40, 15 July 2015 (UTC)<br />
:It seems that still needs an {{ic|~/.emacs}}, so I'm unsure it's a great improvement over a single {{ic|~/.emacs.d}}. That said, you could try to start emacs with the {{ic|--load}} or {{ic|--directory}} argument. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:15, 1 September 2015 (UTC)<br />
<br />
Emacs should be XDG-aware in the first 27.* release [https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=4118297ae2fab4886b20d193ba511a229637aea3 (see this commit)]. Not sure if this warrants updating the table yet. [[User:Odnir|Odnir]] ([[User talk:Odnir|talk]]) 22:00, 28 August 2019 (UTC)<br />
<br />
== Abuse of XDG_CONFIG_HOME ==<br />
<br />
I've just revised the VCS management of my config files and had to put configs of practically all graphical programs to {{ic|.gitignore}}, because they all abuse the {{ic|$XDG_CONFIG_HOME}} path for the purpose of persistent cache, which is {{ic|$XDG_CACHE_HOME}}. A typical config file of a [[Qt]] programs looks [https://gist.github.com/lahwaacz/8a806d9c248cff10ffe0 like this], notice especially the {{ic|recentFileList}}, {{ic|geometry}} and {{ic|windowState}} keys -- IMHO this is exactly the stuff that belongs to {{ic|$XDG_CACHE_HOME}} or {{ic|$XDG_DATA_HOME}}. The [[Qt]] programs are notorious, I suspect the toolkit itself is responsible. But there is more: inkscape puts there {{ic|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... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:12, 21 August 2015 (UTC)<br />
<br />
: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.<br />
: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. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:08, 1 September 2015 (UTC)<br />
<br />
::This is why adding {{ic|*}} to {{ic|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... [[User:Earnest|Earnest]] ([[User talk:Earnest|talk]]) 15:31, 12 September 2015 (UTC)<br />
<br />
== Should command-line history be data or cache? ==<br />
<br />
Should they be placed in {{ic|XDG_DATA_HOME}}, or {{ic|XDG_CACHE_HOME}}? --[[User:Franklin Yu|Franklin Yu]] ([[User talk:Franklin Yu|talk]]) 20:07, 16 May 2017 (UTC)<br />
<br />
: 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 {{ic|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 {{ic|XDG_DATA_HOME}}. —[[User:Ayekat|Ayekat]] ([[User talk:Ayekat|talk]]) 22:30, 16 May 2017 (UTC)<br />
<br />
== nvidia uses XDG_CACHE_HOME, how to test CUDA? ==<br />
<br />
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.<br />
<br />
[[User:Cyant|Cyant]] ([[User talk:Cyant|talk]]) 11:55, 25 February 2018 (UTC)<br />
<br />
== Add description of support categories ==<br />
<br />
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:<br />
* app that use a hardcoded {{ic|~/.config}}, not using the XDG variables<br />
* app that use the {{ic|XDG_CONFIG_HOME}} for ''everything''<br />
* app where we can use alternative methods (environment variable, option, ...) for specific files<br />
* app where we can use alternative methods, freeing {{ic|$HOME}}, but not using the correct path for each file (config vs cache vs data) (for example, [[GnuPG]])<br />
<br />
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)?<br />
<br />
[[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 13:58, 14 March 2019 (UTC)<br />
<br />
:''#Partial'' meaning is implied in the [[{{BASEPAGENAME}}#Support]] section:<br />
::''For those not currently supporting the Base Directory Specification, workarounds will be demonstrated to emulate it instead.''<br />
::''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.''<br />
: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''.<br />
:I also propose using fields to describe how different programs work with the spec, instead of just having 3 categories:<br />
:{| class="wikitable sortable"<br />
! Application<br />
! Legacy paths<br />
! Dir split<br />
! XDG variables<br />
! XDG fallback<br />
! Legacy fallback<br />
! Legacy files moved<br />
! Notes<br />
|-<br />
| Cool-utils<br />
| .cool-utils/<br />
| {{No|http://example.com/bug/1}}<br />
| {{Yes|http://example.com/cool-utils/commit/1234567}}<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{No}}<br />
| {{-}}<br />
|-<br />
| git-xmonad<br />
| .git-xmonad<br />
| {{No}}<br />
| {{Y|[http://example.com/bug/1 After legacy]}}<br />
| {{No|http://example.com/bug/1}}<br />
| {{Yes}}<br />
| {{No|http://example.com/bug/1}}<br />
| {{-}}<br />
|-<br />
| Dumper<br />
| .dumper/<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{No}}<br />
| {{Y|Old copies left}}<br />
| {{-}}<br />
|-<br />
| Hostile-app<br />
| .hostileapp/<br />
| {{No|http://example.com/bug/1}}<br />
| {{R|[http://example.com/bug/1 No, WONTFIX]}}<br />
| {{No}}<br />
| {{Yes}}<br />
| {{No}}<br />
| {{ic|1=$ export GARBAGEBIN="$XDG_DATA_HOME"/hostile-app}}<br />
|}<br />
:-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 01:55, 23 April 2020 (UTC)<br />
<br />
::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.<br />
::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.<br />
:: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 12:09, 23 April 2020 (UTC)<br />
<br />
:::I think its definitely confusing/annoying: [https://github.com/xmonad/xmonad/issues/164]. Documenting these particularities would avoid confusion. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 11:27, 25 April 2020 (UTC)<br />
<br />
::::As long as the column title meanings are explained, I think it would certainly be an improvement over the current tables. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:24, 28 April 2020 (UTC)<br />
<br />
== Should Organizations/DEs be mentioned? ==<br />
<br />
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.<br />
<br />
[[User:Hobyamnlyzfsr|Hobyamnlyzfsr]] ([[User talk:Hobyamnlyzfsr|talk]]) 21:35, 9 September 2019 (UTC)<br />
<br />
: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... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:54, 23 April 2020 (UTC)<br />
<br />
== MPV removing XDG support ==<br />
<br />
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<br />
<br />
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).<br />
<br />
{{unsigned|11:45, 9 July 2020|Vash63}}<br />
<br />
: For the record, this change never made it to a release version. It was reverted 2020-10-15.[https://github.com/mpv-player/mpv/pull/8177] [[User:Comic-paralyze-image|Comic-paralyze-image]] ([[User talk:Comic-paralyze-image|talk]]) 22:09, 29 December 2020 (UTC)<br />
<br />
== Android ==<br />
<br />
I updated the android paths, but these might also be valid alternatives:<br />
<br />
$ export ANDROID_EMULATOR_HOME="$ANDROID_PREFS_ROOT"/emulator<br />
$ export ANDROID_AVD_HOME="$XDG_DATA_HOME"/android/avd<br />
<br />
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.<br />
<br />
{{Unsigned|10:55, 23 December 2020 (UTC)|Xerus}}<br />
<br />
Tried the android configuration suggested, as well as `ADB_VENDOR_KEYS` (as suggested by `adb --help`). None of these had any effect.<br />
<br />
[[User:Gesh|Gesh]] ([[User talk:Gesh|talk]]) 19:46, 3 February 2021 (UTC)<br />
<br />
== Vim/Neovim ==<br />
<br />
Hi,<br />
<br />
somehow the suggested way to set up the {{ic|VIMINIT}} environment variable in case you want to use separate configs for Vim and Neovim<br />
<br />
export VIMINIT='if !has('nvim') | source "$XDG_CONFIG_HOME/vim/vimrc" | endif'<br />
<br />
does not work for me. I had to change it to:<br />
<br />
export VIMINIT='if !has("nvim") | let $MYVIMRC="$XDG_CONFIG_HOME/vim/vimrc" | else | let $MYVIMRC="$XDG_CONFIG_HOME/nvim/init.vim" | endif | source $MYVIMRC'<br />
<br />
Besides some minor fixes to the first line, that were necessary to make the first line work in Vim (e.g. double quotes around {{ic|nvim}}), with the first line Neovim didn't load my {{ic|~/.config/nvim/init.vim}}. The second line fixes this issue.<br />
<br />
I'm using Vim version 8.2.1989 and Neovim version 0.4.4.<br />
<br />
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?<br />
<br />
[[User:Schuam|Schuam]] ([[User talk:Schuam|talk]]) 07:41, 29 December 2020 (UTC)<br />
<br />
== Firefox ==<br />
<br />
Mozilla Firefox puts the default profile in {{ic|~/.mozilla/}}. There is a workaround for "moving" it out of the home directory, though — Firefox has the command line option {{ic|--profile}} (I can't actually find documentation on this online, and there's no Firefox man page, but it's in the {{ic|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 {{ic|firefox}} to use a profile from, say, {{ic|$XDG_DATA_HOME/mozilla/firefox}}, then {{ic|~/.mozilla/}} basically becomes useless.<br />
<br />
Note that even when specifying a different profile directory, {{ic|~/.mozilla/}} <i>still</i> 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 {{ic|~/.mozilla/}} directory immediately after its creation.<br />
<br />
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.<br />
<br />
[[User:Inco|Inco]] ([[User talk:Inco|talk]]) 20:52, 20 April 2021 (UTC)<br />
<br />
:It should be added to the [[Firefox]] page and then linked from the notes column. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:58, 20 April 2021 (UTC)<br />
<br />
:The {{ic|~/.mozilla}} directory gets recreated during the runtime of Firefox. I wrote a wrapper which solves this issue: [https://github.com/Jorengarenar/MozXDG MozXDG] -- [[User:Jorengarenar|Jorengarenar]] ([[User talk:Jorengarenar|talk]]) 09:05, 21 April 2021 (UTC)<br />
<br />
== Obscure software ==<br />
<br />
Was wondering how much sense it would make to add obscure/rare software to the list, such as games. I was specifically thinking about [https://aur.archlinux.org/packages/maptool-bin/ MapTool] which places files in the home directory but can be configured not to.<br />
[[User:Maze|Maze]] ([[User talk:Maze|talk]]) 03:04, 24 June 2021 (UTC)<br />
<br />
:80% of this page is already for obscure software, so I don't see how it would make a difference. -- [[User:MrX|MrX]] ([[User talk:MrX|talk]]) 11:47, 24 June 2021 (UTC)<br />
<br />
== Where to put workarounds? ==<br />
<br />
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.<br />
<br />
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/...).<br />
<br />
But the global settings? Varibles are somehow not set if put in /etc/profile.d, even if loaded from .../Xsession. Should they go to /etc/X11/xinit/xinitrc.d/?<br />
<br />
[[User:Baerbeisser|Baerbeisser]] ([[User talk:Baerbeisser|talk]]) 07:23, 6 August 2021 (UTC)</div>Baerbeisserhttps://wiki.archlinux.org/index.php?title=Talk:XDG_Base_Directory&diff=690985Talk:XDG Base Directory2021-08-06T07:19:03Z<p>Baerbeisser: /* Where to put workarounds? */ new section</p>
<hr />
<div>== emacs ==<br />
Has anyone looked at [http://technical-hobbyist.blogspot.com/2014/01/xdg-directories-for-emacs.html? XDG Directories for emacs]? [[User:Ben Creasy|Ben Creasy]] ([[User talk:Ben Creasy|talk]]) 02:40, 15 July 2015 (UTC)<br />
:It seems that still needs an {{ic|~/.emacs}}, so I'm unsure it's a great improvement over a single {{ic|~/.emacs.d}}. That said, you could try to start emacs with the {{ic|--load}} or {{ic|--directory}} argument. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:15, 1 September 2015 (UTC)<br />
<br />
Emacs should be XDG-aware in the first 27.* release [https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=4118297ae2fab4886b20d193ba511a229637aea3 (see this commit)]. Not sure if this warrants updating the table yet. [[User:Odnir|Odnir]] ([[User talk:Odnir|talk]]) 22:00, 28 August 2019 (UTC)<br />
<br />
== Abuse of XDG_CONFIG_HOME ==<br />
<br />
I've just revised the VCS management of my config files and had to put configs of practically all graphical programs to {{ic|.gitignore}}, because they all abuse the {{ic|$XDG_CONFIG_HOME}} path for the purpose of persistent cache, which is {{ic|$XDG_CACHE_HOME}}. A typical config file of a [[Qt]] programs looks [https://gist.github.com/lahwaacz/8a806d9c248cff10ffe0 like this], notice especially the {{ic|recentFileList}}, {{ic|geometry}} and {{ic|windowState}} keys -- IMHO this is exactly the stuff that belongs to {{ic|$XDG_CACHE_HOME}} or {{ic|$XDG_DATA_HOME}}. The [[Qt]] programs are notorious, I suspect the toolkit itself is responsible. But there is more: inkscape puts there {{ic|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... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:12, 21 August 2015 (UTC)<br />
<br />
: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.<br />
: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. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:08, 1 September 2015 (UTC)<br />
<br />
::This is why adding {{ic|*}} to {{ic|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... [[User:Earnest|Earnest]] ([[User talk:Earnest|talk]]) 15:31, 12 September 2015 (UTC)<br />
<br />
== Should command-line history be data or cache? ==<br />
<br />
Should they be placed in {{ic|XDG_DATA_HOME}}, or {{ic|XDG_CACHE_HOME}}? --[[User:Franklin Yu|Franklin Yu]] ([[User talk:Franklin Yu|talk]]) 20:07, 16 May 2017 (UTC)<br />
<br />
: 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 {{ic|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 {{ic|XDG_DATA_HOME}}. —[[User:Ayekat|Ayekat]] ([[User talk:Ayekat|talk]]) 22:30, 16 May 2017 (UTC)<br />
<br />
== nvidia uses XDG_CACHE_HOME, how to test CUDA? ==<br />
<br />
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.<br />
<br />
[[User:Cyant|Cyant]] ([[User talk:Cyant|talk]]) 11:55, 25 February 2018 (UTC)<br />
<br />
== Add description of support categories ==<br />
<br />
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:<br />
* app that use a hardcoded {{ic|~/.config}}, not using the XDG variables<br />
* app that use the {{ic|XDG_CONFIG_HOME}} for ''everything''<br />
* app where we can use alternative methods (environment variable, option, ...) for specific files<br />
* app where we can use alternative methods, freeing {{ic|$HOME}}, but not using the correct path for each file (config vs cache vs data) (for example, [[GnuPG]])<br />
<br />
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)?<br />
<br />
[[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 13:58, 14 March 2019 (UTC)<br />
<br />
:''#Partial'' meaning is implied in the [[{{BASEPAGENAME}}#Support]] section:<br />
::''For those not currently supporting the Base Directory Specification, workarounds will be demonstrated to emulate it instead.''<br />
::''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.''<br />
: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''.<br />
:I also propose using fields to describe how different programs work with the spec, instead of just having 3 categories:<br />
:{| class="wikitable sortable"<br />
! Application<br />
! Legacy paths<br />
! Dir split<br />
! XDG variables<br />
! XDG fallback<br />
! Legacy fallback<br />
! Legacy files moved<br />
! Notes<br />
|-<br />
| Cool-utils<br />
| .cool-utils/<br />
| {{No|http://example.com/bug/1}}<br />
| {{Yes|http://example.com/cool-utils/commit/1234567}}<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{No}}<br />
| {{-}}<br />
|-<br />
| git-xmonad<br />
| .git-xmonad<br />
| {{No}}<br />
| {{Y|[http://example.com/bug/1 After legacy]}}<br />
| {{No|http://example.com/bug/1}}<br />
| {{Yes}}<br />
| {{No|http://example.com/bug/1}}<br />
| {{-}}<br />
|-<br />
| Dumper<br />
| .dumper/<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{Yes}}<br />
| {{No}}<br />
| {{Y|Old copies left}}<br />
| {{-}}<br />
|-<br />
| Hostile-app<br />
| .hostileapp/<br />
| {{No|http://example.com/bug/1}}<br />
| {{R|[http://example.com/bug/1 No, WONTFIX]}}<br />
| {{No}}<br />
| {{Yes}}<br />
| {{No}}<br />
| {{ic|1=$ export GARBAGEBIN="$XDG_DATA_HOME"/hostile-app}}<br />
|}<br />
:-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 01:55, 23 April 2020 (UTC)<br />
<br />
::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.<br />
::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.<br />
:: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 12:09, 23 April 2020 (UTC)<br />
<br />
:::I think its definitely confusing/annoying: [https://github.com/xmonad/xmonad/issues/164]. Documenting these particularities would avoid confusion. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 11:27, 25 April 2020 (UTC)<br />
<br />
::::As long as the column title meanings are explained, I think it would certainly be an improvement over the current tables. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:24, 28 April 2020 (UTC)<br />
<br />
== Should Organizations/DEs be mentioned? ==<br />
<br />
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.<br />
<br />
[[User:Hobyamnlyzfsr|Hobyamnlyzfsr]] ([[User talk:Hobyamnlyzfsr|talk]]) 21:35, 9 September 2019 (UTC)<br />
<br />
: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... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:54, 23 April 2020 (UTC)<br />
<br />
== MPV removing XDG support ==<br />
<br />
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<br />
<br />
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).<br />
<br />
{{unsigned|11:45, 9 July 2020|Vash63}}<br />
<br />
: For the record, this change never made it to a release version. It was reverted 2020-10-15.[https://github.com/mpv-player/mpv/pull/8177] [[User:Comic-paralyze-image|Comic-paralyze-image]] ([[User talk:Comic-paralyze-image|talk]]) 22:09, 29 December 2020 (UTC)<br />
<br />
== Android ==<br />
<br />
I updated the android paths, but these might also be valid alternatives:<br />
<br />
$ export ANDROID_EMULATOR_HOME="$ANDROID_PREFS_ROOT"/emulator<br />
$ export ANDROID_AVD_HOME="$XDG_DATA_HOME"/android/avd<br />
<br />
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.<br />
<br />
{{Unsigned|10:55, 23 December 2020 (UTC)|Xerus}}<br />
<br />
Tried the android configuration suggested, as well as `ADB_VENDOR_KEYS` (as suggested by `adb --help`). None of these had any effect.<br />
<br />
[[User:Gesh|Gesh]] ([[User talk:Gesh|talk]]) 19:46, 3 February 2021 (UTC)<br />
<br />
== Vim/Neovim ==<br />
<br />
Hi,<br />
<br />
somehow the suggested way to set up the {{ic|VIMINIT}} environment variable in case you want to use separate configs for Vim and Neovim<br />
<br />
export VIMINIT='if !has('nvim') | source "$XDG_CONFIG_HOME/vim/vimrc" | endif'<br />
<br />
does not work for me. I had to change it to:<br />
<br />
export VIMINIT='if !has("nvim") | let $MYVIMRC="$XDG_CONFIG_HOME/vim/vimrc" | else | let $MYVIMRC="$XDG_CONFIG_HOME/nvim/init.vim" | endif | source $MYVIMRC'<br />
<br />
Besides some minor fixes to the first line, that were necessary to make the first line work in Vim (e.g. double quotes around {{ic|nvim}}), with the first line Neovim didn't load my {{ic|~/.config/nvim/init.vim}}. The second line fixes this issue.<br />
<br />
I'm using Vim version 8.2.1989 and Neovim version 0.4.4.<br />
<br />
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?<br />
<br />
[[User:Schuam|Schuam]] ([[User talk:Schuam|talk]]) 07:41, 29 December 2020 (UTC)<br />
<br />
== Firefox ==<br />
<br />
Mozilla Firefox puts the default profile in {{ic|~/.mozilla/}}. There is a workaround for "moving" it out of the home directory, though — Firefox has the command line option {{ic|--profile}} (I can't actually find documentation on this online, and there's no Firefox man page, but it's in the {{ic|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 {{ic|firefox}} to use a profile from, say, {{ic|$XDG_DATA_HOME/mozilla/firefox}}, then {{ic|~/.mozilla/}} basically becomes useless.<br />
<br />
Note that even when specifying a different profile directory, {{ic|~/.mozilla/}} <i>still</i> 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 {{ic|~/.mozilla/}} directory immediately after its creation.<br />
<br />
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.<br />
<br />
[[User:Inco|Inco]] ([[User talk:Inco|talk]]) 20:52, 20 April 2021 (UTC)<br />
<br />
:It should be added to the [[Firefox]] page and then linked from the notes column. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:58, 20 April 2021 (UTC)<br />
<br />
:The {{ic|~/.mozilla}} directory gets recreated during the runtime of Firefox. I wrote a wrapper which solves this issue: [https://github.com/Jorengarenar/MozXDG MozXDG] -- [[User:Jorengarenar|Jorengarenar]] ([[User talk:Jorengarenar|talk]]) 09:05, 21 April 2021 (UTC)<br />
<br />
== Obscure software ==<br />
<br />
Was wondering how much sense it would make to add obscure/rare software to the list, such as games. I was specifically thinking about [https://aur.archlinux.org/packages/maptool-bin/ MapTool] which places files in the home directory but can be configured not to.<br />
[[User:Maze|Maze]] ([[User talk:Maze|talk]]) 03:04, 24 June 2021 (UTC)<br />
<br />
:80% of this page is already for obscure software, so I don't see how it would make a difference. -- [[User:MrX|MrX]] ([[User talk:MrX|talk]]) 11:47, 24 June 2021 (UTC)<br />
<br />
== Where to put workarounds? ==<br />
<br />
Some are statically set Variables, some Variables 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.<br />
<br />
Per user i have them in ~/.bashrc and ~/.bash_aliases (respective XDG_CONFIG_HOME/bash/..., must be set globally before login) and in ~/.xinitrc and ~/.xprofile and/or ~/.xsession (respective XDG_CONFIG_HOME/session/..., globally too).<br />
<br />
But the global settings? Varibles are somehow not set if put in /etc/profile.d, even if loaded from .../Xsession. Should they go to /etc/X11/xinit/xinitrc.d/?</div>Baerbeisserhttps://wiki.archlinux.org/index.php?title=Talk:XAMPP&diff=589294Talk:XAMPP2019-11-18T14:50:19Z<p>Baerbeisser: Is there some way to mark topics as solved?</p>
<hr />
<div>The section {{ic|Local test server security}} doesn't match at all, seems copy-pasted from a Windows-XAMPP-Setup.<br />
I tried to adapt it but there is no folder {{ic|extras}} in {{ic|/opt/lampp/apache2/conf/}} and the format of {{ic|/opt/lampp/apache2/conf/httpd.conf}} is completely different.<br />
<br />
Has someone an idea about the correct setup for LAMPP?<br />
<br />
edit: Managed to fix it. Forget it.<br />
<br />
[[User:Baerbeisser|Baerbeisser]] ([[User talk:Baerbeisser|talk]]) 14:50, 18 November 2019 (UTC)</div>Baerbeisserhttps://wiki.archlinux.org/index.php?title=XAMPP&diff=589293XAMPP2019-11-18T14:46:09Z<p>Baerbeisser: Fixed some Windows-ism's and XAMPP-ism's</p>
<hr />
<div>[[Category:Web server]]<br />
[[cs:XAMPP]]<br />
[[es:XAMPP]]<br />
[[it:XAMPP]]<br />
[[ja:Xampp]]<br />
[http://www.apachefriends.org/en/xampp.html XAMPP] is an easy to install Apache distribution containing MariaDB, PHP and Perl. It contains: Apache, MariaDB, PHP & PEAR, Perl, ProFTPD, phpMyAdmin, OpenSSL, GD, Freetype2, libjpeg, libpng, gdbm, zlib, expat, Sablotron, libxml, Ming, Webalizer, pdf class, ncurses, mod_perl, FreeTDS, gettext, mcrypt, mhash, eAccelerator, SQLite and IMAP C-Client.<br />
<br />
== Installation ==<br />
<br />
==== Using AUR package ====<br />
<br />
Install {{AUR|xampp}}.<br />
<br />
==== Manual Installation ====<br />
<br />
Download the installer from: [https://www.apachefriends.org/index.html the website].<br />
<br />
The downloaded file is an installer script. Make it executable and run it by typing:<br />
<br />
# chmod +x xampp-linux-'''version'''-installer.run <br />
# ./xampp-linux-'''version'''-installer.run <br />
<br />
==== Removal ====<br />
<br />
Be sure to stop all lampp services.<br />
<br />
# /opt/lampp/lampp stop<br />
<br />
All the files needed by Xampp to be installed are located in the previous {{ic|/opt/lampp}} folder. So, to uninstall Xampp:<br />
<br />
# rm -rf /opt/lampp<br />
{{Note|If you created symlinks, you may need to destroy them too.}}<br />
<br />
== Configuration ==<br />
<br />
Setting the individual parts of XAMPP can by made by editing following files:<br />
<br />
{{ic|/opt/lampp/etc/httpd.conf}} - Apache configuration. For example you can change folder with web page's source files.<br />
<br />
{{ic|/opt/lampp/etc/php.ini}} - PHP configuration.<br />
<br />
{{ic|/opt/lampp/phpmyadmin/config.inc.php}} - phpMyAdmin configuration.<br />
<br />
{{ic|/opt/lampp/etc/proftpd.conf}} - proFTP configuration.<br />
<br />
{{ic|/opt/lampp/etc/my.cnf}} - MySQL configuration.<br />
<br />
If you would like to set up security of server, you can do it simply by this command:<br />
# /opt/lampp/lampp security<br />
You will be asked step by step to choose passwords for web page's access, user "pma" for phpMyAdmin, user "root" for MySQL and user "nobody" for proFTP.<br />
<br />
=== Autostart on boot ===<br />
<br />
In order to start Xampp at boot, create a systemd service for it ({{ic|/etc/systemd/system/xampp.service}}):<br />
<br />
[Unit]<br />
Description=XAMPP<br />
<br />
[Service]<br />
ExecStart=/opt/lampp/lampp start<br />
ExecStop=/opt/lampp/lampp stop<br />
Type=forking<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
<br />
[[Enable]] {{ic|xampp.service}}.<br />
<br />
== Usage ==<br />
<br />
Use the following commands to control XAMPP: {{bc|# /opt/lampp/lampp start,stop,restart}}<br />
<br />
If you get this error when you start it:<br />
{{bc|<br />
Starting XAMPP for Linux 1.7.7...<br />
/opt/lampp/lampp: line 21: netstat: command not found<br />
/opt/lampp/lampp: line 21: netstat: command not found<br />
XAMPP: Starting Apache with SSL (and PHP5)...<br />
/opt/lampp/lampp: line 241: /bin/hostname: No such file or directory<br />
/opt/lampp/lampp: line 21: netstat: command not found<br />
XAMPP: Starting MySQL...<br />
/opt/lampp/bin/mysql.server: line 263: hostname: command not found<br />
/opt/lampp/lampp: line 21: netstat: command not found<br />
XAMPP: Starting ProFTPD...<br />
XAMPP for Linux started.<br />
}}<br />
Install {{Pkg|net-tools}} and {{Pkg|inetutils}} from the [[official repositories]].<br />
<br />
== Hosting files outside the htdocs directory ==<br />
<br />
The document root (web root) directory is located at {{ic|/opt/lampp/htdocs/}}. All files placed in this directory will be processed by the web server.<br />
<br />
To host other files on your system with XAMPP, you can configure an alias with apache.<br />
<br />
* Edit apache's httpd.conf with your favorite editor.<br />
# vim /opt/lampp/etc/httpd.conf<br />
* Find "DocumentRoot", you will see something like:<br />
{{bc|<br />
DocumentRoot "/opt/lampp/htdocs"<br />
<Directory "/opt/lampp/htdocs"><br />
... <br />
...<br />
<br />
</Directory>}}<br />
<br />
* In the next line after "</Directory>" paste this:<br />
{{bc|<br />
<Directory "/yourDirectory/"><br />
Options Indexes FollowSymLinks ExecCGI Includes<br />
AllowOverride All<br />
Require all granted<br />
</Directory>}}<br />
<br />
* Next find the "<IfModule alias_module>": <br />
{{bc|<br />
<IfModule alias_module><br />
<br />
#<br />
# Redirect: Allows you to tell clients about documents that used to <br />
# exist in your server's namespace, but do not anymore. The client <br />
# will make a new request for the document at its new location.<br />
# Example:<br />
# Redirect permanent /foo http://www.example.com/bar<br />
...<br />
</IfModule><br />
}}<br />
* And before the "</IfModule>" paste this:<br />
<br />
Alias /yourAlias /yourDirectory/<br />
<br />
* Now do not forget to restart Apache:<br />
# /opt/lampp/lampp restart<br />
<br />
This will allow you to host files from your home directory (or any other directory) with XAMPP.<br />
<br />
In the above example, you can access the files by pointing your web browser to '''localhost/yourAlias'''.<br />
<br />
== Debugging and profiling with Xdebug and Xampp ==<br />
<br />
For detailed instructions go [http://xdebug.org/find-binary.php here].<br />
<br />
You must first download the Xampp Development Tools from the same download page [http://www.apachefriends.org/en/xampp-linux.html here].<br />
<br />
Extract this into your Xampp directory:<br />
<br />
# tar xvfz xampp-linux-devel-x.x.x.tar.gz -C /opt<br />
<br />
You should be able to successfully run<br />
/opt/lampp/bin/phpize<br />
in your xdebug folder.<br />
<br />
== PhpMyAdmin 403 Access Forbidden ==<br />
<br />
If your http://localhost/phpmyadmin returns "403 Access Forbidden", you need to edit the following settings in {{ic|/opt/lampp/etc/extra/httpd-xampp.conf}}:<br />
<br />
<Directory "/opt/lampp/phpmyadmin"><br />
AllowOverride AuthConfig Limit<br />
#Order allow,deny<br />
#Allow from all<br />
Require all granted<br />
</Directory><br />
<br />
== Local test server security ==<br />
<br />
Apache and MySQL can be configured so that they only listen to requests from your own computer. For most test systems this is fine and it greatly reduces the risk because the services are not reachable from the Internet.<br />
<br />
Before you start XAMPP for the first time find and edit these files:<br />
<br />
For Apache edit the files {{ic|/opt/lampp/etc/httpd.conf}} and {{ic|/opt/lampp/etc/extra/httpd-ssl.conf}}. Look for lines starting with "Listen" such as<br />
<br />
Listen 80<br />
<br />
and replace them with<br />
<br />
Listen 127.0.0.1:80<br />
<br />
For MySQL open the file {{ic|/opt/lampp/etc/my.cnf}} find the section "[mysqld]" and add this line<br />
<br />
bind-address=localhost<br />
<br />
After starting the services, verify the result by going to a command window and start and execute:<br />
<br />
netstat -a -n<br />
<br />
For the entries marked as LISTEN in the last column, look at the Listen column. It should always start with 127.0.0.1 or ::1 but not with 0.0.0.0.</div>Baerbeisserhttps://wiki.archlinux.org/index.php?title=Talk:XAMPP&diff=589292Talk:XAMPP2019-11-18T14:40:12Z<p>Baerbeisser: formatting-edit</p>
<hr />
<div>The section {{ic|Local test server security}} doesn't match at all, seems copy-pasted from a Windows-XAMPP-Setup.<br />
I tried to adapt it but there is no folder {{ic|extras}} in {{ic|/opt/lampp/apache2/conf/}} and the format of {{ic|/opt/lampp/apache2/conf/httpd.conf}} is completely different.<br />
<br />
Has someone an idea about the correct setup for LAMPP?<br />
<br />
[[User:Baerbeisser|Baerbeisser]] ([[User talk:Baerbeisser|talk]]) 14:37, 18 November 2019 (UTC)</div>Baerbeisserhttps://wiki.archlinux.org/index.php?title=Talk:XAMPP&diff=589291Talk:XAMPP2019-11-18T14:37:33Z<p>Baerbeisser: Created page with "The section 'Local test server security' doesn't match at all, seems copy-pasted from a Windows-XAMPP-Setup. I tried to adapt it but there is no folder 'extras' in '/opt/lampp..."</p>
<hr />
<div>The section 'Local test server security' doesn't match at all, seems copy-pasted from a Windows-XAMPP-Setup.<br />
I tried to adapt it but there is no folder 'extras' in '/opt/lampp/apache2/conf/' and the format of '/opt/lampp/apache2/conf/httpd.conf' is completely different.<br />
<br />
Has someone an idea about the correct setup for LAMPP?<br />
<br />
[[User:Baerbeisser|Baerbeisser]] ([[User talk:Baerbeisser|talk]]) 14:37, 18 November 2019 (UTC)</div>Baerbeisserhttps://wiki.archlinux.org/index.php?title=Kernel_module&diff=582294Kernel module2019-09-14T12:51:21Z<p>Baerbeisser: replaced /bin/false with /bin/true, cause /bin/false sets return code to 1 (false), which caused issues for me.</p>
<hr />
<div>[[Category:Kernel]]<br />
[[Category:Hardware detection and troubleshooting]]<br />
[[Category:Boot process]]<br />
[[es:Kernel module]]<br />
[[fr:Kernel modules]]<br />
[[it:Kernel module]]<br />
[[ja:カーネルモジュール]]<br />
[[ru:Kernel module]]<br />
[[zh-hans:Kernel module]]<br />
{{Related articles start}}<br />
{{Related|Boot debugging}}<br />
{{Related|Kernels}}<br />
{{Related|Kernel parameters}}<br />
{{Related|Compile kernel module}}<br />
{{Related articles end}}<br />
<br />
[[Wikipedia:Loadable_kernel_module|Kernel modules]] are pieces of code that can be loaded and unloaded into the kernel upon demand. They extend the functionality of the kernel without the need to reboot the system. <br />
<br />
To create a kernel module, you can read [http://tldp.org/LDP/lkmpg/2.6/html/index.html The Linux Kernel Module Programming Guide]. A module can be configured as built-in or loadable. To dynamically load or remove a module, it has to be configured as a loadable module in the kernel configuration (the line related to the module will therefore display the letter {{ic|M}}).<br />
<br />
== Obtaining information ==<br />
<br />
Modules are stored in {{ic|/usr/lib/modules/''kernel_release''}}. You can use the command {{ic|uname -r}} to get your current kernel release version.<br />
<br />
{{Note|Module names often use underscores ({{ic|_}}) or dashes ({{ic|-}}); however, those symbols are interchangeable when using the {{ic|modprobe}} command and in configuration files in {{ic|/etc/modprobe.d/}}.}}<br />
<br />
To show what kernel modules are currently loaded:<br />
<br />
$ lsmod<br />
<br />
To show information about a module:<br />
<br />
$ modinfo ''module_name''<br />
<br />
To list the options that are set for a loaded module:<br />
<br />
$ systool -v -m ''module_name''<br />
<br />
To display the comprehensive configuration of all the modules:<br />
<br />
$ modprobe -c | less<br />
<br />
To display the configuration of a particular module:<br />
<br />
$ modprobe -c | grep ''module_name''<br />
<br />
List the dependencies of a module (or alias), including the module itself:<br />
<br />
$ modprobe --show-depends ''module_name''<br />
<br />
== Automatic module loading with systemd ==<br />
<br />
Today, all necessary modules loading is handled automatically by [[udev]], so if you do not need to use any out-of-tree kernel modules, there is no need to put modules that should be loaded at boot in any configuration file. However, there are cases where you might want to load an extra module during the boot process, or blacklist another one for your computer to function properly.<br />
<br />
Kernel modules can be explicitly listed in files under {{ic|/etc/modules-load.d/}} for systemd to load them during boot. Each configuration file is named in the style of {{ic|/etc/modules-load.d/<program>.conf}}. Configuration files simply contain a list of kernel modules names to load, separated by newlines. Empty lines and lines whose first non-whitespace character is {{ic|#}} or {{ic|;}} are ignored.<br />
<br />
{{hc|/etc/modules-load.d/virtio-net.conf|<br />
# Load virtio_net.ko at boot<br />
virtio_net}}<br />
<br />
See {{man|5|modules-load.d}} for more details.<br />
<br />
== Manual module handling ==<br />
<br />
Kernel modules are handled by tools provided by {{Pkg|kmod}} package. You can use these tools manually.<br />
<br />
{{Note|If you have upgraded your kernel but have not yet rebooted, ''modprobe'' will fail with no error message and exit with code 1, because the path {{ic|/usr/lib/modules/$(uname -r)/}} no longer exists. Check manually if this path exists when ''modprobe'' failed to determine if this is the case.}}<br />
<br />
To load a module:<br />
<br />
# modprobe ''module_name''<br />
<br />
To load a module by filename (i.e. one that is not installed in {{ic|/usr/lib/modules/$(uname -r)/}}):<br />
<br />
# insmod filename [args]<br />
<br />
To unload a module:<br />
<br />
# modprobe -r ''module_name''<br />
<br />
Or, alternatively:<br />
<br />
# rmmod ''module_name''<br />
<br />
== Setting module options ==<br />
<br />
To pass a parameter to a kernel module, you can pass them manually with modprobe or assure certain parameters are always applied using a modprobe configuration file or by using the kernel command line.<br />
<br />
=== Manually at load time using modprobe ===<br />
<br />
The basic way to pass parameters to a module is using the modprobe command. Parameters are specified on command line using simple {{ic|1=''key=value''}} assignments:<br />
<br />
# modprobe ''module_name parameter_name=parameter_value''<br />
<br />
=== Using files in /etc/modprobe.d/ ===<br />
<br />
Files in {{ic|/etc/modprobe.d/}} directory can be used to pass module settings to [[udev]], which will use {{ic|modprobe}} to manage the loading of the modules during system boot. Configuration files in this directory can have any name, given that they end with the {{ic|.conf}} extension. The syntax is:<br />
<br />
{{hc|/etc/modprobe.d/myfilename.conf|2=<br />
options ''module_name parameter_name=parameter_value''}}<br />
<br />
For example:<br />
<br />
{{hc|/etc/modprobe.d/thinkfan.conf|2=<br />
# On ThinkPads, this lets the 'thinkfan' daemon control fan speed<br />
options thinkpad_acpi fan_control=1}}<br />
<br />
{{Note|If any of the affected modules is loaded from the initramfs, then you will need to add the appropriate {{ic|.conf}} file to {{ic|FILES}} in [[mkinitcpio.conf]] or use the {{ic|modconf}} [[Mkinitcpio.conf#HOOKS|hook]], so that it will be included in the initramfs. To see the contents of the default initramfs use {{ic|lsinitcpio /boot/initramfs-linux.img}}.}}<br />
<br />
=== Using kernel command line ===<br />
<br />
If the module is built into the kernel, you can also pass options to the module using the kernel command line. For all common bootloaders, the following syntax is correct:<br />
<br />
''module_name.parameter_name=parameter_value''<br />
<br />
For example:<br />
<br />
thinkpad_acpi.fan_control=1<br />
<br />
Simply add this to your bootloader's kernel-line, as described in [[Kernel parameters|Kernel Parameters]].<br />
<br />
== Aliasing ==<br />
<br />
Aliases are alternate names for a module. For example: {{ic|alias my-mod really_long_modulename}} means you can use {{ic|modprobe my-mod}} instead of {{ic|modprobe really_long_modulename}}. You can also use shell-style wildcards, so {{ic|alias my-mod* really_long_modulename}} means that {{ic|modprobe my-mod-something}} has the same effect. Create an alias:<br />
<br />
{{hc|/etc/modprobe.d/myalias.conf|<br />
alias mymod really_long_module_name}}<br />
<br />
Some modules have aliases which are used to automatically load them when they are needed by an application. Disabling these aliases can prevent automatic loading but will still allow the modules to be manually loaded.<br />
<br />
{{hc|/etc/modprobe.d/modprobe.conf|<br />
# Prevent Bluetooth autoload<br />
alias net-pf-31 off}}<br />
<br />
== Blacklisting ==<br />
<br />
Blacklisting, in the context of kernel modules, is a mechanism to prevent the kernel module from loading. This could be useful if, for example, the associated hardware is not needed, or if loading that module causes problems: for instance there may be two kernel modules that try to control the same piece of hardware, and loading them together would result in a conflict.<br />
<br />
Some modules are loaded as part of the [[initramfs]]. {{ic|mkinitcpio -M}} will print out all automatically detected modules: to prevent the initramfs from loading some of those modules, blacklist them in a ''.conf'' file under {{ic|/etc/modprobe.d}} and it shall be added in by the {{ic|modconf}} hook during image generation. Running {{ic|mkinitcpio -v}} will list all modules pulled in by the various hooks (e.g. {{ic|filesystems}} hook, {{ic|block}} hook, etc.). Remember to add that ''.conf'' file to the {{ic|FILES}} array in {{ic|/etc/mkinitcpio.conf}}, if you do not have the {{ic|modconf}} hook in your {{ic|HOOKS}} array (e.g. you have deviated from the default configuration), and once you have blacklisted the modules [[regenerate the initramfs]], and reboot afterwards.<br />
<br />
=== Using files in /etc/modprobe.d/ ===<br />
<br />
Create a {{ic|.conf}} file inside {{ic|/etc/modprobe.d/}} and append a line for each module you want to blacklist, using the {{ic|blacklist}} keyword. If for example you want to prevent the {{ic|pcspkr}} module from loading:<br />
<br />
{{hc|/etc/modprobe.d/nobeep.conf|<br />
# Do not load the 'pcspkr' module on boot.<br />
blacklist pcspkr}}<br />
<br />
{{Note|The {{ic|blacklist}} command will blacklist a module so that it will not be loaded automatically, but the module may be loaded if another non-blacklisted module depends on it or if it is loaded manually.<br />
<br />
However, there is a workaround for this behaviour; the {{ic|install}} command instructs modprobe to run a custom command instead of inserting the module in the kernel as normal, so you can force the module to always fail loading with:<br />
<br />
{{hc|/etc/modprobe.d/blacklist.conf|<br />
...<br />
install ''module_name'' /bin/true<br />
...}}<br />
<br />
This will effectively blacklist that module and any other that depends on it.}}<br />
<br />
=== Using kernel command line ===<br />
<br />
{{Tip|This can be very useful if a broken module makes it impossible to boot your system.}}<br />
<br />
You can also blacklist modules from the bootloader.<br />
<br />
Simply add {{ic|1=module_blacklist=modname1,modname2,modname3}} to your bootloader's kernel line, as described in [[Kernel parameters]].<br />
<br />
{{Note|When you are blacklisting more than one module, note that they are separated by commas only. Spaces or anything else might presumably break the syntax.}}<br />
<br />
== Troubleshooting ==<br />
<br />
=== Modules do not load ===<br />
<br />
In case a specific module does not load and the boot log (accessible with {{ic|journalctl -b}}) says that the module is blacklisted, but the directory {{ic|/etc/modprobe.d/}} does not show a corresponding entry, check another modprobe source folder at {{ic|/usr/lib/modprobe.d/}} for blacklisting entries.<br />
<br />
A module will not be loaded if the "vermagic" string contained within the kernel module does not match the value of the currently running kernel. If it is known that the module is compatible with the current running kernel the "vermagic" check can be ignored with {{ic|modprobe --force-vermagic}}.<br />
<br />
{{warning|Ignoring the version checks for a kernel module can cause a kernel to crash or a system to exhibit undefined behavior due to incompatibility. Use {{ic|--force-vermagic}} only with the utmost caution.}}<br />
<br />
== See also ==<br />
<br />
* [[Disable PC speaker beep]]<br />
* [https://lwn.net/Articles/391230/ Writing a WMI driver] - an LWM introduction</div>Baerbeisserhttps://wiki.archlinux.org/index.php?title=Talk:Data-at-rest_encryption&diff=578156Talk:Data-at-rest encryption2019-07-27T15:25:27Z<p>Baerbeisser: formatting issues</p>
<hr />
<div>== Add filesystem encryption ==<br />
It is possible to use encryption offered by filesystems, instead of using something like [[dm-crypt]] and [[eCryptfs]].<br />
In most cases they are even better because they offer more flexibility, performance and without the need of something like [[FUSE]] (but that's not part of this scope).<br />
<br />
Should we extend the table listing encryption solutions or simple link to the filesystem page instead?<br />
<br />
[[User:Francoism|Francoism]] ([[User talk:Francoism|talk]]) 11:53, 19 November 2018 (UTC)<br />
<br />
==Unicode graphs/patterns==<br />
''[Original title was Ascii graphs/patterns]''<br />
<br />
Hi,<br />
A small issue unrelated topic : how are ascii graphs/patterns made?<br />
:One method I know is: http://www.asciiflow.com/#Draw<br />
:--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:45, 3 September 2013 (UTC)<br />
::Note that those graphs are not made with simple ASCII characters, but Unicode (I've fixed the title of the discussion).<br />
::Anyway, this is a very interesting question indeed, I too would like to know if there are any editors that can make it easy to draw such diagrams.<br />
::This would also solve [[Talk:Installing Arch Linux with EVMS#Image replacement contest]].<br />
::Finally, an editor like that should be mentioned in [[Help:Style#Non-pertinent content]].<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:47, 4 September 2013 (UTC)<br />
:I created these diagrams manually using [[Wikipedia:Kate_%28text_editor%29|Kate]], which is a normal text editor ''(but it has an advanced feature called "Block Selection Mode" that helps a lot with this kind of stuff)''. I also kept a window of [[Wikipedia:gucharmap|gucharmap]] open on one side of the screen, which allowed me to easily find and pick suitable Unicode characters.<br />
:--[[User:Sas|Sas]] ([[User talk:Sas|talk]]) 19:21, 19 November 2013 (UTC)<br />
<br />
==Move out of User page==<br />
This page is quite good IMO. So it can be moved to a normal page. It can receive updates there and other pepole can contribute. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 06:20, 11 June 2012 (UTC)<br />
:+1 -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:18, 12 June 2012 (UTC)<br />
: No respons from author. This will block [System_Encryption_with_LUKS] restructure so I do the job to move on.-- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 02:22, 15 June 2012 (UTC)<br />
:: Hi, and sorry for abandoning this article half-way through and then forgetting about it.<br />
:: As for writing the general introduction/explanation text (part of which consists of merging the corresponding sections from the [[System_Encryption_with_LUKS]] article into this one), I had already started working on that locally back when I created this article, but I have that file on a different computer than I am on now. If you give me until tomorrow (Monday) evening (European time), I'll bring what I have into a readable state and upload it to this page, and then everybody can help modifying/extending it.<br />
:: The reason why I created the article as a user page and didn't move it into the main namespace right away, is that I originally planned to first discuss some feature requests with the wiki maintainers which would make the page more maintainable (without sacrificing user-friendliness). Namely, support for automatically numbered footnotes, and moving the comparison table formatting into a wiki-wide "comparison-table" CSS class (or maybe, separate "comparison-table-vertical" and "comparison-table-horizontal" classes). Right now, the comparison table's wiki markup is so messy and difficult to work with that I would feel guilty asking other people to help add info to it. --[[User:Sas|Sas]] ([[User talk:Sas|talk]]) 17:35, 17 June 2012 (UTC)<br />
::: I added the main text sections now. It would be great if a native speaker with good language skills could do some copyediting for the individual subsections to formulate them more concisely and make them nicer to read. --[[User:Sas|Sas]] ([[User talk:Sas|talk]]) 20:42, 18 June 2012 (UTC)<br />
::::Hi Sas, thank you for getting back working on this article!!<br />
::::About the numbered footnotes, that would require the installation of an extension (involving web developers) and if we can keep it simpler instead it'd be better, since this would be the only article using that feature.<br />
::::About the comparison-table class, can you report an existing example (in another wiki I guess) of what you mean exactly?<br />
::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 20:57, 19 June 2012 (UTC)<br />
<br />
== Proposed renaming of this article to "System Encryption" or "Encryption" ==<br />
<br />
This was proposed by Kynikos in the form of a template added to this article, and also discussed [[Talk:System_Encryption_with_LUKS#Moving_the_.22why_should_I_use_encryption.22_section_to_a_separate_article|here]].<br />
<br />
I disagree with the proposal, and still believe that "Disk Encryption" is the right name for this article. Let me try to explain why.<br />
<br />
"Encryption" is a huge topic, encompassing a ''much'' bigger scope than this article could sensibly cover in the level of detail set out by the content I already added here, and the content that is to be merged here from [[System_Encryption_with_LUKS]].<br />
There is (among others)...<br />
* <span style="color:#00f">manual encryption of '''pieces of data''' (no matter where it comes from / is stored / is going to)</span><br />
** ''<span style="color:#777">GnuPG, ...</span>''<br />
* <span style="color:#00f">cryptographically protecting a '''communication channel'''</span><br />
** ''<span style="color:#777">HTTPS, SSH, ...</span>''<br />
* <span style="color:#00f">cryptographically protecting a '''logical part of a storage disk''' (real or virtual)</span><br />
** ''<span style="color:#777">Loop-AES, dm-crypt+LUKS, Truecrypt, eCryptfs, EncFs, ...</span>''<br />
<br />
I believe that the article should exclusively deal with the latter topic.<br />
Trust me, there's enough valuable information on this to fill a whole article (just look at how big the comparison table alone grew already). It would only add confusion and result in TL;DR to mix other encryption-related topics into the same article.<br />
<br />
I.e., the article should exclusively be about techniques which will cause all data written to a logical part of a disk to be automatically encrypted, and data read from it to be automatically decrypted.<br />
<br />
All of the following are examples of logical parts of (real or virtual) storage disks:<br />
* a '''whole disk'''<br />
* a '''partition''' (or anything else represented as a block device)<br />
* a '''folder'''<br />
So I don't see how the term "Disk Encryption" should be inclusive of block device encryption, but not of filesystem-level encryption, as Kynikos suggested in the renaming-proposal.<br />
The level at which the protected logical part of the disc is defined, is an just implementation detail - I don't see a conceptual difference there.<br />
<br />
So that's why I believe "Disk Encryption" is a more sensible title than "Encryption".<br />
<br />
Regarding "System Encryption", I believe ''that'' would actually not be inclusive enough of everything encompassed by the encryption methods described here.<br />
<br />
In my mind, '''system encryption''' is a potential ''application'' of disk encryption - it's about securing the "system" itself (as in, an Arch Linux installation) from unauthorized access to its system and user data while the system is not running.<br />
<br />
But disk encryption can also be used for simple '''data encryption''', e.g. protecting a partition or folder in which confidential data files are to be stored, and letting the user unlock/lock the encrypted data container on demand or on login/logout. This has nothing to do with the "system" and whether it is running.<br />
(This is especially the case for the filesystem-based disk encryption methods.)<br />
<br />
And of course there are many possible combinations and shades of grey in between.<br />
<br />
"Disk encryption", to my ears at least, captures all of that quite nicely.<br />
<br />
--[[User:Sas|Sas]] ([[User talk:Sas|talk]]) 18:37, 17 June 2012 (UTC)<br />
<br />
:Wow, you provided such an exhaustive argumentation in support of the current title that I don't think anyone will try to reply (including me) :) Let's stick with [[Disk Encryption]] then! It's worth to be noted that Wikipedia itself is a bit ambiguous in finding a consistent naming for this topic, see for example the intro of [[wikipedia:Filesystem-level encryption]] (''"Filesystem-level encryption, often called file or folder encryption, is a form of disk encryption [...]"'') versus [[wikipedia:Disk encryption#Disk encryption vs. filesystem-level encryption]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 21:10, 19 June 2012 (UTC)<br />
<br />
== Was Serpent judged most secure? ==<br />
<br />
According to the fact sheet available from the relevant link (https://web.archive.org/web/20020211162045/http://csrc.nist.gov:80/encryption/aes/round2/aesfact.html), Serpent was not the finalist selected for the relevant standard. According to that fact sheet, the judgement was not that the other finalists (including Serpent) were insecure, but claiming it was judged the most secure seems unmotivated. Have I missed something? What's the source for this? The linked papers are by the researchers who proposed Serpent, aren't they? That's not the judgement of impartial evaluators. --[[User:Margali|cfr]] ([[User talk:Margali|talk]]) 05:03, 4 November 2017 (UTC)<br />
<br />
== Discontinued Windows software ==<br />
<br />
The Windows compatibility row of the comparison table links four discontinued programs (CrossCrypt, FreeOTFE, LibreCrypt and encfs4win).<br />
<br />
Should we just remove them as using unmaintained encryption software is a bad idea?<br />
<br />
--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 08:30, 15 July 2018 (UTC)<br />
<br />
:The same issue can be said about Linux software: see [https://github.com/vgough/encfs/issues/314 issues] of encfs v1.0 and still listing Truecrypt.<br />
:I vote for dropping them and move them to a section of unmaintained/possible dangerous solutions.<br />
:[[User:Francoism|Francoism]] ([[User talk:Francoism|talk]]) 12:02, 19 November 2018 (UTC)<br />
<br />
::Quite a few adaptations have been done to mark Truecrypt as outdated. I'd be generally ok with dropping it, but don't see it urgent and would only be wary about losing info (applicable, not yet migrated to Veracrypt). If there was a new software to feature in the table, I'd be for replacing the Truecrypt column. Encfs development slowed for a long time, yes, but is used widely and supported (same applies for ecryptfs).<br />
::I'm generally against a section of unmaintained software, particularly stuff not in the official repos. Let's drop those windows programs. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:10, 19 November 2018 (UTC)<br />
::Done [https://wiki.archlinux.org/index.php?title=Disk_encryption&type=revision&diff=562448&oldid=555962]. The librecrypt bug tracker appears to be unattended for 1.5 years. Done [https://wiki.archlinux.org/index.php?title=Disk_encryption&type=revision&diff=562449&oldid=562448] too. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 22:06, 8 January 2019 (UTC)<br />
<br />
== About hardware-based full disk encryption ==<br />
<br />
There's a line stating<br />
<br />
"The best remedy might be hardware-based full disk encryption and Trusted Computing."<br />
<br />
As it became known over the last few years, disk-based encryption is often either weak, broken or vulnerable to other attaks, like altering the firmware.<br />
<br />
So the Arch Wiki recommends a propritary solution, which (from the vendors point of view) must be as cheap and fast as possible.<br />
<br />
Should the statement be altered or a warning added?<br />
<br />
[[User:Baerbeisser|Baerbeisser]] ([[User talk:Baerbeisser|talk]]) 15:23, 27 July 2019 (UTC)</div>Baerbeisserhttps://wiki.archlinux.org/index.php?title=Talk:Data-at-rest_encryption&diff=578155Talk:Data-at-rest encryption2019-07-27T15:23:42Z<p>Baerbeisser: /* About hardware-based full disk encryption */ new section</p>
<hr />
<div>== Add filesystem encryption ==<br />
It is possible to use encryption offered by filesystems, instead of using something like [[dm-crypt]] and [[eCryptfs]].<br />
In most cases they are even better because they offer more flexibility, performance and without the need of something like [[FUSE]] (but that's not part of this scope).<br />
<br />
Should we extend the table listing encryption solutions or simple link to the filesystem page instead?<br />
<br />
[[User:Francoism|Francoism]] ([[User talk:Francoism|talk]]) 11:53, 19 November 2018 (UTC)<br />
<br />
==Unicode graphs/patterns==<br />
''[Original title was Ascii graphs/patterns]''<br />
<br />
Hi,<br />
A small issue unrelated topic : how are ascii graphs/patterns made?<br />
:One method I know is: http://www.asciiflow.com/#Draw<br />
:--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:45, 3 September 2013 (UTC)<br />
::Note that those graphs are not made with simple ASCII characters, but Unicode (I've fixed the title of the discussion).<br />
::Anyway, this is a very interesting question indeed, I too would like to know if there are any editors that can make it easy to draw such diagrams.<br />
::This would also solve [[Talk:Installing Arch Linux with EVMS#Image replacement contest]].<br />
::Finally, an editor like that should be mentioned in [[Help:Style#Non-pertinent content]].<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:47, 4 September 2013 (UTC)<br />
:I created these diagrams manually using [[Wikipedia:Kate_%28text_editor%29|Kate]], which is a normal text editor ''(but it has an advanced feature called "Block Selection Mode" that helps a lot with this kind of stuff)''. I also kept a window of [[Wikipedia:gucharmap|gucharmap]] open on one side of the screen, which allowed me to easily find and pick suitable Unicode characters.<br />
:--[[User:Sas|Sas]] ([[User talk:Sas|talk]]) 19:21, 19 November 2013 (UTC)<br />
<br />
==Move out of User page==<br />
This page is quite good IMO. So it can be moved to a normal page. It can receive updates there and other pepole can contribute. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 06:20, 11 June 2012 (UTC)<br />
:+1 -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:18, 12 June 2012 (UTC)<br />
: No respons from author. This will block [System_Encryption_with_LUKS] restructure so I do the job to move on.-- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 02:22, 15 June 2012 (UTC)<br />
:: Hi, and sorry for abandoning this article half-way through and then forgetting about it.<br />
:: As for writing the general introduction/explanation text (part of which consists of merging the corresponding sections from the [[System_Encryption_with_LUKS]] article into this one), I had already started working on that locally back when I created this article, but I have that file on a different computer than I am on now. If you give me until tomorrow (Monday) evening (European time), I'll bring what I have into a readable state and upload it to this page, and then everybody can help modifying/extending it.<br />
:: The reason why I created the article as a user page and didn't move it into the main namespace right away, is that I originally planned to first discuss some feature requests with the wiki maintainers which would make the page more maintainable (without sacrificing user-friendliness). Namely, support for automatically numbered footnotes, and moving the comparison table formatting into a wiki-wide "comparison-table" CSS class (or maybe, separate "comparison-table-vertical" and "comparison-table-horizontal" classes). Right now, the comparison table's wiki markup is so messy and difficult to work with that I would feel guilty asking other people to help add info to it. --[[User:Sas|Sas]] ([[User talk:Sas|talk]]) 17:35, 17 June 2012 (UTC)<br />
::: I added the main text sections now. It would be great if a native speaker with good language skills could do some copyediting for the individual subsections to formulate them more concisely and make them nicer to read. --[[User:Sas|Sas]] ([[User talk:Sas|talk]]) 20:42, 18 June 2012 (UTC)<br />
::::Hi Sas, thank you for getting back working on this article!!<br />
::::About the numbered footnotes, that would require the installation of an extension (involving web developers) and if we can keep it simpler instead it'd be better, since this would be the only article using that feature.<br />
::::About the comparison-table class, can you report an existing example (in another wiki I guess) of what you mean exactly?<br />
::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 20:57, 19 June 2012 (UTC)<br />
<br />
== Proposed renaming of this article to "System Encryption" or "Encryption" ==<br />
<br />
This was proposed by Kynikos in the form of a template added to this article, and also discussed [[Talk:System_Encryption_with_LUKS#Moving_the_.22why_should_I_use_encryption.22_section_to_a_separate_article|here]].<br />
<br />
I disagree with the proposal, and still believe that "Disk Encryption" is the right name for this article. Let me try to explain why.<br />
<br />
"Encryption" is a huge topic, encompassing a ''much'' bigger scope than this article could sensibly cover in the level of detail set out by the content I already added here, and the content that is to be merged here from [[System_Encryption_with_LUKS]].<br />
There is (among others)...<br />
* <span style="color:#00f">manual encryption of '''pieces of data''' (no matter where it comes from / is stored / is going to)</span><br />
** ''<span style="color:#777">GnuPG, ...</span>''<br />
* <span style="color:#00f">cryptographically protecting a '''communication channel'''</span><br />
** ''<span style="color:#777">HTTPS, SSH, ...</span>''<br />
* <span style="color:#00f">cryptographically protecting a '''logical part of a storage disk''' (real or virtual)</span><br />
** ''<span style="color:#777">Loop-AES, dm-crypt+LUKS, Truecrypt, eCryptfs, EncFs, ...</span>''<br />
<br />
I believe that the article should exclusively deal with the latter topic.<br />
Trust me, there's enough valuable information on this to fill a whole article (just look at how big the comparison table alone grew already). It would only add confusion and result in TL;DR to mix other encryption-related topics into the same article.<br />
<br />
I.e., the article should exclusively be about techniques which will cause all data written to a logical part of a disk to be automatically encrypted, and data read from it to be automatically decrypted.<br />
<br />
All of the following are examples of logical parts of (real or virtual) storage disks:<br />
* a '''whole disk'''<br />
* a '''partition''' (or anything else represented as a block device)<br />
* a '''folder'''<br />
So I don't see how the term "Disk Encryption" should be inclusive of block device encryption, but not of filesystem-level encryption, as Kynikos suggested in the renaming-proposal.<br />
The level at which the protected logical part of the disc is defined, is an just implementation detail - I don't see a conceptual difference there.<br />
<br />
So that's why I believe "Disk Encryption" is a more sensible title than "Encryption".<br />
<br />
Regarding "System Encryption", I believe ''that'' would actually not be inclusive enough of everything encompassed by the encryption methods described here.<br />
<br />
In my mind, '''system encryption''' is a potential ''application'' of disk encryption - it's about securing the "system" itself (as in, an Arch Linux installation) from unauthorized access to its system and user data while the system is not running.<br />
<br />
But disk encryption can also be used for simple '''data encryption''', e.g. protecting a partition or folder in which confidential data files are to be stored, and letting the user unlock/lock the encrypted data container on demand or on login/logout. This has nothing to do with the "system" and whether it is running.<br />
(This is especially the case for the filesystem-based disk encryption methods.)<br />
<br />
And of course there are many possible combinations and shades of grey in between.<br />
<br />
"Disk encryption", to my ears at least, captures all of that quite nicely.<br />
<br />
--[[User:Sas|Sas]] ([[User talk:Sas|talk]]) 18:37, 17 June 2012 (UTC)<br />
<br />
:Wow, you provided such an exhaustive argumentation in support of the current title that I don't think anyone will try to reply (including me) :) Let's stick with [[Disk Encryption]] then! It's worth to be noted that Wikipedia itself is a bit ambiguous in finding a consistent naming for this topic, see for example the intro of [[wikipedia:Filesystem-level encryption]] (''"Filesystem-level encryption, often called file or folder encryption, is a form of disk encryption [...]"'') versus [[wikipedia:Disk encryption#Disk encryption vs. filesystem-level encryption]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 21:10, 19 June 2012 (UTC)<br />
<br />
== Was Serpent judged most secure? ==<br />
<br />
According to the fact sheet available from the relevant link (https://web.archive.org/web/20020211162045/http://csrc.nist.gov:80/encryption/aes/round2/aesfact.html), Serpent was not the finalist selected for the relevant standard. According to that fact sheet, the judgement was not that the other finalists (including Serpent) were insecure, but claiming it was judged the most secure seems unmotivated. Have I missed something? What's the source for this? The linked papers are by the researchers who proposed Serpent, aren't they? That's not the judgement of impartial evaluators. --[[User:Margali|cfr]] ([[User talk:Margali|talk]]) 05:03, 4 November 2017 (UTC)<br />
<br />
== Discontinued Windows software ==<br />
<br />
The Windows compatibility row of the comparison table links four discontinued programs (CrossCrypt, FreeOTFE, LibreCrypt and encfs4win).<br />
<br />
Should we just remove them as using unmaintained encryption software is a bad idea?<br />
<br />
--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 08:30, 15 July 2018 (UTC)<br />
<br />
:The same issue can be said about Linux software: see [https://github.com/vgough/encfs/issues/314 issues] of encfs v1.0 and still listing Truecrypt.<br />
:I vote for dropping them and move them to a section of unmaintained/possible dangerous solutions.<br />
:[[User:Francoism|Francoism]] ([[User talk:Francoism|talk]]) 12:02, 19 November 2018 (UTC)<br />
<br />
::Quite a few adaptations have been done to mark Truecrypt as outdated. I'd be generally ok with dropping it, but don't see it urgent and would only be wary about losing info (applicable, not yet migrated to Veracrypt). If there was a new software to feature in the table, I'd be for replacing the Truecrypt column. Encfs development slowed for a long time, yes, but is used widely and supported (same applies for ecryptfs).<br />
::I'm generally against a section of unmaintained software, particularly stuff not in the official repos. Let's drop those windows programs. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:10, 19 November 2018 (UTC)<br />
::Done [https://wiki.archlinux.org/index.php?title=Disk_encryption&type=revision&diff=562448&oldid=555962]. The librecrypt bug tracker appears to be unattended for 1.5 years. Done [https://wiki.archlinux.org/index.php?title=Disk_encryption&type=revision&diff=562449&oldid=562448] too. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 22:06, 8 January 2019 (UTC)<br />
<br />
== About hardware-based full disk encryption ==<br />
<br />
There's a line stating<br />
"The best remedy might be hardware-based full disk encryption and Trusted Computing."<br />
As it became known over the last few years, disk-based encryption is often either weak, broken or vulnerable to other attaks, like altering the firmware.<br />
So the Arch Wiki recommends a propritary solution, which (from the vendors point of view) must be as cheap and fast as possible.<br />
<br />
Should the statement be altered or a warning added?<br />
<br />
[[User:Baerbeisser|Baerbeisser]] ([[User talk:Baerbeisser|talk]]) 15:23, 27 July 2019 (UTC)</div>Baerbeisser