https://wiki.archlinux.org/api.php?action=feedcontributions&user=Gesh&feedformat=atomArchWiki - User contributions [en]2024-03-29T09:41:09ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Talk:Python_package_guidelines&diff=800703Talk:Python package guidelines2024-02-18T10:53:46Z<p>Gesh: Indent my comment more for clarity -- currently looks like Levitating's last paragraph is mine</p>
<hr />
<div>There is going to be an official policy drafted to deal with .pyc/.pyo files. See: https://wiki.archlinux.org/index.php/User:Allan/Python_Packaging_Policy<br />
<br />
== tests directory ==<br />
<br />
The article states that one shouldn't install a "tests" directory. My package however, after running through setup.py, contains such a directory. What is the recommended way to deal with this? Can this directory be deleted? Couldn't find a clue in other Python packages I've looked at, so can someone maybe point me in the right direction?<br />
<br />
: You should probably delete it from "${pkgdir}". I don't know of any reason to have such a directory, unless it contains unittests for the module. Which probably means upstream should be advised to fix their setup.py because there is no reason to run unittests on an installed module, and the module itself certainly shouldn't rely on methods hidden in the unittests...<br />
<br />
: I don't actually know of any misbehaving modules to point to which violate that rule though.<br />
: [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 18:52, 19 December 2016 (UTC)<br />
<br />
:: To the best of my knowledge, the recommendation is designed to prevent namespace conflicts. If I install your package and execute {{ic|python -c 'import tests'}}, and your code is imported, that's bad; If I install your package and execute {{ic|python -c 'from your_package import tests'}}, and your code is imported, that's fine. Getting this right is a little tricky. For an example of Python code that sidesteps these issues, see [https://github.com/PulpQE/pulp-smash/ this package]. The top-level "tests" directory is not — as of [https://github.com/PulpQE/pulp-smash/pull/458 this PR] — installed by setup.py, and therefore produces no namespace conflicts. The "pulp_smash/tests" directory is installed by setup.py and available as "pulp_smash.tests", and therefore produces no namespace conflicts. [[User:Ichimonji10|Ichimonji10]] ([[User talk:Ichimonji10|talk]]) 21:56, 19 December 2016 (UTC)<br />
<br />
:: I'm experiencing these issues with [https://aur.archlinux.org/packages/python-pendulum/ python-pendulum] and [https://aur.archlinux.org/packages/python-pytzdata/ python-pytzdata], both of which seem to install a global tests directory. Not too familiar with Python packaging, so I'm not sure if it is ok to simply delete those directories? --[[User:Johnpatcher|Johnpatcher]] ([[User talk:Johnpatcher|talk]]) 06:54, 20 December 2016 (UTC)<br />
<br />
: ''The article states that one shouldn't install a "tests" directory.'' - unfortunately, this is no longer the case. I think this statement must be added to the article, or at least a discussion on that. I thought for a while about that, and I am really sure that users don't need program tests: they should be done only by developers. -- [[User:Ynikitenko|Ynikitenko]] ([[User talk:Ynikitenko|talk]]) 14:27, 23 June 2022 (UTC)<br />
<br />
:: It is stated in [[Python package guidelines#Test directory in site-package]] and the wording did not change substantially since 2016. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:59, 23 June 2022 (UTC)<br />
<br />
::: No, in that section it is stated: ''not install a directory named just tests into site-packages''. I understand this phrase as "you can install tests into ''site-packages/mypackage-tests''". I think there should be a phrase about any tests (that they need to be installed in very rare cases). -- [[User:Ynikitenko|Ynikitenko]] ([[User talk:Ynikitenko|talk]]) 16:12, 23 June 2022 (UTC)<br />
<br />
:::: The wording is basically the same since at least [https://wiki.archlinux.org/index.php?title=Python_package_guidelines&oldid=459611#Notes December 2016] which is when this discussion started. As for your wording: there can't be such rule because many official packages would violate it, look at e.g. {{pkg|python-pandas}} or {{pkg|python-sympy}}. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:00, 23 June 2022 (UTC)<br />
<br />
::::: Well, I didn't see that revision (I quoted only this talk here). Thanks for the links! I think, since this is an educational article for package creators, it would be an improvement if we could formulate in what cases tests should be present, and it what they should not? For example, as a hypothetical user of ''python-sympy'' I could wonder: do I need to have its tests installed? Why is the repository 10Mb large? (is it because of tests or not...) -- [[User:Ynikitenko|Ynikitenko]] ([[User talk:Ynikitenko|talk]]) 17:09, 23 June 2022 (UTC)<br />
<br />
:::::: The phrase is supposed to be about buggy packages which misconfigure setuptools. Because setuptools configuration is ancient and basically a cargo cult, people copy configurations that result in not only the intended {{ic|<repository>/<package-name>/}} being packaged, but also {{ic|<repository>/tests/}}. Many packages have this problem, see e.g. [https://github.com/Lightning-AI/lightning/issues/10335 here]. I added some clarifying text in [https://wiki.archlinux.org/index.php?title=Python_package_guidelines&oldid=736240 revision 736240] – [[User:Flying_sheep|flying sheep]] 15:33, 3 July 2022 (UTC)<br />
<br />
== Python version directories ==<br />
For example debian packaging guidelines dictate that python files go into /usr/lib/pythonX/ and OpenSUSE wants files to go into /usr/lib/pythonX.Y/.<br />
<br />
Arch should have a clear guideline where packaged files go into. Most packages have their python files in /usr/lib/pythonX.Y/ but the package openimageio has python files in /usr/lib/python3/.<br />
<br />
[[User:Z3ntu|Z3ntu]] ([[User talk:Z3ntu|talk]]) 12:35, 24 January 2017 (UTC)<br />
<br />
:The {{ic|/usr/lib/python3/}} path does not work: {{bc|<nowiki><br />
>>> import sys<br />
>>> sys.path<br />
['', '/usr/lib/python36.zip', '/usr/lib/python3.6', '/usr/lib/python3.6/lib-dynload', '/home/lahwaacz/.local/lib/python3.6/site-packages', '/usr/lib/python3.6/site-packages']<br />
</nowiki>}} Hence it is a bug and should be reported on the bug tracker. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:46, 24 January 2017 (UTC)<br />
<br />
== Remove pip section in favor of wheels section? ==<br />
<br />
I can’t come up with any reason to use pip other than installing wheels, and wheels are just as easily installed by<br />
<br />
# Unzipping them into the {{ic|$pkgdir}}<br />
# Creating a little wrapper scripts for all console_scripts it provides (Which can be done manually or using {{AUR|install-wheel-scripts}})<br />
<br />
Do you agree? – [[User:Flying_sheep|flying sheep]] 18:08, 12 March 2019 (UTC)<br />
:The relevant specification for installing wheels is [https://www.python.org/dev/peps/pep-0427/ PEP 427] which includes a [https://www.python.org/dev/peps/pep-0427/#installing-a-wheel-distribution-1-0-py32-none-any-whl helpful example] on how to extract a wheel. There are a few steps missing in {{AUR|install-wheel-scripts}}. [[User:Pyfisch|Pyfisch]] ([[User talk:Pyfisch|talk]]) 20:30, 24 February 2021 (UTC)<br />
<br />
::As far as I can tell, I need pip for installing sdists (in my case built for pep517 packages using {{pkg|python-build}}). That said, pip definitely has its quirks, and a simpler solution would definitely be appreciated.[[User:Rmsc|Rmsc]] ([[User talk:Rmsc|talk]]) 12:49, 13 April 2021 (UTC)<br />
<br />
:::{{pkg|python-installer}} now supports our use case with its new CLI, and takes care of more parts than the scripts (e.g. data) – [[User:Flying_sheep|flying sheep]] 15:52, 19 February 2022 (UTC)<br />
<br />
== pyproject2setuppy as dephell alternative for flit/poetry ==<br />
<br />
When packaging first flit/poetry packages for Gentoo, I've written [https://github.com/mgorny/pyproject2setuppy pyproject2setuppy] to avoid the dependency hell involved in other existing solutions (read: I really didn't want to have to package dephell). Perhaps you'd be interested in using it in place of dephell. It's ~200 lines of Python with the only dependency being toml, so it's much lighter on the packager. When the new build systems become more popular, it may also help you avoid circular dependencies. [[User:MGorny|MGorny]] ([[User talk:MGorny|talk]]) 05:41, 4 May 2020 (UTC)<br />
<br />
== Is it time to deprecate Python2? ==<br />
<br />
Python2 is now officially not supported by upstream anymore, and Arch will move on as well. I suggest we make clear in this document, that uploading Python2-modules just for the sake of having them is not ok anymore. Necessary dependencies of un-migrated programs should stay around for the time being. But we have moved on with 32bit, and will do so with Python2 at some point as well. I feel it is time to take first small steps in that direction. [[User:Fordprefect|Fordprefect]] ([[User talk:Fordprefect|talk]]) 13:48, 20 August 2020 (UTC)<br />
<br />
== Future of Python packaging in Arch Linux? ==<br />
<br />
Since PEP 517 and PEP 518 are slowly gaining traction and setuptools wants to deprecate and remove {{ic|setup.py install}} the current guidelines will need to be updated. Right now there are multiple workarounds including {{pkg|python-dephell}}. Is there already a plan to migrate to a standards based build process how does it look like? As far as I know both a package builder and a package installer are needed for this if Arch wants to avoid pip. [https://github.com/pypa/build pypa/build] and [https://github.com/pradyunsg/installer pradyunsg/installer] appear to be packages for this task. FFY00 contributes to both these packages and maintains lots of Arch Python packages, so I assume they are interested in using them here? --[[User:Pyfisch|Pyfisch]] ([[User talk:Pyfisch|talk]]) 21:06, 24 February 2021 (UTC)<br />
<br />
:There's already packages in community that use Poetry. [https://github.com/archlinux/svntogit-community/commit/052b80214776d2c69bd2deb4e013af3634a62a32 python-rich 10.0.1-1]<br />
:[[User:Grawlinson|Grawlinson]] ([[User talk:Grawlinson|talk]]) 00:22, 1 April 2021 (UTC)<br />
<br />
:: Someone added `python-build` instructions to the wiki but I'm interested in us actually discussing the needed changes in an official capacity before randomly adding them to the wiki.<br />
:: [[User:Foxboron|Foxboron]] ([[User talk:Foxboron|talk]]) 12:02, 13 April 2021 (UTC)<br />
<br />
::: That was me, sorry. The current guidelines simply don't work for pep517 packages that install scripts. After spending hours trying to get this to work for my PKGBUILDS, I assumed these would be useful right now for this particular niche. So while perhaps a bit rude (sorry..), it wasn't exactly random.[[User:Rmsc|Rmsc]] ([[User talk:Rmsc|talk]]) 12:37, 13 April 2021 (UTC)<br />
<br />
:::: Yes, calling it "random" wasn't nice :) Sorry. It was more a reference to adding it without any discussion then the change itself. I have asked FFY00 if we should draft something or wait. Hopefully something is going to crop up the next week or something.<br />
:::: [[User:Foxboron|Foxboron]] ([[User talk:Foxboron|talk]]) 12:56, 13 April 2021 (UTC)<br />
<br />
::::: python-build is mature, the usage of pip is the issue here, as it's not very nice. I really don't like dephell, as IMO it is essentially a hack and can fail in obscure ways, but other people think it is fine. I would mention the two approaches, python-dephell and python-build/python-pip, for now. Once we have a proper standalone wheel installer that can replace pip, I will submit a RFC proposing to change all packages to python-build/python-installer. Btw, there are some issues with the change. --skip-dependencies does not prevent pip from being used, --no-isolation does that, --skip-dependencies will simply skip the check that looks if the dependencies are met, I don't think it should be used here. We should also be building a wheel, to install with pip, not a sdist. The correct command would be `python -m build --wheel --no-isolation` or `python -m build -wn`. [[User:FFY00|FFY00]] ([[User talk:FFY00|talk]]) 13:17, 13 April 2021 (UTC)<br />
<br />
:::::: No problem, my bad :) I've tested the proposed fixes (no --skip-dependencies and --wheel) and it works even better (pip would always build a wheel no matter what). I also dislike having to use ''pip install'', and would rather replace it with a stand-alone installer. If you feel it's appropriate as a temporary thing, I can fix and reintroduce the python-build/python-pip changes.<br />
<br />
:::::: In the meantime I was also preparing a few changes to the ''pip'' section. The issue in https://github.com/pypa/pip/issues/2209 is no longer relevant (was closed in 2017), but the pyo and pyc files generated by pip are still broken (they contain references to $pkgdir). There are a few community packages affected by the problem (tensorflow stuff, for instance). I would like to suggest adding ''--no-compile'' to the recommended pip flags, and using 'compileall' instead. If that's ok, I have the change ready to submit.[[User:Rmsc|Rmsc]] ([[User talk:Rmsc|talk]]) 15:50, 13 April 2021 (UTC)<br />
<br />
::::::: pip builds wheels in isolation (isolated environment) by default and IIRC it had some issues building without isolation. I agree that passing --no-compile to pip and running compileall afterwards is a correct solution. [[User:FFY00|FFY00]] ([[User talk:FFY00|talk]]) 17:24, 13 April 2021 (UTC)<br />
<br />
:::::::: As a side note for compileall - since Python 3.9 ([https://bugs.python.org/issue38112 Issue 38112: Compileall improvements - Python tracker]), compileall supports -s and -p for stripping and prepending paths, so that there will not be $pkgdir in pyc files. The overall affect is similar to what -d does, while more intuitive. Here is an example usage:<br />
:::::::: {{bc|python -m compileall -s "$pkgdir" -p / "$pkgdir"/usr/lib}} [[User:Yan12125|Yan12125]] ([[User talk:Yan12125|talk]]) 07:51, 26 November 2021 (UTC)<br />
<br />
: I tried to have a quick summary for possible solutions in the below table. Feel free to update it if some information is incorrect/missing/out-dated. --[[User:Yan12125|Yan12125]] ([[User talk:Yan12125|talk]]) 08:09, 26 November 2021 (UTC)<br />
<br />
:{| class="wikitable"<br />
|+ Python packaging tools targetting PEP 517/PEP 518<br />
! Tools !! Pros !! Cons<br />
|-<br />
| dephell + setuptools || || <ol><li>No longer maintained ([https://github.com/dephell/dephell GitHub project] archived)</li><li>Not actually building packages following PEP 517/PEP 518</li></ol><br />
|-<br />
| pyproject2setuppy + setuptools || <ol><li>Actively maintained</li></ol> || <ol><li>Similar to dephell, not actually building packages following PEP 517/PEP 518</li></ol><br />
|-<br />
| python-build + python-install || <ol><li>python-build is a PyPA project</li><li>python-install is maintained by an Arch TU</li></ol> || <ol><li>Requires further development; no stable release yet</li></ol><br />
|-<br />
| python-build + python-pip || <ol><li>pip is actively maintained and widely used</li></ol> || <ol><li>many dependencies</li><li>Does not support stripping $pkgdir from pycs out of box<br />
|-<br />
| python-build + python-installer || <ol><li>python-installer is maintained by a PyPA member</li></ol> || <ol><li>No CLI yet https://github.com/pradyunsg/installer/pull/66<br />
|}<br />
<br />
::So since {{pkg|python-installer}} now has a CLI, we can use it. I updated the page accordingly, as the last table entry now reads as follows.<br />
::This approach will probably be the future. I think it allows for bootstrapping our whole Python toolchain. – [[User:Flying_sheep|flying sheep]] 15:49, 19 February 2022 (UTC)<br />
:According to the packaging guidelines, invocation of `setup.py` directly is deprecated. [1]<br />
:It suggests just building a wheel using <code>python -m build</code><br />
:From my testing this works fine. Should a distinction between a project with a `pyproject.toml` and `setup.py` even be made?<br />
:[1]: https://packaging.python.org/en/latest/discussions/setup-py-deprecated/#what-commands-should-be-used-instead [[User:Levitating|Levitating]] ([[User talk:Levitating|talk]]) 04:03, 29 January 2024 (UTC)<br />
::{| class="wikitable"<br />
|+ Python packaging tools targetting PEP 517/PEP 518<br />
! Tools !! Pros !! Cons<br />
|-<br />
| {{pkg|python-build}} + {{pkg|python-installer}} || <ol><li>Are PyPA projects</li><li>A lot of design consideration went into both to enable explicitly our use case</li></ol> ||<br />
|}<br />
<br />
::: Rereading [https://peps.python.org/pep-0517/ PEP517], explicit invocation of {{ic|setup.py}} is unnecessary and deprecated -- it explicitly states: "If the pyproject.toml file is absent, or the build-backend key is missing, the source tree is not using this specification, and tools should revert to the legacy behaviour of running setup.py (either directly, or by implicitly invoking the setuptools.build_meta:__legacy__ backend)."<br />
::: In other words, it should be safe to recommend using {{pkg|python-build}} and {{pkg|python-installer}} everywhere, with the possible caveat that we should recommend falling back to looking in {{ic|setup.py}} for dependencies if {{ic|pyproject.toml}} doesn't exist.<br />
::: Indeed, checking eg with {{aur|papis-git}}, despite the project not having been rewritten for PEP517, a PEP517-style build works fine for it.<br />
::: [[User:Gesh|Gesh]] ([[User talk:Gesh|talk]]) 10:53, 18 February 2024 (UTC)<br />
<br />
== Pytest downloads dependencies if unmet ==<br />
<br />
I'm currently looking at [https://bugs.archlinux.org/task/69967 a bug] in python-keyring caused by the Arch packaging shipping a) without specifying a required dependency and b) without the required version of the dependency being in the Arch repos yet. And yet, python-keyring has a check() function and the tests pass. The reason for this is that pytest actually downloads unmet dependencies from PyPI solely for the purposes of running the tests. This kind of defeats some of the purpose of the check() function, as this ought to be an error. I propose changing the recommended 'setup.py pytest' line to:<br />
<br />
python setup.py pytest --allow-hosts ','<br />
<br />
Which blocks it from downloading anything, turning unmet dependencies into errors. There are probably similar changes than can be made to other test runners. [[User:Chrisjbillington|Chrisjbillington]] ([[User talk:Chrisjbillington|talk]]) 03:23, 13 March 2021 (UTC)<br />
<br />
== python3- upstream name ==<br />
<br />
Are there any guidelines for when package upstream has name which begins with python3-?<br />
<br />
Example is this one https://aur.archlinux.org/packages/python3-saml where the upstream repo is also named python3-saml. Should it be python3- or be renamed to python-?<br />
<br />
Cheers.<br />
[[User:Micwoj92|Micwoj92]] ([[User talk:Micwoj92|talk]]) 00:04, 3 April 2021 (UTC)<br />
<br />
:To avoid namespace conflicts, use upstream's name as-is. In that particular example, {{ic|python-python3-saml}} is appropriate.<br />
:[[User:Grawlinson|Grawlinson]] ([[User talk:Grawlinson|talk]]) 19:49, 25 August 2021 (UTC)<br />
<br />
== Thoughts on PEP-610's direct_url.json ==<br />
<br />
[https://www.python.org/dev/peps/pep-0610/ PEP-610] has been supported in {{Pkg|poetry}} for a while now.<br />
<br />
It creates a {{ic|direct_url.json}} file that serves no purpose except to take up space.<br />
<br />
[[User:Grawlinson|Grawlinson]] ([[User talk:Grawlinson|talk]]) 19:43, 25 August 2021 (UTC)<br />
<br />
:That is not true. https://www.python.org/dev/peps/pep-0610/#freezing-an-environment particularly stands out. [[User:FFY00|FFY00]] ([[User talk:FFY00|talk]])</div>Geshhttps://wiki.archlinux.org/index.php?title=Talk:Python_package_guidelines&diff=800702Talk:Python package guidelines2024-02-18T10:51:58Z<p>Gesh: Forgot signature</p>
<hr />
<div>There is going to be an official policy drafted to deal with .pyc/.pyo files. See: https://wiki.archlinux.org/index.php/User:Allan/Python_Packaging_Policy<br />
<br />
== tests directory ==<br />
<br />
The article states that one shouldn't install a "tests" directory. My package however, after running through setup.py, contains such a directory. What is the recommended way to deal with this? Can this directory be deleted? Couldn't find a clue in other Python packages I've looked at, so can someone maybe point me in the right direction?<br />
<br />
: You should probably delete it from "${pkgdir}". I don't know of any reason to have such a directory, unless it contains unittests for the module. Which probably means upstream should be advised to fix their setup.py because there is no reason to run unittests on an installed module, and the module itself certainly shouldn't rely on methods hidden in the unittests...<br />
<br />
: I don't actually know of any misbehaving modules to point to which violate that rule though.<br />
: [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 18:52, 19 December 2016 (UTC)<br />
<br />
:: To the best of my knowledge, the recommendation is designed to prevent namespace conflicts. If I install your package and execute {{ic|python -c 'import tests'}}, and your code is imported, that's bad; If I install your package and execute {{ic|python -c 'from your_package import tests'}}, and your code is imported, that's fine. Getting this right is a little tricky. For an example of Python code that sidesteps these issues, see [https://github.com/PulpQE/pulp-smash/ this package]. The top-level "tests" directory is not — as of [https://github.com/PulpQE/pulp-smash/pull/458 this PR] — installed by setup.py, and therefore produces no namespace conflicts. The "pulp_smash/tests" directory is installed by setup.py and available as "pulp_smash.tests", and therefore produces no namespace conflicts. [[User:Ichimonji10|Ichimonji10]] ([[User talk:Ichimonji10|talk]]) 21:56, 19 December 2016 (UTC)<br />
<br />
:: I'm experiencing these issues with [https://aur.archlinux.org/packages/python-pendulum/ python-pendulum] and [https://aur.archlinux.org/packages/python-pytzdata/ python-pytzdata], both of which seem to install a global tests directory. Not too familiar with Python packaging, so I'm not sure if it is ok to simply delete those directories? --[[User:Johnpatcher|Johnpatcher]] ([[User talk:Johnpatcher|talk]]) 06:54, 20 December 2016 (UTC)<br />
<br />
: ''The article states that one shouldn't install a "tests" directory.'' - unfortunately, this is no longer the case. I think this statement must be added to the article, or at least a discussion on that. I thought for a while about that, and I am really sure that users don't need program tests: they should be done only by developers. -- [[User:Ynikitenko|Ynikitenko]] ([[User talk:Ynikitenko|talk]]) 14:27, 23 June 2022 (UTC)<br />
<br />
:: It is stated in [[Python package guidelines#Test directory in site-package]] and the wording did not change substantially since 2016. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:59, 23 June 2022 (UTC)<br />
<br />
::: No, in that section it is stated: ''not install a directory named just tests into site-packages''. I understand this phrase as "you can install tests into ''site-packages/mypackage-tests''". I think there should be a phrase about any tests (that they need to be installed in very rare cases). -- [[User:Ynikitenko|Ynikitenko]] ([[User talk:Ynikitenko|talk]]) 16:12, 23 June 2022 (UTC)<br />
<br />
:::: The wording is basically the same since at least [https://wiki.archlinux.org/index.php?title=Python_package_guidelines&oldid=459611#Notes December 2016] which is when this discussion started. As for your wording: there can't be such rule because many official packages would violate it, look at e.g. {{pkg|python-pandas}} or {{pkg|python-sympy}}. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:00, 23 June 2022 (UTC)<br />
<br />
::::: Well, I didn't see that revision (I quoted only this talk here). Thanks for the links! I think, since this is an educational article for package creators, it would be an improvement if we could formulate in what cases tests should be present, and it what they should not? For example, as a hypothetical user of ''python-sympy'' I could wonder: do I need to have its tests installed? Why is the repository 10Mb large? (is it because of tests or not...) -- [[User:Ynikitenko|Ynikitenko]] ([[User talk:Ynikitenko|talk]]) 17:09, 23 June 2022 (UTC)<br />
<br />
:::::: The phrase is supposed to be about buggy packages which misconfigure setuptools. Because setuptools configuration is ancient and basically a cargo cult, people copy configurations that result in not only the intended {{ic|<repository>/<package-name>/}} being packaged, but also {{ic|<repository>/tests/}}. Many packages have this problem, see e.g. [https://github.com/Lightning-AI/lightning/issues/10335 here]. I added some clarifying text in [https://wiki.archlinux.org/index.php?title=Python_package_guidelines&oldid=736240 revision 736240] – [[User:Flying_sheep|flying sheep]] 15:33, 3 July 2022 (UTC)<br />
<br />
== Python version directories ==<br />
For example debian packaging guidelines dictate that python files go into /usr/lib/pythonX/ and OpenSUSE wants files to go into /usr/lib/pythonX.Y/.<br />
<br />
Arch should have a clear guideline where packaged files go into. Most packages have their python files in /usr/lib/pythonX.Y/ but the package openimageio has python files in /usr/lib/python3/.<br />
<br />
[[User:Z3ntu|Z3ntu]] ([[User talk:Z3ntu|talk]]) 12:35, 24 January 2017 (UTC)<br />
<br />
:The {{ic|/usr/lib/python3/}} path does not work: {{bc|<nowiki><br />
>>> import sys<br />
>>> sys.path<br />
['', '/usr/lib/python36.zip', '/usr/lib/python3.6', '/usr/lib/python3.6/lib-dynload', '/home/lahwaacz/.local/lib/python3.6/site-packages', '/usr/lib/python3.6/site-packages']<br />
</nowiki>}} Hence it is a bug and should be reported on the bug tracker. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:46, 24 January 2017 (UTC)<br />
<br />
== Remove pip section in favor of wheels section? ==<br />
<br />
I can’t come up with any reason to use pip other than installing wheels, and wheels are just as easily installed by<br />
<br />
# Unzipping them into the {{ic|$pkgdir}}<br />
# Creating a little wrapper scripts for all console_scripts it provides (Which can be done manually or using {{AUR|install-wheel-scripts}})<br />
<br />
Do you agree? – [[User:Flying_sheep|flying sheep]] 18:08, 12 March 2019 (UTC)<br />
:The relevant specification for installing wheels is [https://www.python.org/dev/peps/pep-0427/ PEP 427] which includes a [https://www.python.org/dev/peps/pep-0427/#installing-a-wheel-distribution-1-0-py32-none-any-whl helpful example] on how to extract a wheel. There are a few steps missing in {{AUR|install-wheel-scripts}}. [[User:Pyfisch|Pyfisch]] ([[User talk:Pyfisch|talk]]) 20:30, 24 February 2021 (UTC)<br />
<br />
::As far as I can tell, I need pip for installing sdists (in my case built for pep517 packages using {{pkg|python-build}}). That said, pip definitely has its quirks, and a simpler solution would definitely be appreciated.[[User:Rmsc|Rmsc]] ([[User talk:Rmsc|talk]]) 12:49, 13 April 2021 (UTC)<br />
<br />
:::{{pkg|python-installer}} now supports our use case with its new CLI, and takes care of more parts than the scripts (e.g. data) – [[User:Flying_sheep|flying sheep]] 15:52, 19 February 2022 (UTC)<br />
<br />
== pyproject2setuppy as dephell alternative for flit/poetry ==<br />
<br />
When packaging first flit/poetry packages for Gentoo, I've written [https://github.com/mgorny/pyproject2setuppy pyproject2setuppy] to avoid the dependency hell involved in other existing solutions (read: I really didn't want to have to package dephell). Perhaps you'd be interested in using it in place of dephell. It's ~200 lines of Python with the only dependency being toml, so it's much lighter on the packager. When the new build systems become more popular, it may also help you avoid circular dependencies. [[User:MGorny|MGorny]] ([[User talk:MGorny|talk]]) 05:41, 4 May 2020 (UTC)<br />
<br />
== Is it time to deprecate Python2? ==<br />
<br />
Python2 is now officially not supported by upstream anymore, and Arch will move on as well. I suggest we make clear in this document, that uploading Python2-modules just for the sake of having them is not ok anymore. Necessary dependencies of un-migrated programs should stay around for the time being. But we have moved on with 32bit, and will do so with Python2 at some point as well. I feel it is time to take first small steps in that direction. [[User:Fordprefect|Fordprefect]] ([[User talk:Fordprefect|talk]]) 13:48, 20 August 2020 (UTC)<br />
<br />
== Future of Python packaging in Arch Linux? ==<br />
<br />
Since PEP 517 and PEP 518 are slowly gaining traction and setuptools wants to deprecate and remove {{ic|setup.py install}} the current guidelines will need to be updated. Right now there are multiple workarounds including {{pkg|python-dephell}}. Is there already a plan to migrate to a standards based build process how does it look like? As far as I know both a package builder and a package installer are needed for this if Arch wants to avoid pip. [https://github.com/pypa/build pypa/build] and [https://github.com/pradyunsg/installer pradyunsg/installer] appear to be packages for this task. FFY00 contributes to both these packages and maintains lots of Arch Python packages, so I assume they are interested in using them here? --[[User:Pyfisch|Pyfisch]] ([[User talk:Pyfisch|talk]]) 21:06, 24 February 2021 (UTC)<br />
<br />
:There's already packages in community that use Poetry. [https://github.com/archlinux/svntogit-community/commit/052b80214776d2c69bd2deb4e013af3634a62a32 python-rich 10.0.1-1]<br />
:[[User:Grawlinson|Grawlinson]] ([[User talk:Grawlinson|talk]]) 00:22, 1 April 2021 (UTC)<br />
<br />
:: Someone added `python-build` instructions to the wiki but I'm interested in us actually discussing the needed changes in an official capacity before randomly adding them to the wiki.<br />
:: [[User:Foxboron|Foxboron]] ([[User talk:Foxboron|talk]]) 12:02, 13 April 2021 (UTC)<br />
<br />
::: That was me, sorry. The current guidelines simply don't work for pep517 packages that install scripts. After spending hours trying to get this to work for my PKGBUILDS, I assumed these would be useful right now for this particular niche. So while perhaps a bit rude (sorry..), it wasn't exactly random.[[User:Rmsc|Rmsc]] ([[User talk:Rmsc|talk]]) 12:37, 13 April 2021 (UTC)<br />
<br />
:::: Yes, calling it "random" wasn't nice :) Sorry. It was more a reference to adding it without any discussion then the change itself. I have asked FFY00 if we should draft something or wait. Hopefully something is going to crop up the next week or something.<br />
:::: [[User:Foxboron|Foxboron]] ([[User talk:Foxboron|talk]]) 12:56, 13 April 2021 (UTC)<br />
<br />
::::: python-build is mature, the usage of pip is the issue here, as it's not very nice. I really don't like dephell, as IMO it is essentially a hack and can fail in obscure ways, but other people think it is fine. I would mention the two approaches, python-dephell and python-build/python-pip, for now. Once we have a proper standalone wheel installer that can replace pip, I will submit a RFC proposing to change all packages to python-build/python-installer. Btw, there are some issues with the change. --skip-dependencies does not prevent pip from being used, --no-isolation does that, --skip-dependencies will simply skip the check that looks if the dependencies are met, I don't think it should be used here. We should also be building a wheel, to install with pip, not a sdist. The correct command would be `python -m build --wheel --no-isolation` or `python -m build -wn`. [[User:FFY00|FFY00]] ([[User talk:FFY00|talk]]) 13:17, 13 April 2021 (UTC)<br />
<br />
:::::: No problem, my bad :) I've tested the proposed fixes (no --skip-dependencies and --wheel) and it works even better (pip would always build a wheel no matter what). I also dislike having to use ''pip install'', and would rather replace it with a stand-alone installer. If you feel it's appropriate as a temporary thing, I can fix and reintroduce the python-build/python-pip changes.<br />
<br />
:::::: In the meantime I was also preparing a few changes to the ''pip'' section. The issue in https://github.com/pypa/pip/issues/2209 is no longer relevant (was closed in 2017), but the pyo and pyc files generated by pip are still broken (they contain references to $pkgdir). There are a few community packages affected by the problem (tensorflow stuff, for instance). I would like to suggest adding ''--no-compile'' to the recommended pip flags, and using 'compileall' instead. If that's ok, I have the change ready to submit.[[User:Rmsc|Rmsc]] ([[User talk:Rmsc|talk]]) 15:50, 13 April 2021 (UTC)<br />
<br />
::::::: pip builds wheels in isolation (isolated environment) by default and IIRC it had some issues building without isolation. I agree that passing --no-compile to pip and running compileall afterwards is a correct solution. [[User:FFY00|FFY00]] ([[User talk:FFY00|talk]]) 17:24, 13 April 2021 (UTC)<br />
<br />
:::::::: As a side note for compileall - since Python 3.9 ([https://bugs.python.org/issue38112 Issue 38112: Compileall improvements - Python tracker]), compileall supports -s and -p for stripping and prepending paths, so that there will not be $pkgdir in pyc files. The overall affect is similar to what -d does, while more intuitive. Here is an example usage:<br />
:::::::: {{bc|python -m compileall -s "$pkgdir" -p / "$pkgdir"/usr/lib}} [[User:Yan12125|Yan12125]] ([[User talk:Yan12125|talk]]) 07:51, 26 November 2021 (UTC)<br />
<br />
: I tried to have a quick summary for possible solutions in the below table. Feel free to update it if some information is incorrect/missing/out-dated. --[[User:Yan12125|Yan12125]] ([[User talk:Yan12125|talk]]) 08:09, 26 November 2021 (UTC)<br />
<br />
:{| class="wikitable"<br />
|+ Python packaging tools targetting PEP 517/PEP 518<br />
! Tools !! Pros !! Cons<br />
|-<br />
| dephell + setuptools || || <ol><li>No longer maintained ([https://github.com/dephell/dephell GitHub project] archived)</li><li>Not actually building packages following PEP 517/PEP 518</li></ol><br />
|-<br />
| pyproject2setuppy + setuptools || <ol><li>Actively maintained</li></ol> || <ol><li>Similar to dephell, not actually building packages following PEP 517/PEP 518</li></ol><br />
|-<br />
| python-build + python-install || <ol><li>python-build is a PyPA project</li><li>python-install is maintained by an Arch TU</li></ol> || <ol><li>Requires further development; no stable release yet</li></ol><br />
|-<br />
| python-build + python-pip || <ol><li>pip is actively maintained and widely used</li></ol> || <ol><li>many dependencies</li><li>Does not support stripping $pkgdir from pycs out of box<br />
|-<br />
| python-build + python-installer || <ol><li>python-installer is maintained by a PyPA member</li></ol> || <ol><li>No CLI yet https://github.com/pradyunsg/installer/pull/66<br />
|}<br />
<br />
::So since {{pkg|python-installer}} now has a CLI, we can use it. I updated the page accordingly, as the last table entry now reads as follows.<br />
::This approach will probably be the future. I think it allows for bootstrapping our whole Python toolchain. – [[User:Flying_sheep|flying sheep]] 15:49, 19 February 2022 (UTC)<br />
:According to the packaging guidelines, invocation of `setup.py` directly is deprecated. [1]<br />
:It suggests just building a wheel using <code>python -m build</code><br />
:From my testing this works fine. Should a distinction between a project with a `pyproject.toml` and `setup.py` even be made?<br />
:[1]: https://packaging.python.org/en/latest/discussions/setup-py-deprecated/#what-commands-should-be-used-instead [[User:Levitating|Levitating]] ([[User talk:Levitating|talk]]) 04:03, 29 January 2024 (UTC)<br />
::{| class="wikitable"<br />
|+ Python packaging tools targetting PEP 517/PEP 518<br />
! Tools !! Pros !! Cons<br />
|-<br />
| {{pkg|python-build}} + {{pkg|python-installer}} || <ol><li>Are PyPA projects</li><li>A lot of design consideration went into both to enable explicitly our use case</li></ol> ||<br />
|}<br />
<br />
:: Rereading [https://peps.python.org/pep-0517/ PEP517], explicit invocation of {{ic|setup.py}} is unnecessary and deprecated -- it explicitly states: "If the pyproject.toml file is absent, or the build-backend key is missing, the source tree is not using this specification, and tools should revert to the legacy behaviour of running setup.py (either directly, or by implicitly invoking the setuptools.build_meta:__legacy__ backend)."<br />
:: In other words, it should be safe to recommend using {{pkg|python-build}} and {{pkg|python-installer}} everywhere, with the possible caveat that we should recommend falling back to looking in {{ic|setup.py}} for dependencies if {{ic|pyproject.toml}} doesn't exist.<br />
:: Indeed, checking eg with {{aur|papis-git}}, despite the project not having been rewritten for PEP517, a PEP517-style build works fine for it.<br />
:: [[User:Gesh|Gesh]] ([[User talk:Gesh|talk]]) 10:51, 18 February 2024 (UTC)<br />
<br />
== Pytest downloads dependencies if unmet ==<br />
<br />
I'm currently looking at [https://bugs.archlinux.org/task/69967 a bug] in python-keyring caused by the Arch packaging shipping a) without specifying a required dependency and b) without the required version of the dependency being in the Arch repos yet. And yet, python-keyring has a check() function and the tests pass. The reason for this is that pytest actually downloads unmet dependencies from PyPI solely for the purposes of running the tests. This kind of defeats some of the purpose of the check() function, as this ought to be an error. I propose changing the recommended 'setup.py pytest' line to:<br />
<br />
python setup.py pytest --allow-hosts ','<br />
<br />
Which blocks it from downloading anything, turning unmet dependencies into errors. There are probably similar changes than can be made to other test runners. [[User:Chrisjbillington|Chrisjbillington]] ([[User talk:Chrisjbillington|talk]]) 03:23, 13 March 2021 (UTC)<br />
<br />
== python3- upstream name ==<br />
<br />
Are there any guidelines for when package upstream has name which begins with python3-?<br />
<br />
Example is this one https://aur.archlinux.org/packages/python3-saml where the upstream repo is also named python3-saml. Should it be python3- or be renamed to python-?<br />
<br />
Cheers.<br />
[[User:Micwoj92|Micwoj92]] ([[User talk:Micwoj92|talk]]) 00:04, 3 April 2021 (UTC)<br />
<br />
:To avoid namespace conflicts, use upstream's name as-is. In that particular example, {{ic|python-python3-saml}} is appropriate.<br />
:[[User:Grawlinson|Grawlinson]] ([[User talk:Grawlinson|talk]]) 19:49, 25 August 2021 (UTC)<br />
<br />
== Thoughts on PEP-610's direct_url.json ==<br />
<br />
[https://www.python.org/dev/peps/pep-0610/ PEP-610] has been supported in {{Pkg|poetry}} for a while now.<br />
<br />
It creates a {{ic|direct_url.json}} file that serves no purpose except to take up space.<br />
<br />
[[User:Grawlinson|Grawlinson]] ([[User talk:Grawlinson|talk]]) 19:43, 25 August 2021 (UTC)<br />
<br />
:That is not true. https://www.python.org/dev/peps/pep-0610/#freezing-an-environment particularly stands out. [[User:FFY00|FFY00]] ([[User talk:FFY00|talk]])</div>Geshhttps://wiki.archlinux.org/index.php?title=Talk:Python_package_guidelines&diff=800544Talk:Python package guidelines2024-02-15T15:06:10Z<p>Gesh: Recommend using PEP517 builds everywhere, as is spec</p>
<hr />
<div>There is going to be an official policy drafted to deal with .pyc/.pyo files. See: https://wiki.archlinux.org/index.php/User:Allan/Python_Packaging_Policy<br />
<br />
== tests directory ==<br />
<br />
The article states that one shouldn't install a "tests" directory. My package however, after running through setup.py, contains such a directory. What is the recommended way to deal with this? Can this directory be deleted? Couldn't find a clue in other Python packages I've looked at, so can someone maybe point me in the right direction?<br />
<br />
: You should probably delete it from "${pkgdir}". I don't know of any reason to have such a directory, unless it contains unittests for the module. Which probably means upstream should be advised to fix their setup.py because there is no reason to run unittests on an installed module, and the module itself certainly shouldn't rely on methods hidden in the unittests...<br />
<br />
: I don't actually know of any misbehaving modules to point to which violate that rule though.<br />
: [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 18:52, 19 December 2016 (UTC)<br />
<br />
:: To the best of my knowledge, the recommendation is designed to prevent namespace conflicts. If I install your package and execute {{ic|python -c 'import tests'}}, and your code is imported, that's bad; If I install your package and execute {{ic|python -c 'from your_package import tests'}}, and your code is imported, that's fine. Getting this right is a little tricky. For an example of Python code that sidesteps these issues, see [https://github.com/PulpQE/pulp-smash/ this package]. The top-level "tests" directory is not — as of [https://github.com/PulpQE/pulp-smash/pull/458 this PR] — installed by setup.py, and therefore produces no namespace conflicts. The "pulp_smash/tests" directory is installed by setup.py and available as "pulp_smash.tests", and therefore produces no namespace conflicts. [[User:Ichimonji10|Ichimonji10]] ([[User talk:Ichimonji10|talk]]) 21:56, 19 December 2016 (UTC)<br />
<br />
:: I'm experiencing these issues with [https://aur.archlinux.org/packages/python-pendulum/ python-pendulum] and [https://aur.archlinux.org/packages/python-pytzdata/ python-pytzdata], both of which seem to install a global tests directory. Not too familiar with Python packaging, so I'm not sure if it is ok to simply delete those directories? --[[User:Johnpatcher|Johnpatcher]] ([[User talk:Johnpatcher|talk]]) 06:54, 20 December 2016 (UTC)<br />
<br />
: ''The article states that one shouldn't install a "tests" directory.'' - unfortunately, this is no longer the case. I think this statement must be added to the article, or at least a discussion on that. I thought for a while about that, and I am really sure that users don't need program tests: they should be done only by developers. -- [[User:Ynikitenko|Ynikitenko]] ([[User talk:Ynikitenko|talk]]) 14:27, 23 June 2022 (UTC)<br />
<br />
:: It is stated in [[Python package guidelines#Test directory in site-package]] and the wording did not change substantially since 2016. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:59, 23 June 2022 (UTC)<br />
<br />
::: No, in that section it is stated: ''not install a directory named just tests into site-packages''. I understand this phrase as "you can install tests into ''site-packages/mypackage-tests''". I think there should be a phrase about any tests (that they need to be installed in very rare cases). -- [[User:Ynikitenko|Ynikitenko]] ([[User talk:Ynikitenko|talk]]) 16:12, 23 June 2022 (UTC)<br />
<br />
:::: The wording is basically the same since at least [https://wiki.archlinux.org/index.php?title=Python_package_guidelines&oldid=459611#Notes December 2016] which is when this discussion started. As for your wording: there can't be such rule because many official packages would violate it, look at e.g. {{pkg|python-pandas}} or {{pkg|python-sympy}}. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:00, 23 June 2022 (UTC)<br />
<br />
::::: Well, I didn't see that revision (I quoted only this talk here). Thanks for the links! I think, since this is an educational article for package creators, it would be an improvement if we could formulate in what cases tests should be present, and it what they should not? For example, as a hypothetical user of ''python-sympy'' I could wonder: do I need to have its tests installed? Why is the repository 10Mb large? (is it because of tests or not...) -- [[User:Ynikitenko|Ynikitenko]] ([[User talk:Ynikitenko|talk]]) 17:09, 23 June 2022 (UTC)<br />
<br />
:::::: The phrase is supposed to be about buggy packages which misconfigure setuptools. Because setuptools configuration is ancient and basically a cargo cult, people copy configurations that result in not only the intended {{ic|<repository>/<package-name>/}} being packaged, but also {{ic|<repository>/tests/}}. Many packages have this problem, see e.g. [https://github.com/Lightning-AI/lightning/issues/10335 here]. I added some clarifying text in [https://wiki.archlinux.org/index.php?title=Python_package_guidelines&oldid=736240 revision 736240] – [[User:Flying_sheep|flying sheep]] 15:33, 3 July 2022 (UTC)<br />
<br />
== Python version directories ==<br />
For example debian packaging guidelines dictate that python files go into /usr/lib/pythonX/ and OpenSUSE wants files to go into /usr/lib/pythonX.Y/.<br />
<br />
Arch should have a clear guideline where packaged files go into. Most packages have their python files in /usr/lib/pythonX.Y/ but the package openimageio has python files in /usr/lib/python3/.<br />
<br />
[[User:Z3ntu|Z3ntu]] ([[User talk:Z3ntu|talk]]) 12:35, 24 January 2017 (UTC)<br />
<br />
:The {{ic|/usr/lib/python3/}} path does not work: {{bc|<nowiki><br />
>>> import sys<br />
>>> sys.path<br />
['', '/usr/lib/python36.zip', '/usr/lib/python3.6', '/usr/lib/python3.6/lib-dynload', '/home/lahwaacz/.local/lib/python3.6/site-packages', '/usr/lib/python3.6/site-packages']<br />
</nowiki>}} Hence it is a bug and should be reported on the bug tracker. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:46, 24 January 2017 (UTC)<br />
<br />
== Remove pip section in favor of wheels section? ==<br />
<br />
I can’t come up with any reason to use pip other than installing wheels, and wheels are just as easily installed by<br />
<br />
# Unzipping them into the {{ic|$pkgdir}}<br />
# Creating a little wrapper scripts for all console_scripts it provides (Which can be done manually or using {{AUR|install-wheel-scripts}})<br />
<br />
Do you agree? – [[User:Flying_sheep|flying sheep]] 18:08, 12 March 2019 (UTC)<br />
:The relevant specification for installing wheels is [https://www.python.org/dev/peps/pep-0427/ PEP 427] which includes a [https://www.python.org/dev/peps/pep-0427/#installing-a-wheel-distribution-1-0-py32-none-any-whl helpful example] on how to extract a wheel. There are a few steps missing in {{AUR|install-wheel-scripts}}. [[User:Pyfisch|Pyfisch]] ([[User talk:Pyfisch|talk]]) 20:30, 24 February 2021 (UTC)<br />
<br />
::As far as I can tell, I need pip for installing sdists (in my case built for pep517 packages using {{pkg|python-build}}). That said, pip definitely has its quirks, and a simpler solution would definitely be appreciated.[[User:Rmsc|Rmsc]] ([[User talk:Rmsc|talk]]) 12:49, 13 April 2021 (UTC)<br />
<br />
:::{{pkg|python-installer}} now supports our use case with its new CLI, and takes care of more parts than the scripts (e.g. data) – [[User:Flying_sheep|flying sheep]] 15:52, 19 February 2022 (UTC)<br />
<br />
== pyproject2setuppy as dephell alternative for flit/poetry ==<br />
<br />
When packaging first flit/poetry packages for Gentoo, I've written [https://github.com/mgorny/pyproject2setuppy pyproject2setuppy] to avoid the dependency hell involved in other existing solutions (read: I really didn't want to have to package dephell). Perhaps you'd be interested in using it in place of dephell. It's ~200 lines of Python with the only dependency being toml, so it's much lighter on the packager. When the new build systems become more popular, it may also help you avoid circular dependencies. [[User:MGorny|MGorny]] ([[User talk:MGorny|talk]]) 05:41, 4 May 2020 (UTC)<br />
<br />
== Is it time to deprecate Python2? ==<br />
<br />
Python2 is now officially not supported by upstream anymore, and Arch will move on as well. I suggest we make clear in this document, that uploading Python2-modules just for the sake of having them is not ok anymore. Necessary dependencies of un-migrated programs should stay around for the time being. But we have moved on with 32bit, and will do so with Python2 at some point as well. I feel it is time to take first small steps in that direction. [[User:Fordprefect|Fordprefect]] ([[User talk:Fordprefect|talk]]) 13:48, 20 August 2020 (UTC)<br />
<br />
== Future of Python packaging in Arch Linux? ==<br />
<br />
Since PEP 517 and PEP 518 are slowly gaining traction and setuptools wants to deprecate and remove {{ic|setup.py install}} the current guidelines will need to be updated. Right now there are multiple workarounds including {{pkg|python-dephell}}. Is there already a plan to migrate to a standards based build process how does it look like? As far as I know both a package builder and a package installer are needed for this if Arch wants to avoid pip. [https://github.com/pypa/build pypa/build] and [https://github.com/pradyunsg/installer pradyunsg/installer] appear to be packages for this task. FFY00 contributes to both these packages and maintains lots of Arch Python packages, so I assume they are interested in using them here? --[[User:Pyfisch|Pyfisch]] ([[User talk:Pyfisch|talk]]) 21:06, 24 February 2021 (UTC)<br />
<br />
:There's already packages in community that use Poetry. [https://github.com/archlinux/svntogit-community/commit/052b80214776d2c69bd2deb4e013af3634a62a32 python-rich 10.0.1-1]<br />
:[[User:Grawlinson|Grawlinson]] ([[User talk:Grawlinson|talk]]) 00:22, 1 April 2021 (UTC)<br />
<br />
:: Someone added `python-build` instructions to the wiki but I'm interested in us actually discussing the needed changes in an official capacity before randomly adding them to the wiki.<br />
:: [[User:Foxboron|Foxboron]] ([[User talk:Foxboron|talk]]) 12:02, 13 April 2021 (UTC)<br />
<br />
::: That was me, sorry. The current guidelines simply don't work for pep517 packages that install scripts. After spending hours trying to get this to work for my PKGBUILDS, I assumed these would be useful right now for this particular niche. So while perhaps a bit rude (sorry..), it wasn't exactly random.[[User:Rmsc|Rmsc]] ([[User talk:Rmsc|talk]]) 12:37, 13 April 2021 (UTC)<br />
<br />
:::: Yes, calling it "random" wasn't nice :) Sorry. It was more a reference to adding it without any discussion then the change itself. I have asked FFY00 if we should draft something or wait. Hopefully something is going to crop up the next week or something.<br />
:::: [[User:Foxboron|Foxboron]] ([[User talk:Foxboron|talk]]) 12:56, 13 April 2021 (UTC)<br />
<br />
::::: python-build is mature, the usage of pip is the issue here, as it's not very nice. I really don't like dephell, as IMO it is essentially a hack and can fail in obscure ways, but other people think it is fine. I would mention the two approaches, python-dephell and python-build/python-pip, for now. Once we have a proper standalone wheel installer that can replace pip, I will submit a RFC proposing to change all packages to python-build/python-installer. Btw, there are some issues with the change. --skip-dependencies does not prevent pip from being used, --no-isolation does that, --skip-dependencies will simply skip the check that looks if the dependencies are met, I don't think it should be used here. We should also be building a wheel, to install with pip, not a sdist. The correct command would be `python -m build --wheel --no-isolation` or `python -m build -wn`. [[User:FFY00|FFY00]] ([[User talk:FFY00|talk]]) 13:17, 13 April 2021 (UTC)<br />
<br />
:::::: No problem, my bad :) I've tested the proposed fixes (no --skip-dependencies and --wheel) and it works even better (pip would always build a wheel no matter what). I also dislike having to use ''pip install'', and would rather replace it with a stand-alone installer. If you feel it's appropriate as a temporary thing, I can fix and reintroduce the python-build/python-pip changes.<br />
<br />
:::::: In the meantime I was also preparing a few changes to the ''pip'' section. The issue in https://github.com/pypa/pip/issues/2209 is no longer relevant (was closed in 2017), but the pyo and pyc files generated by pip are still broken (they contain references to $pkgdir). There are a few community packages affected by the problem (tensorflow stuff, for instance). I would like to suggest adding ''--no-compile'' to the recommended pip flags, and using 'compileall' instead. If that's ok, I have the change ready to submit.[[User:Rmsc|Rmsc]] ([[User talk:Rmsc|talk]]) 15:50, 13 April 2021 (UTC)<br />
<br />
::::::: pip builds wheels in isolation (isolated environment) by default and IIRC it had some issues building without isolation. I agree that passing --no-compile to pip and running compileall afterwards is a correct solution. [[User:FFY00|FFY00]] ([[User talk:FFY00|talk]]) 17:24, 13 April 2021 (UTC)<br />
<br />
:::::::: As a side note for compileall - since Python 3.9 ([https://bugs.python.org/issue38112 Issue 38112: Compileall improvements - Python tracker]), compileall supports -s and -p for stripping and prepending paths, so that there will not be $pkgdir in pyc files. The overall affect is similar to what -d does, while more intuitive. Here is an example usage:<br />
:::::::: {{bc|python -m compileall -s "$pkgdir" -p / "$pkgdir"/usr/lib}} [[User:Yan12125|Yan12125]] ([[User talk:Yan12125|talk]]) 07:51, 26 November 2021 (UTC)<br />
<br />
: I tried to have a quick summary for possible solutions in the below table. Feel free to update it if some information is incorrect/missing/out-dated. --[[User:Yan12125|Yan12125]] ([[User talk:Yan12125|talk]]) 08:09, 26 November 2021 (UTC)<br />
<br />
:{| class="wikitable"<br />
|+ Python packaging tools targetting PEP 517/PEP 518<br />
! Tools !! Pros !! Cons<br />
|-<br />
| dephell + setuptools || || <ol><li>No longer maintained ([https://github.com/dephell/dephell GitHub project] archived)</li><li>Not actually building packages following PEP 517/PEP 518</li></ol><br />
|-<br />
| pyproject2setuppy + setuptools || <ol><li>Actively maintained</li></ol> || <ol><li>Similar to dephell, not actually building packages following PEP 517/PEP 518</li></ol><br />
|-<br />
| python-build + python-install || <ol><li>python-build is a PyPA project</li><li>python-install is maintained by an Arch TU</li></ol> || <ol><li>Requires further development; no stable release yet</li></ol><br />
|-<br />
| python-build + python-pip || <ol><li>pip is actively maintained and widely used</li></ol> || <ol><li>many dependencies</li><li>Does not support stripping $pkgdir from pycs out of box<br />
|-<br />
| python-build + python-installer || <ol><li>python-installer is maintained by a PyPA member</li></ol> || <ol><li>No CLI yet https://github.com/pradyunsg/installer/pull/66<br />
|}<br />
<br />
::So since {{pkg|python-installer}} now has a CLI, we can use it. I updated the page accordingly, as the last table entry now reads as follows.<br />
::This approach will probably be the future. I think it allows for bootstrapping our whole Python toolchain. – [[User:Flying_sheep|flying sheep]] 15:49, 19 February 2022 (UTC)<br />
:According to the packaging guidelines, invocation of `setup.py` directly is deprecated. [1]<br />
:It suggests just building a wheel using <code>python -m build</code><br />
:From my testing this works fine. Should a distinction between a project with a `pyproject.toml` and `setup.py` even be made?<br />
:[1]: https://packaging.python.org/en/latest/discussions/setup-py-deprecated/#what-commands-should-be-used-instead [[User:Levitating|Levitating]] ([[User talk:Levitating|talk]]) 04:03, 29 January 2024 (UTC)<br />
::{| class="wikitable"<br />
|+ Python packaging tools targetting PEP 517/PEP 518<br />
! Tools !! Pros !! Cons<br />
|-<br />
| {{pkg|python-build}} + {{pkg|python-installer}} || <ol><li>Are PyPA projects</li><li>A lot of design consideration went into both to enable explicitly our use case</li></ol> ||<br />
|}<br />
<br />
:: Rereading [https://peps.python.org/pep-0517/ PEP517], explicit invocation of {{ic|setup.py}} is unnecessary and deprecated -- it explicitly states: "If the pyproject.toml file is absent, or the build-backend key is missing, the source tree is not using this specification, and tools should revert to the legacy behaviour of running setup.py (either directly, or by implicitly invoking the setuptools.build_meta:__legacy__ backend)."<br />
:: In other words, it should be safe to recommend using {{pkg|python-build}} and {{pkg|python-installer}} everywhere, with the possible caveat that we should recommend falling back to looking in {{ic|setup.py}} for dependencies if {{ic|pyproject.toml}} doesn't exist.<br />
:: Indeed, checking eg with {{aur|papis-git}}, despite the project not having been rewritten for PEP517, a PEP517-style build works fine for it.<br />
<br />
== Pytest downloads dependencies if unmet ==<br />
<br />
I'm currently looking at [https://bugs.archlinux.org/task/69967 a bug] in python-keyring caused by the Arch packaging shipping a) without specifying a required dependency and b) without the required version of the dependency being in the Arch repos yet. And yet, python-keyring has a check() function and the tests pass. The reason for this is that pytest actually downloads unmet dependencies from PyPI solely for the purposes of running the tests. This kind of defeats some of the purpose of the check() function, as this ought to be an error. I propose changing the recommended 'setup.py pytest' line to:<br />
<br />
python setup.py pytest --allow-hosts ','<br />
<br />
Which blocks it from downloading anything, turning unmet dependencies into errors. There are probably similar changes than can be made to other test runners. [[User:Chrisjbillington|Chrisjbillington]] ([[User talk:Chrisjbillington|talk]]) 03:23, 13 March 2021 (UTC)<br />
<br />
== python3- upstream name ==<br />
<br />
Are there any guidelines for when package upstream has name which begins with python3-?<br />
<br />
Example is this one https://aur.archlinux.org/packages/python3-saml where the upstream repo is also named python3-saml. Should it be python3- or be renamed to python-?<br />
<br />
Cheers.<br />
[[User:Micwoj92|Micwoj92]] ([[User talk:Micwoj92|talk]]) 00:04, 3 April 2021 (UTC)<br />
<br />
:To avoid namespace conflicts, use upstream's name as-is. In that particular example, {{ic|python-python3-saml}} is appropriate.<br />
:[[User:Grawlinson|Grawlinson]] ([[User talk:Grawlinson|talk]]) 19:49, 25 August 2021 (UTC)<br />
<br />
== Thoughts on PEP-610's direct_url.json ==<br />
<br />
[https://www.python.org/dev/peps/pep-0610/ PEP-610] has been supported in {{Pkg|poetry}} for a while now.<br />
<br />
It creates a {{ic|direct_url.json}} file that serves no purpose except to take up space.<br />
<br />
[[User:Grawlinson|Grawlinson]] ([[User talk:Grawlinson|talk]]) 19:43, 25 August 2021 (UTC)<br />
<br />
:That is not true. https://www.python.org/dev/peps/pep-0610/#freezing-an-environment particularly stands out. [[User:FFY00|FFY00]] ([[User talk:FFY00|talk]])</div>Geshhttps://wiki.archlinux.org/index.php?title=XDG_Base_Directory&diff=794928XDG Base Directory2023-12-22T00:08:08Z<p>Gesh: Add spotdl</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 {{man|8|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|act}}<br />
| {{ic|~/.actrc}}<br />
| [https://github.com/nektos/act/pull/1656 1656]<br />
| [https://github.com/nektos/act/issues/1678]<br />
| {{ic|XDG_CONFIG_HOME/act/actrc}}<br />
If the legacy path {{ic|~/.actr}} is present, it will take precedence. <br />
|-<br />
| [[aerc]]<br />
| <br />
| [https://git.sr.ht/~rjarry/aerc/commit/fff1664 fff1664]<br />
|<br />
| {{ic|XDG_CONFIG_HOME/aerc/aerc.conf}}<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 />
|<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|atuin}}<br />
| {{ic|~/.config/atuin}} {{ic|~/.local/share/atuin}}<br />
| [https://github.com/ellie/atuin/commit/156893d774b4da5b541fdbb08428f9ec392949a0 156893d]<br />
|<br />
|<br />
XDG_CONFIG_HOME/atuin/config.toml<br />
XDG_DATA_HOME/atuin/history.db<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 />
| Uses new locations if legacy do not exist:<br />
XDG_CONFIG_HOME/audacity<br />
XDG_DATA_HOME/audacity<br />
|-<br />
| {{Pkg|btop}}<br />
| <br />
| [https://github.com/aristocratos/btop/commit/b5e709d b5e709d]<br />
| <br />
| {{ic|XDG_CONFIG_HOME/btop}}<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 />
| [[CUPS]]<br />
| {{ic|~/.cups/}}<br />
| [https://github.com/OpenPrinting/libcups/pull/45/commits/23b1be68803128ed701d374981c4583bcf9e7bf6 23b1be6]<br />
| [https://github.com/OpenPrinting/cups/issues/10]<br />
| <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}}{{Broken package link|package not found}}<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 has not 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 />
| {{Pkg|hunspell}}<br />
| {{ic|~/.hunspell_default.}}<br />
| <br />
| [https://github.com/hunspell/hunspell/pull/637]<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 />
| {{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 />
| Checks if {{ic|$XDG_CONFIG_HOME/ipython}} (or {{ic|~/.config/ipython}} if {{ic|XDG_CONFIG_HOME}} is unset) exists, otherwise it uses {{ic|~/.ipython}}.<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-binextra}})<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://hg.mozilla.org/projects/nss/rev/da45424cb9a0b4d8e45e5040e2e3b574d994e254 3.42 (da45424)]<br />
| [https://bugzilla.mozilla.org/show_bug.cgi?id=818686]<br />
|<br />
|-<br />
| [[Haskell#Stack]]<br />
| {{ic|~/.stack}}<br />
| [https://github.com/commercialhaskell/stack/releases/tag/v2.9.3 2.9.3]<br />
| [https://github.com/commercialhaskell/stack/issues/4243]<br />
| Defaults to legacy. Use {{ic|1=export STACK_XDG=1}} to make it compliant with the spec.<br />
The old method of {{ic|1=export STACK_ROOT="$XDG_DATA_HOME"/stack}} still works and takes priority [https://docs.haskellstack.org/en/stable/environment_variables/#stack_xdg].<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 />
| {{Pkg|mangohud}}<br />
|<br />
| [https://github.com/flightlessmango/MangoHud/commit/65b90fc 65b90fc]<br />
| [https://github.com/flightlessmango/MangoHud/issues/37]<br />
| {{ic|XDG_CONFIG_HOME/MangoHud}}<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 />
| {{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-pipx}}<br />
| {{ic|~/.local/pipx}}<br />
| [https://github.com/pypa/pipx/pull/1001 c3d8de9]<br />
| [https://github.com/pypa/pipx/issues/722]<br />
| For compatibility, pipx will revert to {{ic|~/.local/pipx}} if it exists. Implemented using {{Pkg|python-platformdirs}}<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 />
| [[Steam]] might still create {{ic|~/.pulse-cookie}}. Add {{ic|1=cookie-file = ~/.config/pulse/cookie}} to {{ic|/etc/pulse/client.conf}} to get rid of it.<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 />
| [[SQLite]]<br />
| {{ic|~/.sqliterc}}, {{ic|~/.sqlite_history}}<br />
| [https://github.com/sqlite/sqlite/commit/6e8a33 3.44.0]<br />
| <br />
| {{ic|XDG_CONFIG_HOME/sqlite3/sqliterc}}, {{ic|1=export SQLITE_HISTORY=$XDG_DATA_HOME/sqlite_history}}<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://code.videolan.org/videolan/vlc/-/commit/16f32e1500887c0dcd33cb06ad71759a81a52878 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]{{Dead link|2023|05|06|status=404}}<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 />
$XDG_CONFIG_HOME/zim/preferences.conf<br />
$XDG_CONFIG_HOME/zim/notebooks.list<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 />
The remote's {{ic|~/.ansible/tmp}} can be moved by setting {{ic|1=remote_tmp = ${XDG_CONFIG_HOME}/ansible/tmp}} in an appropriate {{ic|ansible.cfg}}. [https://docs.ansible.com/archive/ansible/2.4/intro_configuration.html#remote-tmp] [https://github.com/ayekat/localdir/issues/7#issuecomment-998286490]<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 />
| {{Aur|bun}}<br />
| {{ic|~/.bun/}}<br />
|<br />
| [https://github.com/oven-sh/bun/issues/1678]<br />
| Bun will prioritize using {{ic|$XDG_CONFIG_HOME}}, {{ic|$XDG_CACHE_HOME}}, and/or {{ic|$XDG_DATA_HOME}} when these have explicitly been set. As an alternative, {{ic|1=export BUN_INSTALL="$XDG_DATA_HOME"/bun}} can be used to set {{ic|bun}}'s main location for its directories.<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://gitlab.archlinux.org/archlinux/packaging/packages/cataclysm-dda/-/commit/0947de440817c9c418cac615275edbf1cc0abdbb 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 />
| chktex in {{pkg|texlive-binextra}}<br />
| {{ic|~/.chktexrc}}<br />
|<br />
|<br />
| Move the config file to {{ic|$XDG_CONFIG_HOME/chktex/.chktexrc}} (mind the leading dot) and {{ic|1=export CHKTEXRC=$XDG_CONFIG_HOME/chktex}}<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 />
| Deliberatly (according to these sources) clobbers {{ic|~/.config}} by writing hundreds of megabytes of '''cache''' data into it. Quite unsupported.<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 />
| [[discord]]<br />
| {{ic|1=${XDG_CONFIG_HOME}/discord}}<br />
|<br />
| <br />
| As of version 0.0.27:<br />
Undocumented, though actively used:<br />
{{ic|1=export DISCORD_USER_DATA_DIR="${XDG_DATA_HOME}"}}<br />
<br />
Source: {{ic|1=<discord_system_package_root>/resources/app.asar}}.<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}}, {{ic|~/.hex}}<br />
| [https://github.com/elixir-lang/elixir/commit/afaf889 afaf889]<br />
| [https://github.com/elixir-lang/elixir/pull/10028] [https://github.com/hexpm/hex/pull/841]<br />
| Elixir does not fully conform to XDG specs, it will use XDG only if the {{ic|1=MIX_XDG}} variable is set to a special value, otherwise it will by default use legacy path.<br />
{{ic|1=export MIX_XDG="true"}}<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 />
| GNU Radio:<br />
{{ic|1=export GR_PREFS_PATH="$XDG_CONFIG_HOME"/gnuradio}}<br />
<br />
GNU Radio Companion:<br />
{{ic|1=export GRC_PREFS_PATH="$XDG_CONFIG_HOME"/gnuradio/grc.conf}}<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 --list-dirs socketdir}} and have to modify the systemd user units to listen on the correct sockets accordingly. You also have to use the following {{ic|gpg-agent.service}} drop-in file (or otherwise pass the GNUPGHOME env var to the agent running in systemd), or you might experience issues with "missing" private keys:<br />
<br />
[Service]<br />
Environment="GNUPGHOME=%h/.local/share/gnupg"<br />
<br />
If you [[GnuPG#SSH agent|use GPG as your SSH agent]], set {{ic|SSH_AUTH_SOCK}} to the output of {{ic|gpgconf --list-dirs agent-ssh-socket}} instead of some hardcoded value. <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 />
[https://github.com/gradle/gradle/issues/8262]<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/3.2.2/stdlibs/irb/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|mtpaint}}<br />
| {{ic|~/.mtpaint}}<br />
|<br />
| [https://github.com/wjaguar/mtPaint/issues/22]<br />
| {{hc|1=/etc/mtpaint/mtpaintrc|2=userINI = ~/.config/mtpaint}}<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 />
logs-dir=${XDG_STATE_HOME}/npm/logs<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 />
| {{Pkg|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 />
| {{AUR|python-easyocr}}<br />
| {{ic|~/.EasyOCR}}<br />
| <br />
|<br />
| {{ic|1=export EASYOCR_MODULE_PATH="$XDG_CONFIG_HOME/EasyOCR"}}<br />
|-<br />
| {{AUR|python-spotdl}}<br />
| {{ic|~/.spotdl}}<br />
| [https://github.com/spotDL/spotify-downloader/releases/tag/v4.0.6 v4.0.6] ([https://github.com/spotDL/spotify-downloader/commit/3929caed5a2e8c2858a1dc3898ad75be263fdb96 3929cae])<br />
| [https://github.com/spotDL/spotify-downloader/issues/1651]<br />
| {{ic|1=mkdir "$XDG_DATA_HOME"/spotdl}}<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 />
| {{AUR|omnisharp-roslyn-bin}}<br />
| {{ic|~/.omnisharp/}}<br />
| [https://github.com/OmniSharp/omnisharp-roslyn/commit/e1353fb8ded7070d6e126b0b6030dac5d3d707ea]<br />
| [https://github.com/OmniSharp/omnisharp-roslyn/issues/953]<br />
| {{ic|1=export OMNISHARPHOME="$XDG_CONFIG_HOME/omnisharp"}}<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/platform/PlatformUtils-posix.cc#L105 hard-codes] {{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 />
| {{Pkg|platformio-core}}<br />
| {{ic|~/.platformio}}<br />
|<br />
| [https://github.com/platformio/platformio-core/issues/2872]<br />
| {{ic|1=export PLATFORMIO_CORE_DIR="$XDG_DATA_HOME"/platformio}}<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}}{{Broken package link|package not found}}<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 />
| {{Pkg|ruff}}<br />
| {{ic|.ruff_cache}}<br />
|<br />
| [https://github.com/charliermarsh/ruff/issues/1292]<br />
| {{ic|1=export RUFF_CACHE_DIR=$XDG_CACHE_HOME/ruff}}<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 />
| {{AUR|singularity-ce}}<br />
| {{ic|~/.singularity}}<br />
| [https://github.com/sylabs/singularity/releases/tag/v3.11.4 3.11.4]<br />
| <br />
| {{ic|1=export SINGULARITY_CONFIGDIR="$XDG_CONFIG_HOME/singularity"}}, {{ic|1=export SINGULARITY_CACHEDIR="$XDG_CACHE_HOME/singularity"}}<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 />
| {{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 />
| {{AUR|x3270}}<br />
| {{ic|~/.x3270pro}}, {{ic|~/.c3270pro}}<br />
|<br />
|<br />
| {{ic|1=export X3270PRO="$XDG_CONFIG_HOME"/x3270/config}}, {{ic|1=export C3270PRO="$XDG_CONFIG_HOME"/c3270/config}}<br />
<br />
App also creates {{ic|~/.x3270connect}} but this is currently unsupported.<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 />
| [https://dotnet.microsoft.com/en-us/apps/aspnet ASP.NET Core]<br />
| {{ic|~/.aspnet}}<br />
| [https://github.com/dotnet/aspnetcore/issues/43278]<br />
|<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 />
| {{Pkg|cmus}}<br />
| {{ic|~/.config/cmus}}<br />
| [https://github.com/cmus/cmus/pull/69]<br />
| [https://github.com/cmus/cmus/issues/1283]<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}} (universal-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|~/.dart-tool}}, {{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 />
| [https://man.archlinux.org/man/dig.1 dig]<br />
| {{ic|~/.digrc}}<br />
|<br />
|<br />
|-<br />
| {{Pkg|dotnet-sdk}}<br />
| {{ic|~/.dotnet/}}, {{ic|~/.templateengine}}<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 />
| {{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}} (repo was deleted)<br />
| Added in [https://repo.or.cz/w/llpp.git/commit/3ab86f0 3ab86f0] but subsequently reverted in [https://repo.or.cz/w/llpp.git/commit/e253c9f1 old:e253c9f1]/[https://github.com/criticic/llpp/commit/e253c9f1ca971b4298cfee889820ad60bded54af new:e253c9f1]<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 />
| {{AUR|jitsi-meet}}<br />
| {{ic|~/Downloads}}<br />
| [https://github.com/jitsi/libjitsi/issues/518 libjitsi#518]<br />
| Download dir hardcoded to {{ic|~/Downloads}} rather than {{ic|XDG_DOWNLOAD_DIR}} (from [[XDG user directories]])<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 />
export JULIA_DEPOT_PATH="$XDG_DATA_HOME/julia:$JULIA_DEPOT_PATH"<br />
export JULIAUP_DEPOT_PATH="$XDG_DATA_HOME/julia"<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][https://github.com/kubernetes/kubernetes/issues/115522]<br />
| <br />
export KUBECONFIG="$XDG_CONFIG_HOME/kube" <br />
export KUBECACHEDIR="$XDG_CACHE_HOME/kube"<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 />
| [[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 />
| {{pkg|nim}}<br />
| {{ic|~/.nimble}}<br />
| [https://github.com/nim-lang/nimble/issues/217]<br />
[https://github.com/nim-lang/Nim/issues/11340]<br />
| Nimble will [https://github.com/nim-lang/nimble/#configuration try to load] {{ic|~/.config/nimble/nimble.ini}} at startup, set {{ic|nimbleDir}} there. You will have to change {{ic|nimblepath}} in the Nim compiler [https://nim-lang.org/docs/nimc.html#compiler-usage-configuration-files configuration file] as well.<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-history}} to {{ic|$XDG_CACHE_HOME}} [https://github.com/ocaml-community/utop/pull/362]<br />
|-<br />
| {{Pkg|ollama}}<br />
| {{ic|~/.ollama}}<br />
| [https://github.com/jmorganca/ollama/issues/228]<br />
| Model locations can be set with:<br />
{{ic|1=export OLLAMA_MODELS=$XDG_DATA_HOME/ollama/models}}<br />
<br />
Source: [https://github.com/jmorganca/ollama/pull/897]<br />
|-<br />
| [[OpenSSH]]<br />
| {{ic|~/.ssh}}<br />
| [https://web.archive.org/web/20190925004614/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 />
| Partial workaround: [https://github.com/phoronix-test-suite/phoronix-test-suite/blob/ebcde81fcd5cd63956e5f8db5664262b5fd4ceb9/pts-core/pts-core.php#L123]<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 />
| {{Pkg|pulumi}}<br />
| {{ic|~/.pulumi}}<br />
| [https://github.com/pulumi/pulumi/issues/2534]<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 />
| [[R]]<br />
| {{ic|~/.Rprofile, ~/.Rdata, ~/.Rhistory}}<br />
| <br />
| <br />
R_HOME_USER="$HOME/.config/R"<br />
R_PROFILE_USER="$HOME/.config/R/profile"<br />
R_HISTFILE="$HOME/.config/R/history"<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 />
| {{Pkg|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 />
| [[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 />
| [[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|stremio}}<br />
| {{ic|~/.stremio-server/|}}<br />
| [https://github.com/Stremio/stremio-features/issues/268]<br />
|<br />
|-<br />
| [https://github.com/spring-projects/sts4 sts4]<br />
| {{ic|~/.sts4}}<br />
| [https://github.com/spring-projects/sts4/issues/601]<br />
| Pass JVM arg {{ic|1=-Dlanguageserver.boot.symbolCacheDir=$XDG_CACHE_HOME/sts4/symbolCache}}<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 />
| See [[Vim#Workaround for XDG Base Directory specification]].<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|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 />
: [https://github.com/ActiveState/appdirs appdirs] (abandoned)<br />
: [https://github.com/platformdirs/platformdirs platformdirs]<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 />
== Tips and tricks ==<br />
<br />
=== Hiding unwanted directories ===<br />
<br />
For directories which cannot be relocated, some desktop environments such as [[KDE]] allow you to hide them:<br />
<br />
$ echo ''path'' >> ~/.hidden<br />
<br />
''path'' is the path of the file/directory, relative to the parent directory of {{ic|.hidden}}.<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>Geshhttps://wiki.archlinux.org/index.php?title=XDG_Base_Directory&diff=794926XDG Base Directory2023-12-21T23:55:44Z<p>Gesh: npm: add log directory</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 {{man|8|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|act}}<br />
| {{ic|~/.actrc}}<br />
| [https://github.com/nektos/act/pull/1656 1656]<br />
| [https://github.com/nektos/act/issues/1678]<br />
| {{ic|XDG_CONFIG_HOME/act/actrc}}<br />
If the legacy path {{ic|~/.actr}} is present, it will take precedence. <br />
|-<br />
| [[aerc]]<br />
| <br />
| [https://git.sr.ht/~rjarry/aerc/commit/fff1664 fff1664]<br />
|<br />
| {{ic|XDG_CONFIG_HOME/aerc/aerc.conf}}<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 />
|<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|atuin}}<br />
| {{ic|~/.config/atuin}} {{ic|~/.local/share/atuin}}<br />
| [https://github.com/ellie/atuin/commit/156893d774b4da5b541fdbb08428f9ec392949a0 156893d]<br />
|<br />
|<br />
XDG_CONFIG_HOME/atuin/config.toml<br />
XDG_DATA_HOME/atuin/history.db<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 />
| Uses new locations if legacy do not exist:<br />
XDG_CONFIG_HOME/audacity<br />
XDG_DATA_HOME/audacity<br />
|-<br />
| {{Pkg|btop}}<br />
| <br />
| [https://github.com/aristocratos/btop/commit/b5e709d b5e709d]<br />
| <br />
| {{ic|XDG_CONFIG_HOME/btop}}<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 />
| [[CUPS]]<br />
| {{ic|~/.cups/}}<br />
| [https://github.com/OpenPrinting/libcups/pull/45/commits/23b1be68803128ed701d374981c4583bcf9e7bf6 23b1be6]<br />
| [https://github.com/OpenPrinting/cups/issues/10]<br />
| <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}}{{Broken package link|package not found}}<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 has not 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 />
| {{Pkg|hunspell}}<br />
| {{ic|~/.hunspell_default.}}<br />
| <br />
| [https://github.com/hunspell/hunspell/pull/637]<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 />
| {{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 />
| Checks if {{ic|$XDG_CONFIG_HOME/ipython}} (or {{ic|~/.config/ipython}} if {{ic|XDG_CONFIG_HOME}} is unset) exists, otherwise it uses {{ic|~/.ipython}}.<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-binextra}})<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://hg.mozilla.org/projects/nss/rev/da45424cb9a0b4d8e45e5040e2e3b574d994e254 3.42 (da45424)]<br />
| [https://bugzilla.mozilla.org/show_bug.cgi?id=818686]<br />
|<br />
|-<br />
| [[Haskell#Stack]]<br />
| {{ic|~/.stack}}<br />
| [https://github.com/commercialhaskell/stack/releases/tag/v2.9.3 2.9.3]<br />
| [https://github.com/commercialhaskell/stack/issues/4243]<br />
| Defaults to legacy. Use {{ic|1=export STACK_XDG=1}} to make it compliant with the spec.<br />
The old method of {{ic|1=export STACK_ROOT="$XDG_DATA_HOME"/stack}} still works and takes priority [https://docs.haskellstack.org/en/stable/environment_variables/#stack_xdg].<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 />
| {{Pkg|mangohud}}<br />
|<br />
| [https://github.com/flightlessmango/MangoHud/commit/65b90fc 65b90fc]<br />
| [https://github.com/flightlessmango/MangoHud/issues/37]<br />
| {{ic|XDG_CONFIG_HOME/MangoHud}}<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 />
| {{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-pipx}}<br />
| {{ic|~/.local/pipx}}<br />
| [https://github.com/pypa/pipx/pull/1001 c3d8de9]<br />
| [https://github.com/pypa/pipx/issues/722]<br />
| For compatibility, pipx will revert to {{ic|~/.local/pipx}} if it exists. Implemented using {{Pkg|python-platformdirs}}<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 />
| [[Steam]] might still create {{ic|~/.pulse-cookie}}. Add {{ic|1=cookie-file = ~/.config/pulse/cookie}} to {{ic|/etc/pulse/client.conf}} to get rid of it.<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 />
| [[SQLite]]<br />
| {{ic|~/.sqliterc}}, {{ic|~/.sqlite_history}}<br />
| [https://github.com/sqlite/sqlite/commit/6e8a33 3.44.0]<br />
| <br />
| {{ic|XDG_CONFIG_HOME/sqlite3/sqliterc}}, {{ic|1=export SQLITE_HISTORY=$XDG_DATA_HOME/sqlite_history}}<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://code.videolan.org/videolan/vlc/-/commit/16f32e1500887c0dcd33cb06ad71759a81a52878 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]{{Dead link|2023|05|06|status=404}}<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 />
$XDG_CONFIG_HOME/zim/preferences.conf<br />
$XDG_CONFIG_HOME/zim/notebooks.list<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 />
The remote's {{ic|~/.ansible/tmp}} can be moved by setting {{ic|1=remote_tmp = ${XDG_CONFIG_HOME}/ansible/tmp}} in an appropriate {{ic|ansible.cfg}}. [https://docs.ansible.com/archive/ansible/2.4/intro_configuration.html#remote-tmp] [https://github.com/ayekat/localdir/issues/7#issuecomment-998286490]<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 />
| {{Aur|bun}}<br />
| {{ic|~/.bun/}}<br />
|<br />
| [https://github.com/oven-sh/bun/issues/1678]<br />
| Bun will prioritize using {{ic|$XDG_CONFIG_HOME}}, {{ic|$XDG_CACHE_HOME}}, and/or {{ic|$XDG_DATA_HOME}} when these have explicitly been set. As an alternative, {{ic|1=export BUN_INSTALL="$XDG_DATA_HOME"/bun}} can be used to set {{ic|bun}}'s main location for its directories.<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://gitlab.archlinux.org/archlinux/packaging/packages/cataclysm-dda/-/commit/0947de440817c9c418cac615275edbf1cc0abdbb 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 />
| chktex in {{pkg|texlive-binextra}}<br />
| {{ic|~/.chktexrc}}<br />
|<br />
|<br />
| Move the config file to {{ic|$XDG_CONFIG_HOME/chktex/.chktexrc}} (mind the leading dot) and {{ic|1=export CHKTEXRC=$XDG_CONFIG_HOME/chktex}}<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 />
| Deliberatly (according to these sources) clobbers {{ic|~/.config}} by writing hundreds of megabytes of '''cache''' data into it. Quite unsupported.<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 />
| [[discord]]<br />
| {{ic|1=${XDG_CONFIG_HOME}/discord}}<br />
|<br />
| <br />
| As of version 0.0.27:<br />
Undocumented, though actively used:<br />
{{ic|1=export DISCORD_USER_DATA_DIR="${XDG_DATA_HOME}"}}<br />
<br />
Source: {{ic|1=<discord_system_package_root>/resources/app.asar}}.<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}}, {{ic|~/.hex}}<br />
| [https://github.com/elixir-lang/elixir/commit/afaf889 afaf889]<br />
| [https://github.com/elixir-lang/elixir/pull/10028] [https://github.com/hexpm/hex/pull/841]<br />
| Elixir does not fully conform to XDG specs, it will use XDG only if the {{ic|1=MIX_XDG}} variable is set to a special value, otherwise it will by default use legacy path.<br />
{{ic|1=export MIX_XDG="true"}}<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 />
| GNU Radio:<br />
{{ic|1=export GR_PREFS_PATH="$XDG_CONFIG_HOME"/gnuradio}}<br />
<br />
GNU Radio Companion:<br />
{{ic|1=export GRC_PREFS_PATH="$XDG_CONFIG_HOME"/gnuradio/grc.conf}}<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 --list-dirs socketdir}} and have to modify the systemd user units to listen on the correct sockets accordingly. You also have to use the following {{ic|gpg-agent.service}} drop-in file (or otherwise pass the GNUPGHOME env var to the agent running in systemd), or you might experience issues with "missing" private keys:<br />
<br />
[Service]<br />
Environment="GNUPGHOME=%h/.local/share/gnupg"<br />
<br />
If you [[GnuPG#SSH agent|use GPG as your SSH agent]], set {{ic|SSH_AUTH_SOCK}} to the output of {{ic|gpgconf --list-dirs agent-ssh-socket}} instead of some hardcoded value. <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 />
[https://github.com/gradle/gradle/issues/8262]<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/3.2.2/stdlibs/irb/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|mtpaint}}<br />
| {{ic|~/.mtpaint}}<br />
|<br />
| [https://github.com/wjaguar/mtPaint/issues/22]<br />
| {{hc|1=/etc/mtpaint/mtpaintrc|2=userINI = ~/.config/mtpaint}}<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 />
logs-dir=${XDG_STATE_HOME}/npm/logs<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 />
| {{Pkg|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 />
| {{AUR|python-easyocr}}<br />
| {{ic|~/.EasyOCR}}<br />
| <br />
|<br />
| {{ic|1=export EASYOCR_MODULE_PATH="$XDG_CONFIG_HOME/EasyOCR"}}<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 />
| {{AUR|omnisharp-roslyn-bin}}<br />
| {{ic|~/.omnisharp/}}<br />
| [https://github.com/OmniSharp/omnisharp-roslyn/commit/e1353fb8ded7070d6e126b0b6030dac5d3d707ea]<br />
| [https://github.com/OmniSharp/omnisharp-roslyn/issues/953]<br />
| {{ic|1=export OMNISHARPHOME="$XDG_CONFIG_HOME/omnisharp"}}<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/platform/PlatformUtils-posix.cc#L105 hard-codes] {{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 />
| {{Pkg|platformio-core}}<br />
| {{ic|~/.platformio}}<br />
|<br />
| [https://github.com/platformio/platformio-core/issues/2872]<br />
| {{ic|1=export PLATFORMIO_CORE_DIR="$XDG_DATA_HOME"/platformio}}<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}}{{Broken package link|package not found}}<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 />
| {{Pkg|ruff}}<br />
| {{ic|.ruff_cache}}<br />
|<br />
| [https://github.com/charliermarsh/ruff/issues/1292]<br />
| {{ic|1=export RUFF_CACHE_DIR=$XDG_CACHE_HOME/ruff}}<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 />
| {{AUR|singularity-ce}}<br />
| {{ic|~/.singularity}}<br />
| [https://github.com/sylabs/singularity/releases/tag/v3.11.4 3.11.4]<br />
| <br />
| {{ic|1=export SINGULARITY_CONFIGDIR="$XDG_CONFIG_HOME/singularity"}}, {{ic|1=export SINGULARITY_CACHEDIR="$XDG_CACHE_HOME/singularity"}}<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 />
| {{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 />
| {{AUR|x3270}}<br />
| {{ic|~/.x3270pro}}, {{ic|~/.c3270pro}}<br />
|<br />
|<br />
| {{ic|1=export X3270PRO="$XDG_CONFIG_HOME"/x3270/config}}, {{ic|1=export C3270PRO="$XDG_CONFIG_HOME"/c3270/config}}<br />
<br />
App also creates {{ic|~/.x3270connect}} but this is currently unsupported.<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 />
| [https://dotnet.microsoft.com/en-us/apps/aspnet ASP.NET Core]<br />
| {{ic|~/.aspnet}}<br />
| [https://github.com/dotnet/aspnetcore/issues/43278]<br />
|<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 />
| {{Pkg|cmus}}<br />
| {{ic|~/.config/cmus}}<br />
| [https://github.com/cmus/cmus/pull/69]<br />
| [https://github.com/cmus/cmus/issues/1283]<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}} (universal-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|~/.dart-tool}}, {{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 />
| [https://man.archlinux.org/man/dig.1 dig]<br />
| {{ic|~/.digrc}}<br />
|<br />
|<br />
|-<br />
| {{Pkg|dotnet-sdk}}<br />
| {{ic|~/.dotnet/}}, {{ic|~/.templateengine}}<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 />
| {{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}} (repo was deleted)<br />
| Added in [https://repo.or.cz/w/llpp.git/commit/3ab86f0 3ab86f0] but subsequently reverted in [https://repo.or.cz/w/llpp.git/commit/e253c9f1 old:e253c9f1]/[https://github.com/criticic/llpp/commit/e253c9f1ca971b4298cfee889820ad60bded54af new:e253c9f1]<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 />
| {{AUR|jitsi-meet}}<br />
| {{ic|~/Downloads}}<br />
| [https://github.com/jitsi/libjitsi/issues/518 libjitsi#518]<br />
| Download dir hardcoded to {{ic|~/Downloads}} rather than {{ic|XDG_DOWNLOAD_DIR}} (from [[XDG user directories]])<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 />
export JULIA_DEPOT_PATH="$XDG_DATA_HOME/julia:$JULIA_DEPOT_PATH"<br />
export JULIAUP_DEPOT_PATH="$XDG_DATA_HOME/julia"<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][https://github.com/kubernetes/kubernetes/issues/115522]<br />
| <br />
export KUBECONFIG="$XDG_CONFIG_HOME/kube" <br />
export KUBECACHEDIR="$XDG_CACHE_HOME/kube"<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 />
| [[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 />
| {{pkg|nim}}<br />
| {{ic|~/.nimble}}<br />
| [https://github.com/nim-lang/nimble/issues/217]<br />
[https://github.com/nim-lang/Nim/issues/11340]<br />
| Nimble will [https://github.com/nim-lang/nimble/#configuration try to load] {{ic|~/.config/nimble/nimble.ini}} at startup, set {{ic|nimbleDir}} there. You will have to change {{ic|nimblepath}} in the Nim compiler [https://nim-lang.org/docs/nimc.html#compiler-usage-configuration-files configuration file] as well.<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-history}} to {{ic|$XDG_CACHE_HOME}} [https://github.com/ocaml-community/utop/pull/362]<br />
|-<br />
| {{Pkg|ollama}}<br />
| {{ic|~/.ollama}}<br />
| [https://github.com/jmorganca/ollama/issues/228]<br />
| Model locations can be set with:<br />
{{ic|1=export OLLAMA_MODELS=$XDG_DATA_HOME/ollama/models}}<br />
<br />
Source: [https://github.com/jmorganca/ollama/pull/897]<br />
|-<br />
| [[OpenSSH]]<br />
| {{ic|~/.ssh}}<br />
| [https://web.archive.org/web/20190925004614/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 />
| Partial workaround: [https://github.com/phoronix-test-suite/phoronix-test-suite/blob/ebcde81fcd5cd63956e5f8db5664262b5fd4ceb9/pts-core/pts-core.php#L123]<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 />
| {{Pkg|pulumi}}<br />
| {{ic|~/.pulumi}}<br />
| [https://github.com/pulumi/pulumi/issues/2534]<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 />
| [[R]]<br />
| {{ic|~/.Rprofile, ~/.Rdata, ~/.Rhistory}}<br />
| <br />
| <br />
R_HOME_USER="$HOME/.config/R"<br />
R_PROFILE_USER="$HOME/.config/R/profile"<br />
R_HISTFILE="$HOME/.config/R/history"<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 />
| {{Pkg|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 />
| [[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 />
| [[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|stremio}}<br />
| {{ic|~/.stremio-server/|}}<br />
| [https://github.com/Stremio/stremio-features/issues/268]<br />
|<br />
|-<br />
| [https://github.com/spring-projects/sts4 sts4]<br />
| {{ic|~/.sts4}}<br />
| [https://github.com/spring-projects/sts4/issues/601]<br />
| Pass JVM arg {{ic|1=-Dlanguageserver.boot.symbolCacheDir=$XDG_CACHE_HOME/sts4/symbolCache}}<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 />
| See [[Vim#Workaround for XDG Base Directory specification]].<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|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 />
: [https://github.com/ActiveState/appdirs appdirs] (abandoned)<br />
: [https://github.com/platformdirs/platformdirs platformdirs]<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 />
== Tips and tricks ==<br />
<br />
=== Hiding unwanted directories ===<br />
<br />
For directories which cannot be relocated, some desktop environments such as [[KDE]] allow you to hide them:<br />
<br />
$ echo ''path'' >> ~/.hidden<br />
<br />
''path'' is the path of the file/directory, relative to the parent directory of {{ic|.hidden}}.<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>Geshhttps://wiki.archlinux.org/index.php?title=Systemd/User&diff=794925Systemd/User2023-12-21T22:43:48Z<p>Gesh: Restore all-user drop-in suggestion, reformat metavariables to fit wiki style</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:System administration]]<br />
[[fr:Systemd (Français)/User]]<br />
[[it:Systemd (Italiano)/User]]<br />
[[ja:Systemd/ユーザー]]<br />
[[ru:Systemd (Русский)/User]]<br />
[[zh-hans:Systemd/User]]<br />
{{Related articles start}}<br />
{{Related|systemd}}<br />
{{Related|Automatic login to virtual console}}<br />
{{Related|Start X at login}}<br />
{{Related articles end}}<br />
<br />
[[systemd]] offers the ability to manage services under the user's control with a per-user systemd instance, enabling them to start, stop, enable, and disable their own '''user units'''. This is convenient for daemons and other services that are commonly run for a single user, such as [[mpd]], or to perform automated tasks like fetching mail.<br />
<br />
== How it works ==<br />
<br />
As per default configuration in {{ic|/etc/pam.d/system-login}}, the {{ic|pam_systemd}} module automatically launches a {{ic|systemd --user}} instance when the user logs in for the first time. This process will survive as long as there is some session for that user, and will be killed as soon as the last session for the user is closed. When [[#Automatic start-up of systemd user instances]] is enabled, the instance is started on boot and will not be killed. The systemd user instance is responsible for managing user services, which can be used to run daemons or automated tasks with all the benefits of systemd, such as socket activation, timers, dependency system, and strict process control via cgroups.<br />
<br />
Similar to system units, user units are located in the following directories (ordered by ascending precedence):<br />
<br />
* {{ic|/usr/lib/systemd/user/}} where units provided by installed packages belong.<br />
* {{ic|~/.local/share/systemd/user/}} where units of packages that have been installed in the home directory belong.<br />
* {{ic|/etc/systemd/user/}} where system-wide user units are placed by the system administrator.<br />
* {{ic|~/.config/systemd/user/}} where the user puts their own units.<br />
<br />
When a systemd user instance starts, it brings up the per user target {{ic|default.target}}. Other units can be controlled manually with {{ic|systemctl --user}}. See {{man|7|systemd.special|UNITS MANAGED BY THE USER SERVICE MANAGER}}.<br />
<br />
{{Note|<br />
* Be aware that the {{ic|systemd --user}} instance is a per-user process, and not per-session. The rationale is that most resources handled by user services, like sockets or state files will be per-user (live on the user's home directory) and not per session. This means that all user services run outside of a session. As a consequence, programs that need to be run inside a session will probably break in user services. The way systemd handles user sessions is pretty much in flux. See [https://mail.gnome.org/archives/desktop-devel-list/2014-January/msg00079.html] and [https://lists.freedesktop.org/archives/systemd-devel/2014-March/017552.html] for some hints on where things are going.<br />
* {{ic|systemd --user}} runs as a separate process from the {{ic|systemd --system}} process. User units can not reference or depend on system units or units of other users.<br />
}}<br />
<br />
== Basic setup ==<br />
<br />
All the user units will be placed in {{ic|~/.config/systemd/user/}}. If you want to start units on first login, execute {{ic|systemctl --user enable ''unit''}} for any unit you want to be autostarted.<br />
<br />
{{Tip|If you want to enable a unit for all users rather than the user executing the ''systemctl'' command, run {{ic|systemctl --global enable ''unit''}} as root. Similarly for {{ic|disable}}.}}<br />
<br />
=== Environment variables ===<br />
<br />
Units started by user instance of systemd do not inherit any of the [[environment variables]] set in places like {{ic|.bashrc}} etc. There are several ways to set environment variables for them:<br />
* For users with a {{ic|$HOME}} directory, create a ''.conf'' file in the {{ic|~/.config/environment.d/}} directory with lines of the form {{ic|NAME{{=}}VAL}}. Affects only that user's user unit. See {{man|5|environment.d}} for more information.<br />
* Use the {{ic|DefaultEnvironment}} option in {{ic|/etc/systemd/user.conf}} file. Affects all user units.<br />
* Add a drop-in configuration file in {{ic|/etc/systemd/system/user@''UID''.service.d/}}, see [[#Service example]]<br />
* Add a drop-in configuration file in {{ic|/etc/systemd/system/user@.service.d/}} (affects all users), see [[#Service example]]<br />
* At any time, use {{ic|systemctl --user set-environment}} or {{ic|systemctl --user import-environment}}. Affects all user units started after setting the environment variables, but not the units that were already running.<br />
* Using the {{ic|dbus-update-activation-environment --systemd --all}} command provided by [[dbus]]. Has the same effect as {{ic|systemctl --user import-environment}}, but also affects the D-Bus session. You can add this to the end of your shell initialization file.<br />
* For "global" environment variables for the user environment you can use the {{ic|environment.d}} directories which are parsed by some generators. See {{man|5|environment.d}} and {{man|7|systemd.generator}} for more information.<br />
* You can also write a {{man|7|systemd.environment-generator}} script which can produce environment variables that vary from user to user, this is probably the best way if you need per-user environments (this is the case for {{ic|XDG_RUNTIME_DIR}}, {{ic|DBUS_SESSION_BUS_ADDRESS}}, etc).<br />
<br />
One variable you may want to set is {{ic|PATH}}.<br />
<br />
After configuration, the command {{ic|systemctl --user show-environment}} can be used to verify that the values are correct.<br />
<br />
==== Systemd user instance ====<br />
<br />
The above only addresses default environment variables for user units. However, the systemd user instance itself is also affected by some environment variables. In particular, certain specifiers (see {{man|5|systemd.unit|SPECIFIERS}}) are affected by [[XDG Base Directory|{{ic|XDG_*}} variables]].<br />
<br />
However, the systemd user instance will ''only'' use environment variables that are set when it is started. In particular, it won't try parsing files, see [https://github.com/systemd/systemd/issues/29414 upstream bug #29414 (closed WONTFIX)]. Therefore, if such environment variables are needed, they should be set in a drop-in for {{ic|user@''UID''.service}}, cf [[#Service example]].<br />
<br />
Systemd doesn't provide introspection tools to check these values, however, something like the following service can be used to help checking that the specifiers expand as expected:<br />
{{hc|$XDG_CONFIG_HOME/systemd/user/test-specifiers.service|2=<br />
[Service]<br />
Type=oneshot<br />
ExecStart=printf '(systemd)=(envvar)\n'<br />
ExecStart=printf '%%s=%%s\n' %C "${XDG_CACHE_HOME}"<br />
ExecStart=printf '%%s=%%s\n' %E "${XDG_CONFIG_HOME}"<br />
ExecStart=printf '%%s=%%s\n' %L "${XDG_STATE_HOME}"/log<br />
ExecStart=printf '%%s=%%s\n' %S "${XDG_STATE_HOME}"<br />
ExecStart=printf '%%s=%%s\n' %t "${XDG_RUNTIME_DIR}"<br />
}}<br />
<br />
==== Service example ====<br />
<br />
Create the [[Systemd#Drop-in files|drop-in]] directory {{ic|/etc/systemd/system/user@''UID''.service.d/}} and inside create a file that has the extension ''.conf'' (e.g. {{ic|local.conf}}):<br />
<br />
{{hc|/etc/systemd/system/user@''UID''.service.d/local.conf|2=<br />
[Service]<br />
Environment="PATH=/usr/lib/ccache/bin:/usr/local/bin:/usr/bin:/bin"<br />
Environment="EDITOR=nano -c"<br />
Environment="BROWSER=firefox"<br />
Environment="NO_AT_BRIDGE=1"<br />
Environment="XDG_STATE_HOME=/home/user/.local/var/state"<br />
}}<br />
<br />
==== DISPLAY and XAUTHORITY ====<br />
<br />
{{ic|DISPLAY}} is used by any X application to know which display to use and {{ic|XAUTHORITY}} to provide a path to the user's {{ic|.Xauthority}} file and thus the cookie needed to access the X server. If you plan on launching X applications from systemd units, these variables need to be set. Systemd provides a script in {{ic|/etc/X11/xinit/xinitrc.d/50-systemd-user.sh}} to import those variables into the systemd user session on X launch. [https://github.com/systemd/systemd/blob/v219/NEWS#L194] So unless you start X in a nonstandard way, user services should be aware of the {{ic|DISPLAY}} and {{ic|XAUTHORITY}}.<br />
<br />
==== PATH ====<br />
<br />
If you customize your {{ic|PATH}} and plan on launching applications that make use of it from systemd units, you should make sure the modified {{ic|PATH}} is set on the systemd environment. Assuming you set your {{ic|PATH}} in {{ic|.bash_profile}}, the best way to make systemd aware of your modified {{ic|PATH}} is by adding the following to {{ic|.bash_profile}} after the {{ic|PATH}} variable is set:<br />
<br />
{{hc|~/.bash_profile|<br />
systemctl --user import-environment PATH<br />
}}<br />
<br />
{{Note|<br />
* This will not affect systemd services started before {{ic|PATH}} is imported.<br />
* ''systemd'' does not look at the set {{ic|PATH}} when resolving non-absolute binaries itself.}}<br />
<br />
==== pam_env ====<br />
<br />
{{Note|This way of setting environment variables per user is deprecated and will be removed.}}<br />
<br />
Environment variables can be made available through use of the {{ic|pam_env.so}} module. See [[Environment variables#Using pam_env]] for configuration details.<br />
<br />
=== Automatic start-up of systemd user instances ===<br />
<br />
The systemd user instance is started after the first login of a user and killed after the last session of the user is closed. Sometimes it may be useful to start it right after boot, and keep the systemd user instance running after the last session closes, for instance to have some user process running without any open session. Lingering is used to that effect. Use the following command to enable lingering for your own user:<br />
<br />
$ loginctl enable-linger<br />
<br />
To enable lingering for a different user:<br />
<br />
# loginctl enable-linger ''username''<br />
<br />
{{Warning|systemd services are '''not''' sessions, they run outside of ''logind''. Do not use lingering to enable automatic login as it will [[General troubleshooting#Session permissions|break the session]].}}<br />
<br />
== Writing user units ==<br />
<br />
See [[systemd#Writing unit files]] for general information about writing systemd unit files.<br />
<br />
=== Example ===<br />
<br />
The following is an example of a user version of the mpd service:<br />
<br />
{{hc|~/.config/systemd/user/mpd.service|2=<br />
[Unit]<br />
Description=Music Player Daemon<br />
<br />
[Service]<br />
ExecStart=/usr/bin/mpd --no-daemon<br />
<br />
[Install]<br />
WantedBy=default.target<br />
}}<br />
<br />
=== Example with variables ===<br />
<br />
The following is a user service used by {{AUR|foldingathome}}, which takes into account variable home directories where [[Folding@home]] can find certain files:<br />
<br />
{{hc|~/.config/systemd/user/foldingathome-user.service|2=<br />
[Unit]<br />
Description=Folding@home distributed computing client<br />
After=network.target<br />
<br />
[Service]<br />
Type=simple<br />
WorkingDirectory=%h/.config/fah<br />
ExecStart=/usr/bin/FAHClient<br />
CPUSchedulingPolicy=idle<br />
IOSchedulingClass=3<br />
<br />
[Install]<br />
WantedBy=default.target<br />
}}<br />
<br />
As detailed in {{man|5|systemd.unit|SPECIFIERS}}, the {{ic|%h}} variable is replaced by the home directory of the user running the service. There are other variables that can be taken into account in the [[systemd]] manpages.<br />
<br />
=== Reading the journal ===<br />
<br />
The journal for the user can be read using the analogous command:<br />
<br />
$ journalctl --user<br />
<br />
To specify a unit, one can use<br />
<br />
$ journalctl --user-unit myunit.service<br />
<br />
Or, equivalently:<br />
<br />
$ journalctl --user -u myunit.service<br />
<br />
{{Note|journald will not write user journals for users with UIDs below 1000, instead [https://github.com/systemd/systemd/blob/a33687b792908aa6c9f4c0b22e8935643ee0ddb6/src/journal/journald-server.c#L402 directing] everything to the system journal.}}<br />
<br />
== Temporary files ==<br />
<br />
''systemd-tmpfiles'' allows users to manage custom volatile and temporary files and directories just like in the system-wide way (see [[systemd#systemd-tmpfiles - temporary files]]). User-specific configuration files are read from {{ic|~/.config/user-tmpfiles.d/}} and {{ic|~/.local/share/user-tmpfiles.d/}}, in that order. For this functionality to be used, it is needed to enable the necessary systemd user units for your user:<br />
<br />
$ systemctl --user enable systemd-tmpfiles-setup.service systemd-tmpfiles-clean.timer<br />
<br />
The syntax of the configuration files is the same than those used system-wide. See the {{man|8|systemd-tmpfiles}} and {{man|5|tmpfiles.d}} man pages for details.<br />
<br />
== Xorg and systemd ==<br />
<br />
{{Expansion|Cover {{ic|graphical-session.target}}: {{man|7|systemd.special|Special Passive User Units}}, [https://goral.net.pl/post/systemd-x-sessions/].}}<br />
<br />
There are several ways to run xorg within systemd units. Below there are two options, either by starting a new user session with an xorg process, or by launching xorg from a systemd user service.<br />
<br />
=== Automatic login into Xorg without display manager ===<br />
<br />
{{Accuracy|This setup ends up with two user D-Bus buses, one for the desktop, and an other for systemd. Why cannot we use the systemd one alone? }}<br />
<br />
This option will launch a system unit that will start a user session with an xorg server and then run the usual {{ic|~/.xinitrc}} to launch the window manager, etc. You need to have {{AUR|xlogin-git}} installed. Set up your xinitrc as specified in the [[Xinit#xinitrc]] section.<br />
<br />
The session will use its own dbus daemon, but various systemd utilities will automatically connect to the {{ic|dbus.service}} instance. Finally, [[enable]] the {{ic|xlogin@''username''}} service for automatic login at boot. The user session lives entirely inside a systemd scope and everything in the user session should work just fine.<br />
<br />
=== Xorg as a systemd user service ===<br />
<br />
Alternatively, [[xorg]] can be run from within a systemd user service. This is nice since other X-related units can be made to depend on xorg, etc, but on the other hand, it has some drawbacks explained below.<br />
<br />
{{Pkg|xorg-server}} provides integration with systemd in two ways:<br />
<br />
* Can be run unprivileged, delegating device management to logind (see Hans de Goede commits around [https://gitlab.freedesktop.org/xorg/xserver/-/commit/82863656ec449644cd34a86388ba40f36cea11e9 this commit]).<br />
* Can be made into a socket activated service (see [https://gitlab.freedesktop.org/xorg/xserver/-/commit/b3d3ffd19937827bcbdb833a628f9b1814a6e189 this commit]). <br />
<br />
Unfortunately, to be able to run xorg in unprivileged mode, it needs to run inside a session. So, right now the handicap of running xorg as user service is that it must be run with root privileges (like before 1.16), and cannot take advantage of the unprivileged mode introduced in 1.16.<br />
<br />
{{Note|This is not a fundamental restriction imposed by logind, but the reason seems to be that xorg needs to know which session to take over, and right now it gets this information calling [https://www.freedesktop.org/wiki/Software/systemd/logind logind]'s {{ic|GetSessionByPID}} using its own pid as argument. See [https://lists.x.org/archives/xorg-devel/2014-February/040476.html this thread] and [https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/hw/xfree86/os-support/linux/systemd-logind.c xorg sources]. It seems likely that xorg could be modified to get the session from the tty it is attaching to, and then it could run unprivileged from a user service outside a session.}}<br />
<br />
{{Warning|On xorg 1.18 socket activation seems to be broken. The client triggering the activation deadlocks. See the upstream bug report [https://gitlab.freedesktop.org/xorg/xserver/issues/491]. As a temporary workaround you can start the xorg server without socket activation, making sure the clients connect after a delay, so the server is fully started. There seems to be no nice mechanism to get a startup notification for the X server.}}<br />
<br />
This is how to launch xorg from a user service:<br />
<br />
1. Make xorg run with root privileges for any user, by editing {{ic|/etc/X11/Xwrapper.config}}. This builds on [[Xorg#Xorg as Root]] by adding the stipulation that this need not be done from a physical console. That is, {{ic|allowed_user}}'s default of {{ic|console}} is being overwritten with {{ic|anybody}}; see {{Man|1|Xorg.wrap}}.<br />
<br />
{{hc|/etc/X11/Xwrapper.config|2=<br />
allowed_users=anybody<br />
needs_root_rights=yes<br />
}}<br />
<br />
2. Add the following units to {{ic|~/.config/systemd/user}}<br />
<br />
{{hc|~/.config/systemd/user/xorg@.socket|2=<br />
[Unit]<br />
Description=Socket for xorg at display %i<br />
<br />
[Socket]<br />
ListenStream=/tmp/.X11-unix/X%i<br />
}}<br />
<br />
{{hc|~/.config/systemd/user/xorg@.service|2=<br />
[Unit]<br />
Description=Xorg server at display %i<br />
<br />
Requires=xorg@%i.socket<br />
After=xorg@%i.socket<br />
<br />
[Service]<br />
Type=simple<br />
SuccessExitStatus=0 1<br />
<br />
ExecStart=/usr/bin/Xorg :%i -nolisten tcp -noreset -verbose 2 "vt${XDG_VTNR}"<br />
}}<br />
<br />
where {{ic|${XDG_VTNR}<nowiki/>}} is the virtual terminal where xorg will be launched, either hard-coded in the service unit, or set in the systemd environment with<br />
<br />
$ systemctl --user set-environment XDG_VTNR=1<br />
<br />
{{Note|xorg should be launched at the same virtual terminal where the user logged in. Otherwise logind will consider the session inactive.}}<br />
<br />
3. Make sure to configure the {{ic|DISPLAY}} environment variable as explained [[#DISPLAY and XAUTHORITY|above]].<br />
<br />
4. Then, to enable socket activation for xorg on display 0 and tty 2 one would do:<br />
<br />
$ systemctl --user set-environment XDG_VTNR=2 # So that xorg@.service knows which vt use<br />
$ systemctl --user start xorg@0.socket # Start listening on the socket for display 0<br />
<br />
Now running any X application will launch xorg on virtual terminal 2 automatically.<br />
<br />
The environment variable {{ic|XDG_VTNR}} can be set in the systemd environment from {{ic|.bash_profile}}, and then one could start any X application, including a window manager, as a systemd unit that depends on {{ic|xorg@0.socket}}.<br />
<br />
{{Warning|Currently running a window manager as a user service means it runs outside of a session with the problems this may bring: [[General troubleshooting#Session permissions|break the session]]. However, it seems that systemd developers intend to make something like this possible. See [https://mail.gnome.org/archives/desktop-devel-list/2014-January/msg00079.html] and [https://lists.freedesktop.org/archives/systemd-devel/2014-March/017552.html]}}<br />
<br />
== Some use cases ==<br />
<br />
=== Window manager ===<br />
<br />
To run a window manager as a systemd service, you first need to run [[#Xorg as a systemd user service]]. In the following we will use [[awesome]] as an example:<br />
<br />
{{hc|~/.config/systemd/user/awesome.service|2=<br />
[Unit]<br />
Description=Awesome window manager<br />
After=xorg.target<br />
Requires=xorg.target<br />
<br />
[Service]<br />
ExecStart=/usr/bin/awesome<br />
Restart=always<br />
RestartSec=10<br />
<br />
[Install]<br />
WantedBy=wm.target<br />
}}<br />
<br />
{{Note|The {{ic|[Install]}} section includes a {{ic|WantedBy}} part. When using {{ic|systemctl --user enable}} it will link this as {{ic|~/.config/systemd/user/wm.target.wants/''window_manager''.service}}, allowing it to be started at login. Is recommended to enable this service, not to link it manually.}}<br />
<br />
=== Persistent terminal multiplexer ===<br />
<br />
Rather than logging you into a window manager session for your user session by default, you may want to automatically run a terminal multiplexer (such as [[screen]] or [[tmux]]) in the background. <br />
<br />
[[Create]] the following: <br />
<br />
{{hc|~/.config/systemd/user/multiplexer.target|2=<br />
[Unit]<br />
Description=Terminal multiplexer<br />
Documentation=info:screen man:screen(1) man:tmux(1)<br />
After=cruft.target<br />
Wants=cruft.target<br />
<br />
[Install]<br />
Alias=default.target<br />
}}<br />
<br />
Separating login from X login is most likely only useful for those who boot to a TTY instead of to a display manager (in which case you can simply bundle everything you start in {{ic|mystuff.target}}). <br />
<br />
The dependency {{ic|cruft.target}}, like the {{ic|mystuff.target}} above, allows starting anything which should run before the multiplexer starts (or which you want started at boot regardless of timing), such as a GnuPG daemon session.<br />
<br />
You then need to create a service for your multiplexer session. Here is a sample service, using tmux as an example and sourcing a gpg-agent session which wrote its information to {{ic|/tmp/gpg-agent-info}}. This sample session, when you start X, will also be able to run X programs, since {{ic|$DISPLAY}} is set: <br />
<br />
{{hc|~/.config/systemd/user/tmux.service|2=<br />
[Unit]<br />
Description=tmux: A terminal multiplexer <br />
Documentation=man:tmux(1)<br />
After=gpg-agent.service<br />
Wants=gpg-agent.service<br />
<br />
[Service]<br />
Type=forking<br />
ExecStart=/usr/bin/tmux start<br />
ExecStop=/usr/bin/tmux kill-server<br />
Environment=DISPLAY=:0<br />
EnvironmentFile=/tmp/gpg-agent-info<br />
<br />
[Install]<br />
WantedBy=multiplexer.target<br />
}}<br />
<br />
[[Enable]] {{ic|tmux.service}}, {{ic|multiplexer.target}} and any services you created to be run by {{ic|cruft.target}}, [[start]] {{ic|user@.service}} as usual and you should be done.<br />
<br />
== Kill user processes on logout ==<br />
<br />
Arch Linux builds the {{pkg|systemd}} package with {{ic|--without-kill-user-processes}}, setting {{ic|KillUserProcesses}} to {{ic|no}} by default. This setting causes user processes not to be killed when the user logs out. To change this behavior in order to have all user processes killed on the user's logout, set {{ic|KillUserProcesses{{=}}yes}} in {{ic|/etc/systemd/logind.conf}}. <br />
<br />
Note that changing this setting breaks terminal multiplexers such as [[tmux]] and [[GNU Screen]]. If you change this setting, you can still use a terminal multiplexer by using {{ic|systemd-run}} as follows:<br />
<br />
$ systemd-run --scope --user ''command'' ''args''<br />
<br />
For example, to run {{ic|screen}} you would do:<br />
<br />
$ systemd-run --scope --user screen -S ''foo''<br />
<br />
Using {{ic|systemd-run}} will keep the process running after logout only while the user is logged in at least once somewhere else in the system and {{ic|user@.service}} is still running. <br />
<br />
After the user logs out of all sessions, {{ic|user@.service}} will be terminated too, by default, unless the user has "lingering" enabled [https://github.com/systemd/systemd/blob/76153ad45f09b6ae45464f2e03d3afefbb4b2afe/NEWS#L274]. To effectively allow users to run long-term tasks even if they are completely logged out, lingering must be enabled for them. See [[#Automatic start-up of systemd user instances]] and {{man|1|loginctl}} for details.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Runtime directory '/run/user/1000' is not owned by UID 1000, as it should ===<br />
<br />
systemd[1867]: pam_systemd(systemd-user:session): Runtime directory '/run/user/1000' is not owned by UID 1000, as it should.<br />
systemd[1867]: Trying to run as user instance, but $XDG_RUNTIME_DIR is not set<br />
<br />
If you see errors such as this and your login session is broken, it is possible that another system (non-user) service on your system is creating this directory. This can happen for example if you use a [[docker]] container that has a bind mount to {{ic|/run/user/1000}}. To fix this, you can either fix the container by removing the mount, or disable/delay the docker service.<br />
<br />
== See also ==<br />
<br />
* [https://bitbucket.org/KaiSforza/systemd-user-units/wiki/Home KaiSforza's Bitbucket wiki]<br />
* [https://github.com/zoqaeski/systemd-user-units Zoqaeski's units on GitHub]<br />
* [https://bbs.archlinux.org/viewtopic.php?id=167115 Arch forum thread about changes in systemd 206 user instances]</div>Geshhttps://wiki.archlinux.org/index.php?title=Systemd/User&diff=794924Systemd/User2023-12-21T22:10:09Z<p>Gesh: Configuring systemd user instance environment</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:System administration]]<br />
[[fr:Systemd (Français)/User]]<br />
[[it:Systemd (Italiano)/User]]<br />
[[ja:Systemd/ユーザー]]<br />
[[ru:Systemd (Русский)/User]]<br />
[[zh-hans:Systemd/User]]<br />
{{Related articles start}}<br />
{{Related|systemd}}<br />
{{Related|Automatic login to virtual console}}<br />
{{Related|Start X at login}}<br />
{{Related articles end}}<br />
<br />
[[systemd]] offers the ability to manage services under the user's control with a per-user systemd instance, enabling them to start, stop, enable, and disable their own '''user units'''. This is convenient for daemons and other services that are commonly run for a single user, such as [[mpd]], or to perform automated tasks like fetching mail.<br />
<br />
== How it works ==<br />
<br />
As per default configuration in {{ic|/etc/pam.d/system-login}}, the {{ic|pam_systemd}} module automatically launches a {{ic|systemd --user}} instance when the user logs in for the first time. This process will survive as long as there is some session for that user, and will be killed as soon as the last session for the user is closed. When [[#Automatic start-up of systemd user instances]] is enabled, the instance is started on boot and will not be killed. The systemd user instance is responsible for managing user services, which can be used to run daemons or automated tasks with all the benefits of systemd, such as socket activation, timers, dependency system, and strict process control via cgroups.<br />
<br />
Similar to system units, user units are located in the following directories (ordered by ascending precedence):<br />
<br />
* {{ic|/usr/lib/systemd/user/}} where units provided by installed packages belong.<br />
* {{ic|~/.local/share/systemd/user/}} where units of packages that have been installed in the home directory belong.<br />
* {{ic|/etc/systemd/user/}} where system-wide user units are placed by the system administrator.<br />
* {{ic|~/.config/systemd/user/}} where the user puts their own units.<br />
<br />
When a systemd user instance starts, it brings up the per user target {{ic|default.target}}. Other units can be controlled manually with {{ic|systemctl --user}}. See {{man|7|systemd.special|UNITS MANAGED BY THE USER SERVICE MANAGER}}.<br />
<br />
{{Note|<br />
* Be aware that the {{ic|systemd --user}} instance is a per-user process, and not per-session. The rationale is that most resources handled by user services, like sockets or state files will be per-user (live on the user's home directory) and not per session. This means that all user services run outside of a session. As a consequence, programs that need to be run inside a session will probably break in user services. The way systemd handles user sessions is pretty much in flux. See [https://mail.gnome.org/archives/desktop-devel-list/2014-January/msg00079.html] and [https://lists.freedesktop.org/archives/systemd-devel/2014-March/017552.html] for some hints on where things are going.<br />
* {{ic|systemd --user}} runs as a separate process from the {{ic|systemd --system}} process. User units can not reference or depend on system units or units of other users.<br />
}}<br />
<br />
== Basic setup ==<br />
<br />
All the user units will be placed in {{ic|~/.config/systemd/user/}}. If you want to start units on first login, execute {{ic|systemctl --user enable ''unit''}} for any unit you want to be autostarted.<br />
<br />
{{Tip|If you want to enable a unit for all users rather than the user executing the ''systemctl'' command, run {{ic|systemctl --global enable ''unit''}} as root. Similarly for {{ic|disable}}.}}<br />
<br />
=== Environment variables ===<br />
<br />
Units started by user instance of systemd do not inherit any of the [[environment variables]] set in places like {{ic|.bashrc}} etc. There are several ways to set environment variables for them:<br />
* For users with a {{ic|$HOME}} directory, create a ''.conf'' file in the {{ic|~/.config/environment.d/}} directory with lines of the form {{ic|NAME{{=}}VAL}}. Affects only that user's user unit. See {{man|5|environment.d}} for more information.<br />
* Use the {{ic|DefaultEnvironment}} option in {{ic|/etc/systemd/user.conf}} file. Affects all user units.<br />
* Add a drop-in configuration file in {{ic|/etc/systemd/system/user@$UID.service.d/}}, see [[#Service example]]<br />
* At any time, use {{ic|systemctl --user set-environment}} or {{ic|systemctl --user import-environment}}. Affects all user units started after setting the environment variables, but not the units that were already running.<br />
* Using the {{ic|dbus-update-activation-environment --systemd --all}} command provided by [[dbus]]. Has the same effect as {{ic|systemctl --user import-environment}}, but also affects the D-Bus session. You can add this to the end of your shell initialization file.<br />
* For "global" environment variables for the user environment you can use the {{ic|environment.d}} directories which are parsed by some generators. See {{man|5|environment.d}} and {{man|7|systemd.generator}} for more information.<br />
* You can also write a {{man|7|systemd.environment-generator}} script which can produce environment variables that vary from user to user, this is probably the best way if you need per-user environments (this is the case for {{ic|XDG_RUNTIME_DIR}}, {{ic|DBUS_SESSION_BUS_ADDRESS}}, etc).<br />
<br />
One variable you may want to set is {{ic|PATH}}.<br />
<br />
After configuration, the command {{ic|systemctl --user show-environment}} can be used to verify that the values are correct.<br />
<br />
==== Systemd user instance ====<br />
<br />
The above only addresses default environment variables for user units. However, the systemd user instance itself is also affected by some environment variables. In particular, certain specifiers (see {{man|5|systemd.unit|SPECIFIERS}}) are affected by [[XDG Base Directory|{{ic|XDG_*}} variables]].<br />
<br />
However, the systemd user instance will ''only'' use environment variables that are set when it is started. In particular, it won't try parsing files, see [https://github.com/systemd/systemd/issues/29414 upstream bug #29414 (closed WONTFIX)]. Therefore, if such environment variables are needed, they should be set in a drop-in for {{ic|user@$UID.service}}, cf [[#Service example]].<br />
<br />
Systemd doesn't provide introspection tools to check these values, however, something like the following service can be used to help checking that the specifiers expand as expected:<br />
{{hc|$XDG_CONFIG_HOME/systemd/user/test-specifiers.service|2=<br />
[Service]<br />
Type=oneshot<br />
ExecStart=printf '(systemd)=(envvar)\n'<br />
ExecStart=printf '%%s=%%s\n' %C "${XDG_CACHE_HOME}"<br />
ExecStart=printf '%%s=%%s\n' %E "${XDG_CONFIG_HOME}"<br />
ExecStart=printf '%%s=%%s\n' %L "${XDG_STATE_HOME}"/log<br />
ExecStart=printf '%%s=%%s\n' %S "${XDG_STATE_HOME}"<br />
ExecStart=printf '%%s=%%s\n' %t "${XDG_RUNTIME_DIR}"<br />
}}<br />
<br />
==== Service example ====<br />
<br />
Create the [[Systemd#Drop-in files|drop-in]] directory {{ic|/etc/systemd/system/user@$UID.service.d/}} and inside create a file that has the extension ''.conf'' (e.g. {{ic|local.conf}}):<br />
<br />
{{hc|/etc/systemd/system/user@.service.d/local.conf|2=<br />
[Service]<br />
Environment="PATH=/usr/lib/ccache/bin:/usr/local/bin:/usr/bin:/bin"<br />
Environment="EDITOR=nano -c"<br />
Environment="BROWSER=firefox"<br />
Environment="NO_AT_BRIDGE=1"<br />
Environment="XDG_STATE_HOME=/home/user/.local/var/state"<br />
}}<br />
<br />
==== DISPLAY and XAUTHORITY ====<br />
<br />
{{ic|DISPLAY}} is used by any X application to know which display to use and {{ic|XAUTHORITY}} to provide a path to the user's {{ic|.Xauthority}} file and thus the cookie needed to access the X server. If you plan on launching X applications from systemd units, these variables need to be set. Systemd provides a script in {{ic|/etc/X11/xinit/xinitrc.d/50-systemd-user.sh}} to import those variables into the systemd user session on X launch. [https://github.com/systemd/systemd/blob/v219/NEWS#L194] So unless you start X in a nonstandard way, user services should be aware of the {{ic|DISPLAY}} and {{ic|XAUTHORITY}}.<br />
<br />
==== PATH ====<br />
<br />
If you customize your {{ic|PATH}} and plan on launching applications that make use of it from systemd units, you should make sure the modified {{ic|PATH}} is set on the systemd environment. Assuming you set your {{ic|PATH}} in {{ic|.bash_profile}}, the best way to make systemd aware of your modified {{ic|PATH}} is by adding the following to {{ic|.bash_profile}} after the {{ic|PATH}} variable is set:<br />
<br />
{{hc|~/.bash_profile|<br />
systemctl --user import-environment PATH<br />
}}<br />
<br />
{{Note|<br />
* This will not affect systemd services started before {{ic|PATH}} is imported.<br />
* ''systemd'' does not look at the set {{ic|PATH}} when resolving non-absolute binaries itself.}}<br />
<br />
==== pam_env ====<br />
<br />
{{Note|This way of setting environment variables per user is deprecated and will be removed.}}<br />
<br />
Environment variables can be made available through use of the {{ic|pam_env.so}} module. See [[Environment variables#Using pam_env]] for configuration details.<br />
<br />
=== Automatic start-up of systemd user instances ===<br />
<br />
The systemd user instance is started after the first login of a user and killed after the last session of the user is closed. Sometimes it may be useful to start it right after boot, and keep the systemd user instance running after the last session closes, for instance to have some user process running without any open session. Lingering is used to that effect. Use the following command to enable lingering for your own user:<br />
<br />
$ loginctl enable-linger<br />
<br />
To enable lingering for a different user:<br />
<br />
# loginctl enable-linger ''username''<br />
<br />
{{Warning|systemd services are '''not''' sessions, they run outside of ''logind''. Do not use lingering to enable automatic login as it will [[General troubleshooting#Session permissions|break the session]].}}<br />
<br />
== Writing user units ==<br />
<br />
See [[systemd#Writing unit files]] for general information about writing systemd unit files.<br />
<br />
=== Example ===<br />
<br />
The following is an example of a user version of the mpd service:<br />
<br />
{{hc|~/.config/systemd/user/mpd.service|2=<br />
[Unit]<br />
Description=Music Player Daemon<br />
<br />
[Service]<br />
ExecStart=/usr/bin/mpd --no-daemon<br />
<br />
[Install]<br />
WantedBy=default.target<br />
}}<br />
<br />
=== Example with variables ===<br />
<br />
The following is a user service used by {{AUR|foldingathome}}, which takes into account variable home directories where [[Folding@home]] can find certain files:<br />
<br />
{{hc|~/.config/systemd/user/foldingathome-user.service|2=<br />
[Unit]<br />
Description=Folding@home distributed computing client<br />
After=network.target<br />
<br />
[Service]<br />
Type=simple<br />
WorkingDirectory=%h/.config/fah<br />
ExecStart=/usr/bin/FAHClient<br />
CPUSchedulingPolicy=idle<br />
IOSchedulingClass=3<br />
<br />
[Install]<br />
WantedBy=default.target<br />
}}<br />
<br />
As detailed in {{man|5|systemd.unit|SPECIFIERS}}, the {{ic|%h}} variable is replaced by the home directory of the user running the service. There are other variables that can be taken into account in the [[systemd]] manpages.<br />
<br />
=== Reading the journal ===<br />
<br />
The journal for the user can be read using the analogous command:<br />
<br />
$ journalctl --user<br />
<br />
To specify a unit, one can use<br />
<br />
$ journalctl --user-unit myunit.service<br />
<br />
Or, equivalently:<br />
<br />
$ journalctl --user -u myunit.service<br />
<br />
{{Note|journald will not write user journals for users with UIDs below 1000, instead [https://github.com/systemd/systemd/blob/a33687b792908aa6c9f4c0b22e8935643ee0ddb6/src/journal/journald-server.c#L402 directing] everything to the system journal.}}<br />
<br />
== Temporary files ==<br />
<br />
''systemd-tmpfiles'' allows users to manage custom volatile and temporary files and directories just like in the system-wide way (see [[systemd#systemd-tmpfiles - temporary files]]). User-specific configuration files are read from {{ic|~/.config/user-tmpfiles.d/}} and {{ic|~/.local/share/user-tmpfiles.d/}}, in that order. For this functionality to be used, it is needed to enable the necessary systemd user units for your user:<br />
<br />
$ systemctl --user enable systemd-tmpfiles-setup.service systemd-tmpfiles-clean.timer<br />
<br />
The syntax of the configuration files is the same than those used system-wide. See the {{man|8|systemd-tmpfiles}} and {{man|5|tmpfiles.d}} man pages for details.<br />
<br />
== Xorg and systemd ==<br />
<br />
{{Expansion|Cover {{ic|graphical-session.target}}: {{man|7|systemd.special|Special Passive User Units}}, [https://goral.net.pl/post/systemd-x-sessions/].}}<br />
<br />
There are several ways to run xorg within systemd units. Below there are two options, either by starting a new user session with an xorg process, or by launching xorg from a systemd user service.<br />
<br />
=== Automatic login into Xorg without display manager ===<br />
<br />
{{Accuracy|This setup ends up with two user D-Bus buses, one for the desktop, and an other for systemd. Why cannot we use the systemd one alone? }}<br />
<br />
This option will launch a system unit that will start a user session with an xorg server and then run the usual {{ic|~/.xinitrc}} to launch the window manager, etc. You need to have {{AUR|xlogin-git}} installed. Set up your xinitrc as specified in the [[Xinit#xinitrc]] section.<br />
<br />
The session will use its own dbus daemon, but various systemd utilities will automatically connect to the {{ic|dbus.service}} instance. Finally, [[enable]] the {{ic|xlogin@''username''}} service for automatic login at boot. The user session lives entirely inside a systemd scope and everything in the user session should work just fine.<br />
<br />
=== Xorg as a systemd user service ===<br />
<br />
Alternatively, [[xorg]] can be run from within a systemd user service. This is nice since other X-related units can be made to depend on xorg, etc, but on the other hand, it has some drawbacks explained below.<br />
<br />
{{Pkg|xorg-server}} provides integration with systemd in two ways:<br />
<br />
* Can be run unprivileged, delegating device management to logind (see Hans de Goede commits around [https://gitlab.freedesktop.org/xorg/xserver/-/commit/82863656ec449644cd34a86388ba40f36cea11e9 this commit]).<br />
* Can be made into a socket activated service (see [https://gitlab.freedesktop.org/xorg/xserver/-/commit/b3d3ffd19937827bcbdb833a628f9b1814a6e189 this commit]). <br />
<br />
Unfortunately, to be able to run xorg in unprivileged mode, it needs to run inside a session. So, right now the handicap of running xorg as user service is that it must be run with root privileges (like before 1.16), and cannot take advantage of the unprivileged mode introduced in 1.16.<br />
<br />
{{Note|This is not a fundamental restriction imposed by logind, but the reason seems to be that xorg needs to know which session to take over, and right now it gets this information calling [https://www.freedesktop.org/wiki/Software/systemd/logind logind]'s {{ic|GetSessionByPID}} using its own pid as argument. See [https://lists.x.org/archives/xorg-devel/2014-February/040476.html this thread] and [https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/hw/xfree86/os-support/linux/systemd-logind.c xorg sources]. It seems likely that xorg could be modified to get the session from the tty it is attaching to, and then it could run unprivileged from a user service outside a session.}}<br />
<br />
{{Warning|On xorg 1.18 socket activation seems to be broken. The client triggering the activation deadlocks. See the upstream bug report [https://gitlab.freedesktop.org/xorg/xserver/issues/491]. As a temporary workaround you can start the xorg server without socket activation, making sure the clients connect after a delay, so the server is fully started. There seems to be no nice mechanism to get a startup notification for the X server.}}<br />
<br />
This is how to launch xorg from a user service:<br />
<br />
1. Make xorg run with root privileges for any user, by editing {{ic|/etc/X11/Xwrapper.config}}. This builds on [[Xorg#Xorg as Root]] by adding the stipulation that this need not be done from a physical console. That is, {{ic|allowed_user}}'s default of {{ic|console}} is being overwritten with {{ic|anybody}}; see {{Man|1|Xorg.wrap}}.<br />
<br />
{{hc|/etc/X11/Xwrapper.config|2=<br />
allowed_users=anybody<br />
needs_root_rights=yes<br />
}}<br />
<br />
2. Add the following units to {{ic|~/.config/systemd/user}}<br />
<br />
{{hc|~/.config/systemd/user/xorg@.socket|2=<br />
[Unit]<br />
Description=Socket for xorg at display %i<br />
<br />
[Socket]<br />
ListenStream=/tmp/.X11-unix/X%i<br />
}}<br />
<br />
{{hc|~/.config/systemd/user/xorg@.service|2=<br />
[Unit]<br />
Description=Xorg server at display %i<br />
<br />
Requires=xorg@%i.socket<br />
After=xorg@%i.socket<br />
<br />
[Service]<br />
Type=simple<br />
SuccessExitStatus=0 1<br />
<br />
ExecStart=/usr/bin/Xorg :%i -nolisten tcp -noreset -verbose 2 "vt${XDG_VTNR}"<br />
}}<br />
<br />
where {{ic|${XDG_VTNR}<nowiki/>}} is the virtual terminal where xorg will be launched, either hard-coded in the service unit, or set in the systemd environment with<br />
<br />
$ systemctl --user set-environment XDG_VTNR=1<br />
<br />
{{Note|xorg should be launched at the same virtual terminal where the user logged in. Otherwise logind will consider the session inactive.}}<br />
<br />
3. Make sure to configure the {{ic|DISPLAY}} environment variable as explained [[#DISPLAY and XAUTHORITY|above]].<br />
<br />
4. Then, to enable socket activation for xorg on display 0 and tty 2 one would do:<br />
<br />
$ systemctl --user set-environment XDG_VTNR=2 # So that xorg@.service knows which vt use<br />
$ systemctl --user start xorg@0.socket # Start listening on the socket for display 0<br />
<br />
Now running any X application will launch xorg on virtual terminal 2 automatically.<br />
<br />
The environment variable {{ic|XDG_VTNR}} can be set in the systemd environment from {{ic|.bash_profile}}, and then one could start any X application, including a window manager, as a systemd unit that depends on {{ic|xorg@0.socket}}.<br />
<br />
{{Warning|Currently running a window manager as a user service means it runs outside of a session with the problems this may bring: [[General troubleshooting#Session permissions|break the session]]. However, it seems that systemd developers intend to make something like this possible. See [https://mail.gnome.org/archives/desktop-devel-list/2014-January/msg00079.html] and [https://lists.freedesktop.org/archives/systemd-devel/2014-March/017552.html]}}<br />
<br />
== Some use cases ==<br />
<br />
=== Window manager ===<br />
<br />
To run a window manager as a systemd service, you first need to run [[#Xorg as a systemd user service]]. In the following we will use [[awesome]] as an example:<br />
<br />
{{hc|~/.config/systemd/user/awesome.service|2=<br />
[Unit]<br />
Description=Awesome window manager<br />
After=xorg.target<br />
Requires=xorg.target<br />
<br />
[Service]<br />
ExecStart=/usr/bin/awesome<br />
Restart=always<br />
RestartSec=10<br />
<br />
[Install]<br />
WantedBy=wm.target<br />
}}<br />
<br />
{{Note|The {{ic|[Install]}} section includes a {{ic|WantedBy}} part. When using {{ic|systemctl --user enable}} it will link this as {{ic|~/.config/systemd/user/wm.target.wants/''window_manager''.service}}, allowing it to be started at login. Is recommended to enable this service, not to link it manually.}}<br />
<br />
=== Persistent terminal multiplexer ===<br />
<br />
Rather than logging you into a window manager session for your user session by default, you may want to automatically run a terminal multiplexer (such as [[screen]] or [[tmux]]) in the background. <br />
<br />
[[Create]] the following: <br />
<br />
{{hc|~/.config/systemd/user/multiplexer.target|2=<br />
[Unit]<br />
Description=Terminal multiplexer<br />
Documentation=info:screen man:screen(1) man:tmux(1)<br />
After=cruft.target<br />
Wants=cruft.target<br />
<br />
[Install]<br />
Alias=default.target<br />
}}<br />
<br />
Separating login from X login is most likely only useful for those who boot to a TTY instead of to a display manager (in which case you can simply bundle everything you start in {{ic|mystuff.target}}). <br />
<br />
The dependency {{ic|cruft.target}}, like the {{ic|mystuff.target}} above, allows starting anything which should run before the multiplexer starts (or which you want started at boot regardless of timing), such as a GnuPG daemon session.<br />
<br />
You then need to create a service for your multiplexer session. Here is a sample service, using tmux as an example and sourcing a gpg-agent session which wrote its information to {{ic|/tmp/gpg-agent-info}}. This sample session, when you start X, will also be able to run X programs, since {{ic|$DISPLAY}} is set: <br />
<br />
{{hc|~/.config/systemd/user/tmux.service|2=<br />
[Unit]<br />
Description=tmux: A terminal multiplexer <br />
Documentation=man:tmux(1)<br />
After=gpg-agent.service<br />
Wants=gpg-agent.service<br />
<br />
[Service]<br />
Type=forking<br />
ExecStart=/usr/bin/tmux start<br />
ExecStop=/usr/bin/tmux kill-server<br />
Environment=DISPLAY=:0<br />
EnvironmentFile=/tmp/gpg-agent-info<br />
<br />
[Install]<br />
WantedBy=multiplexer.target<br />
}}<br />
<br />
[[Enable]] {{ic|tmux.service}}, {{ic|multiplexer.target}} and any services you created to be run by {{ic|cruft.target}}, [[start]] {{ic|user@.service}} as usual and you should be done.<br />
<br />
== Kill user processes on logout ==<br />
<br />
Arch Linux builds the {{pkg|systemd}} package with {{ic|--without-kill-user-processes}}, setting {{ic|KillUserProcesses}} to {{ic|no}} by default. This setting causes user processes not to be killed when the user logs out. To change this behavior in order to have all user processes killed on the user's logout, set {{ic|KillUserProcesses{{=}}yes}} in {{ic|/etc/systemd/logind.conf}}. <br />
<br />
Note that changing this setting breaks terminal multiplexers such as [[tmux]] and [[GNU Screen]]. If you change this setting, you can still use a terminal multiplexer by using {{ic|systemd-run}} as follows:<br />
<br />
$ systemd-run --scope --user ''command'' ''args''<br />
<br />
For example, to run {{ic|screen}} you would do:<br />
<br />
$ systemd-run --scope --user screen -S ''foo''<br />
<br />
Using {{ic|systemd-run}} will keep the process running after logout only while the user is logged in at least once somewhere else in the system and {{ic|user@.service}} is still running. <br />
<br />
After the user logs out of all sessions, {{ic|user@.service}} will be terminated too, by default, unless the user has "lingering" enabled [https://github.com/systemd/systemd/blob/76153ad45f09b6ae45464f2e03d3afefbb4b2afe/NEWS#L274]. To effectively allow users to run long-term tasks even if they are completely logged out, lingering must be enabled for them. See [[#Automatic start-up of systemd user instances]] and {{man|1|loginctl}} for details.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Runtime directory '/run/user/1000' is not owned by UID 1000, as it should ===<br />
<br />
systemd[1867]: pam_systemd(systemd-user:session): Runtime directory '/run/user/1000' is not owned by UID 1000, as it should.<br />
systemd[1867]: Trying to run as user instance, but $XDG_RUNTIME_DIR is not set<br />
<br />
If you see errors such as this and your login session is broken, it is possible that another system (non-user) service on your system is creating this directory. This can happen for example if you use a [[docker]] container that has a bind mount to {{ic|/run/user/1000}}. To fix this, you can either fix the container by removing the mount, or disable/delay the docker service.<br />
<br />
== See also ==<br />
<br />
* [https://bitbucket.org/KaiSforza/systemd-user-units/wiki/Home KaiSforza's Bitbucket wiki]<br />
* [https://github.com/zoqaeski/systemd-user-units Zoqaeski's units on GitHub]<br />
* [https://bbs.archlinux.org/viewtopic.php?id=167115 Arch forum thread about changes in systemd 206 user instances]</div>Geshhttps://wiki.archlinux.org/index.php?title=Talk:XDG_Base_Directory&diff=785181Talk:XDG Base Directory2023-08-11T11:26:35Z<p>Gesh: Fix my signatures</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 />
::Would it be advised to use symbolic links to manually split such offending programs into their corresponding places? There are a lot of offending packages that store their cache inside the {{ic|$XDG_CONFIG_HOME}} instead of in {{ic|$XDG_CACHE_HOME}}. I noticed a pattern, though. Most of the offenders use Electron, or are Chromium-based browsers... could they be nudged to automatically migrate the data to the corresponding places? [[User:Rolandog|Rolandog]] ([[User talk:Rolandog|talk]]) 12:58, 10 February 2022 (UTC)<br />
<br />
:::To answer your first question, for any use cases I can think of, I wouldn't advise it. For the case of having all of your {{ic|~/.config}} in VCS, replacing the offending configurations with symlinks provides no clear advantage over adding a line to a {{ic|.gitignore}}. In fact, this increases the overhead needed to setup a new system, and some might argue that the complexity added to your hierarchy by having the same files in two locations is also undesirable.<br />
<br />
:::As for the Electron programs, this is an even more egregious abuse of {{ic|$XDG_CACHE_HOME}} than [[User:Alad|Alad]] was referring to. This section was, as I understand it, mainly targeting Qt programs who put human-unreadable, non-configuration state in configuration files. Nevertheless, the same principles apply. Add the offending programs to a {{ic|.gitignore}}. Though most Electron programs indeed share a common structure, I feel like {{ic|.gitignore}} is too primitive to do anything very useful with this information. I think you still be best off blocking entire Electron program config directories manually. Cheers, [[User:CodingKoopa|CodingKoopa]] ([[User talk:CodingKoopa|talk]]) 04:42, 2 March 2022 (UTC)<br />
<br />
:I deleted Chromium from the `partial' list because it abuses the ~.config directory. Unfortunately it had some links. I woudn't put it in the `hardcoded' section though. Maybe we could have an `unsupported' section, to be used when we need to explain why we consider some program unsupported and write there some references? [[User:Tétrapyle|Tétrapyle]] ([[User talk:Tétrapyle|talk]]) 08:59, 20 December 2022 (UTC)<br />
<br />
::Programs like Chromium are not "unsupported" in the same way that programs who use {{ic|$HOME/.''directory''}}, and this should be reflected in their placement. Given how prevalent XDG abuse is, I would honestly put them where they would go anyways, and note the abuse in the ''Notes'' column. The alternatives would unneededly complicate the page by adding another "degree" of support, I think. -- [[User:CodingKoopa|CodingKoopa]] ([[User talk:CodingKoopa|talk]]) 02:22, 25 December 2022 (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 />
::::I for one am not fond of 5 (?!) additional colored columns. It leads to visual overload, there's already enough columns in the table as is. Maybe we can just think of some alternative categories if "partial" is deemed misleading. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:24, 11 November 2021 (UTC)<br />
<br />
::::I question the value add for all the extra fields. Especially as compliance in programs tends to be more nuanced than this allows. For example, many programs make use of {{ic|XDG_CONFIG_HOME}} but debatably fail to correctly follow the standard, mixing state with config, etc. The reality is many developers have different interpretations of the standard which would require far more binary options to capture. I propose a simpler table that doesn't try to over-define abstract values for implementations, and just captures the implementation detail.<br />
::::{| class="wikitable sortable"<br />
! Application<br />
! Official paths<br />
! XDG Base Directory Implementation<br />
! Notes<br />
|-<br />
| Cool-utils<br />
| {{ic|.cool-utils/}}, {{ic|$XDG_CONFIG_HOME/cool-utils/}}<br />
| Uses {{ic|$XDG_CONFIG_DIR}} by default as of 1.2.0.[https://example.com/example/issues/1] Stores extension binaries with config.<br />
| {{-}}<br />
|-<br />
| git-xmonad<br />
| {{ic|.git-xmonad}}<br />
| {{No|http://example.com/bug/1}}<br />
| [http://example.com/bug/1 After legacy]<br />
|-<br />
| Dumper<br />
| {{ic|$XDG_DATA_HOME/dumper/}}<br />
| {{Yes}}<br />
| (an example of a program that always had native support for the standard)<br />
|-<br />
| Hostile-app<br />
| {{ic|.hostileapp/}}<br />
| {{No|[http://example.com/bug/1 WONTFIX]}}<br />
| Workaround: {{ic|1=$ export GARBAGEBIN="$XDG_DATA_HOME"/hostile-app}}<br />
|}<br />
::::[[User:Comic-paralyze-image|Comic-paralyze-image]] ([[User talk:Comic-paralyze-image|talk]]) 15:23, 11 November 2021 (UTC)<br />
<br />
::::More columns are better for people…<br />
::::* maintaining this page<br />
::::* looking to move projects towards supporting XDG more<br />
::::* selecting software based on XDG-support<br />
<br />
::::Fewer columns are better for people…<br />
::::* trying to get their particular piece of software to work better with XDG<br />
<br />
::::That's my current impression.<br />
<br />
::::* I've spent more time as part of the more-columns-group, than I have as part of the fewer-columns-group.<br />
::::* I suspect that much more time is spent by the latter group.<br />
::::* The table should imo still stay readable to people who are seeing it for the 1st time (Cpt. Obvious).<br />
::::* But it would be nice to be able to express and sort by more granularity.<br />
::::* I disagree that more columns automatically make it overwhelming; Wikipedia has a lot of these tables. They've probably put a lot of thought into them, and they're still using them. [[User:Cyethiod|Cyethiod]] ([[User talk:Cyethiod|talk]]) 13:55, 12 November 2021 (UTC)<br />
<br />
:::::It doesn't matter what Wikipedia has or hasn't. Adding 5 columns is an extreme measure to add "more granularity". 1 extra column is fine for me. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:01, 12 November 2021 (UTC)<br />
<br />
::::::I disagree. Most, if not all people who arrive at this ArchWiki-article, have seen Wikipedia pages with tables in them. Both projects even use the same software. Worth mentioning: [[User:Lahwaacz|Lahwaacz]]'s doubt that even Wikipedia has a table as large as those on this page.<br />
<br />
::::::Am I right in thinking that you and I agree on more granularity, but not on the way to achieve it? :) [[User:Cyethiod|Cyethiod]] ([[User talk:Cyethiod|talk]]) 16:18, 12 November 2021 (UTC)<br />
<br />
:::::I doubt that even Wikipedia has a table as large as those on this page... — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:13, 12 November 2021 (UTC)<br />
<br />
::::::Would this serve as a sufficient counter-example? 23 columns (36 rows) - [https://en.wikipedia.org/w/index.php?title=Comparison_of_virtual_reality_headsets&oldid=1052030717#Tethered_VR Comparison of virtual reality headsets #Tethered]. [[User:Cyethiod|Cyethiod]] ([[User talk:Cyethiod|talk]]) 16:12, 12 November 2021 (UTC)<br />
<br />
:::::::That's not nearly as large, since there are over 400 rows in 4 tables on this page. Also none of those 23 columns contains arbitrary-width content like the current "Notes" column here. None of the proposals above removed that column, and one even added another column where arbitrary notes might be added. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:37, 12 November 2021 (UTC)<br />
<br />
:::::For every user on Wikipedia that wants larger, more verbose tables, there are a dozen users that will cite rules about Manual of Style violations, original research, etc. I would not hold Wikipedia articles as a shining example of _the correct way to do something_. If you really want a reference from Wikipedia, I would find a MOS page instead.<br />
:::::In general I am a more-columns person, but having made some effort myself to implement overrides I really think we would need more than six columns to capture **everything** meaningful.<br />
:::::If we wanted more columns, I would suggest following the standard more closely:<br />
:::::{| class="wikitable sortable"<br />
! Application<br />
! Data files<br />
! Configuration files<br />
! State data<br />
! Executable files<br />
! Notes<br />
|-<br />
| Cool-utils<br />
| {{-}}<br />
| {{G|{{ic|$XDG_CONFIG_HOME/cool-utils/}} as of 1.2.0.[https://example.com/example/issues/1]}}<br />
| {{-}}<br />
| {{Y|{{ic|$XDG_CONFIG_HOME/cool-utils/}} Stores extension binaries with config.}}<br />
| {{-}}<br />
|-<br />
| git-xmonad<br />
| {{R|{{ic|.git-xmonad}}[http://example.com/bug/1]}}<br />
| {{R|{{ic|.git-xmonad}}}}<br />
| {{-}}<br />
| {{-}}<br />
| [http://example.com/bug/1 After legacy]<br />
|-<br />
| Dumper<br />
| {{G|{{ic|$XDG_DATA_HOME/dumper/}}}}<br />
| {{G|{{ic|$XDG_CONFIG_HOME/dumper/}}}}<br />
| {{-}}<br />
| {{-}}<br />
| (an example of a program that always had native support for the standard)<br />
|-<br />
| Hostile-app<br />
| {{R|{{ic|.hostileapp/}}[http://example.com/bug/1 WONTFIX]}}<br />
| {{-}}<br />
| {{R|{{ic|.hostileapp/}}}}<br />
| {{R|{{ic|.hostileapp/}}}}<br />
| Workaround: {{ic|1=$ export GARBAGEBIN="$XDG_DATA_HOME"/hostile-app}}<br />
|}<br />
:::::The biggest problem with an extended table like this, is the additional onus on writers to confirm AND AGREE that an implementation is correct. Agreeing on the standard doesn't appear to be easy.<br />
:::::--[[User:Comic-paralyze-image|Comic-paralyze-image]] ([[User talk:Comic-paralyze-image|talk]]) 18:53, 12 November 2021 (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)<br />
<br />
== OpenAL .alsoftrc ==<br />
<br />
i'm pretty sure openal supports xdg base dir since it's in [https://github.com/kcat/openal-soft/blob/9cce3ba/ChangeLog#L587 the changelog], but i don't want to contribute it myself since i don't know how to actually test if what i do is correct.<br />
every other archwiki page i've seen (such as [[Gaming#Binaural_audio_with_OpenAL]]) only mentions {{ic|~/.alsoftrc}}.<br />
can someone help figure out the situation with openal?<br />
<br />
[[User:SArpnt|SArpnt]] ([[User talk:SArpnt|talk]]) 23:32, 5 November 2022 (UTC)<br />
<br />
: [https://github.com/kcat/openal-soft/blob/0526ecd2f95877b167293e50ab8ce0ce614d03f4/alc/alconfig.cpp#L365 {{ic|ReadALConfig()}} in alconfig.cpp] searches xdg paths in addition to legacy ({{ic|~/.alsoftrc}} and {{ic|/etc/alsoft.conf}} so I'll add it to "supported" [[User:wowaname|<span style="color:#f7f">wowaname</span>]] [[User talk:wowaname|<span style="color:#f80">#</span>]] [[Special:Contributions/wowaname|<span style="color:#f80">C</span>]] 22:02, 14 February 2023 (UTC)<br />
<br />
== Adding references to developer communication unavailable on web ==<br />
<br />
Talked to {{ic|xscreensaver}} upstream re XDG, they clearly communicated WONTFIX.<br />
However, since they don't use a bugtracker and instead only communicate via direct email,<br />
there is no webpage to link to.<br />
ATM, just copied their response into the table -- {{ic|<ref>}} doesn't appear to work there.<br />
However, this is clearly suboptimal -- is there a better way of doing this?<br />
[[User:Gesh|Gesh]] ([[User talk:Gesh|talk]]) 10:10, 6 August 2023 (UTC)<br />
<br />
:You can just add a link. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:22, 6 August 2023 (UTC)<br />
<br />
:Am confused. I just spent the entire paragraph above explaining why there is no page to link to -- only an email by upstream to me where they expressed their strong objection to changing the situation. I guess you _could_ bug upstream to add an entry to the FAQ, but I'd rather not prod them for that myself, given the vehemence of the objection (I gather it might be a bit of a sore spot).<br />
:In case my edit is restored, further communication from upstream yesterday (2023-08-06) seems to confirm invoking {{ic|xscreensaver}} with {{ic|HOME{{=}}$XDG_CONFIG_HOME/xscreensaver/}} should work (referring to {{ic|~/.xscreensaver}}) {{bc|Both xscreensaver and xscreensaver-settings use that file and communicate with each other through it. xscreensaver-text, xscreensaver-getimage-file and vidwhacker also read it. xscreensaver-getimage-file and mapscroller.pl use FreeDesktop locations for cache files if those directories exist.}}[[User:Gesh|Gesh]] ([[User talk:Gesh|talk]]) 18:05, 7 August 2023 (UTC)<br />
<br />
::I meant you could add a [https://www.mediawiki.org/wiki/Help:Links#External_links link] instead of {{ic|<ref>}} which ''technically'' does not work on this wiki. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:12, 7 August 2023 (UTC)<br />
:::How would that help? The entire reason I'm asking for {{ic|<ref>}} is to be able to move the contents of the email I'm citing to a footnote or similarly move it to somewhere where it doesn't dominate the page. Where would I link to? Unless you're suggesting I encode it in a data url or pastebin it, a la [data:text/plain;charset=utf-8;base64,SSB0aGluayB3aGF0IHlvdSdyZSBhc2tpbmcgZm9yIGlzOiBzdG9yZSB0aGUgY29uZmlndXJhdGlvbiBmaWxlIHNvbWV3aGVyZSBvdGhlciB0aGFuIGxpdGVyYWxseSB+Ly54c2NyZWVuc2F2ZXIsIGFuZCBubywgSSdtIG5ldmVyLCBldmVyIGdvaW5nIHRvIGRvIHRoYXQuIEl0IGhhcyB0aG]? Note that even that is unsupported -- wiki only allows linking to {{ic|http(s)}} urls. [[User:Gesh|Gesh]] ([[User talk:Gesh|talk]]) 08:24, 8 August 2023 (UTC)<br />
<br />
::::That would be a blunt abuse of {{ic|<ref>}} as that is intended for verifiable citations. There is no alternative solution for what you want to do. You need a verifiable source to cite, so either convince upstream to make a public statement or disclose the private communication somewhere (which may be unethical in itself). If you don't want to do it, I suggest you just leave it. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:37, 8 August 2023 (UTC)<br />
:::::Fine, talked with upstream, they didn't want to put in the FAQ, so I guess this will remain undocumented. Too bad. [[User:Gesh|Gesh]] ([[User talk:Gesh|talk]]) 11:26, 11 August 2023 (UTC)<br />
<br />
== Please don't add hacky solutions ==<br />
<br />
Aliasing {{ic|rm -rf}} tastes like a recipe for disaster. If a program does not support XDG Base Directory, please don't propose hacky workarounds. --[[User:AvidSeeker|AvidSeeker]] ([[User talk:AvidSeeker|talk]]) 06:36, 9 August 2023 (UTC)<br />
<br />
:If the partial support for XDG Base Directories is so broken that the entire workflow collapses without a hacky workaround, then the software doesn't deserve to be in the partial support section under this new rule. But there's no section for software whose partial support is so broken that the support may as well not exist. Since {{AUR|python-filetags}} neither fully nor partially supports XDG Base Directories, but also doesn't hardcode a path, I removed the package from the list entirely.<br />
<br />
:The only reason why my original solution didn't use a hacky workaround is because I fixed the bug in my fork. But [https://github.com/novoid/filetags/pull/56 the fix is currently stuck in PR review limbo]. — [[User:Fedora|Fedora]] ([[User talk:Fedora|talk]]) 07:02, 9 August 2023 (UTC)</div>Geshhttps://wiki.archlinux.org/index.php?title=Talk:XDG_Base_Directory&diff=785180Talk:XDG Base Directory2023-08-11T11:25:42Z<p>Gesh: Notified upstream refuses to document position publicly</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 />
::Would it be advised to use symbolic links to manually split such offending programs into their corresponding places? There are a lot of offending packages that store their cache inside the {{ic|$XDG_CONFIG_HOME}} instead of in {{ic|$XDG_CACHE_HOME}}. I noticed a pattern, though. Most of the offenders use Electron, or are Chromium-based browsers... could they be nudged to automatically migrate the data to the corresponding places? [[User:Rolandog|Rolandog]] ([[User talk:Rolandog|talk]]) 12:58, 10 February 2022 (UTC)<br />
<br />
:::To answer your first question, for any use cases I can think of, I wouldn't advise it. For the case of having all of your {{ic|~/.config}} in VCS, replacing the offending configurations with symlinks provides no clear advantage over adding a line to a {{ic|.gitignore}}. In fact, this increases the overhead needed to setup a new system, and some might argue that the complexity added to your hierarchy by having the same files in two locations is also undesirable.<br />
<br />
:::As for the Electron programs, this is an even more egregious abuse of {{ic|$XDG_CACHE_HOME}} than [[User:Alad|Alad]] was referring to. This section was, as I understand it, mainly targeting Qt programs who put human-unreadable, non-configuration state in configuration files. Nevertheless, the same principles apply. Add the offending programs to a {{ic|.gitignore}}. Though most Electron programs indeed share a common structure, I feel like {{ic|.gitignore}} is too primitive to do anything very useful with this information. I think you still be best off blocking entire Electron program config directories manually. Cheers, [[User:CodingKoopa|CodingKoopa]] ([[User talk:CodingKoopa|talk]]) 04:42, 2 March 2022 (UTC)<br />
<br />
:I deleted Chromium from the `partial' list because it abuses the ~.config directory. Unfortunately it had some links. I woudn't put it in the `hardcoded' section though. Maybe we could have an `unsupported' section, to be used when we need to explain why we consider some program unsupported and write there some references? [[User:Tétrapyle|Tétrapyle]] ([[User talk:Tétrapyle|talk]]) 08:59, 20 December 2022 (UTC)<br />
<br />
::Programs like Chromium are not "unsupported" in the same way that programs who use {{ic|$HOME/.''directory''}}, and this should be reflected in their placement. Given how prevalent XDG abuse is, I would honestly put them where they would go anyways, and note the abuse in the ''Notes'' column. The alternatives would unneededly complicate the page by adding another "degree" of support, I think. -- [[User:CodingKoopa|CodingKoopa]] ([[User talk:CodingKoopa|talk]]) 02:22, 25 December 2022 (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 />
::::I for one am not fond of 5 (?!) additional colored columns. It leads to visual overload, there's already enough columns in the table as is. Maybe we can just think of some alternative categories if "partial" is deemed misleading. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:24, 11 November 2021 (UTC)<br />
<br />
::::I question the value add for all the extra fields. Especially as compliance in programs tends to be more nuanced than this allows. For example, many programs make use of {{ic|XDG_CONFIG_HOME}} but debatably fail to correctly follow the standard, mixing state with config, etc. The reality is many developers have different interpretations of the standard which would require far more binary options to capture. I propose a simpler table that doesn't try to over-define abstract values for implementations, and just captures the implementation detail.<br />
::::{| class="wikitable sortable"<br />
! Application<br />
! Official paths<br />
! XDG Base Directory Implementation<br />
! Notes<br />
|-<br />
| Cool-utils<br />
| {{ic|.cool-utils/}}, {{ic|$XDG_CONFIG_HOME/cool-utils/}}<br />
| Uses {{ic|$XDG_CONFIG_DIR}} by default as of 1.2.0.[https://example.com/example/issues/1] Stores extension binaries with config.<br />
| {{-}}<br />
|-<br />
| git-xmonad<br />
| {{ic|.git-xmonad}}<br />
| {{No|http://example.com/bug/1}}<br />
| [http://example.com/bug/1 After legacy]<br />
|-<br />
| Dumper<br />
| {{ic|$XDG_DATA_HOME/dumper/}}<br />
| {{Yes}}<br />
| (an example of a program that always had native support for the standard)<br />
|-<br />
| Hostile-app<br />
| {{ic|.hostileapp/}}<br />
| {{No|[http://example.com/bug/1 WONTFIX]}}<br />
| Workaround: {{ic|1=$ export GARBAGEBIN="$XDG_DATA_HOME"/hostile-app}}<br />
|}<br />
::::[[User:Comic-paralyze-image|Comic-paralyze-image]] ([[User talk:Comic-paralyze-image|talk]]) 15:23, 11 November 2021 (UTC)<br />
<br />
::::More columns are better for people…<br />
::::* maintaining this page<br />
::::* looking to move projects towards supporting XDG more<br />
::::* selecting software based on XDG-support<br />
<br />
::::Fewer columns are better for people…<br />
::::* trying to get their particular piece of software to work better with XDG<br />
<br />
::::That's my current impression.<br />
<br />
::::* I've spent more time as part of the more-columns-group, than I have as part of the fewer-columns-group.<br />
::::* I suspect that much more time is spent by the latter group.<br />
::::* The table should imo still stay readable to people who are seeing it for the 1st time (Cpt. Obvious).<br />
::::* But it would be nice to be able to express and sort by more granularity.<br />
::::* I disagree that more columns automatically make it overwhelming; Wikipedia has a lot of these tables. They've probably put a lot of thought into them, and they're still using them. [[User:Cyethiod|Cyethiod]] ([[User talk:Cyethiod|talk]]) 13:55, 12 November 2021 (UTC)<br />
<br />
:::::It doesn't matter what Wikipedia has or hasn't. Adding 5 columns is an extreme measure to add "more granularity". 1 extra column is fine for me. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:01, 12 November 2021 (UTC)<br />
<br />
::::::I disagree. Most, if not all people who arrive at this ArchWiki-article, have seen Wikipedia pages with tables in them. Both projects even use the same software. Worth mentioning: [[User:Lahwaacz|Lahwaacz]]'s doubt that even Wikipedia has a table as large as those on this page.<br />
<br />
::::::Am I right in thinking that you and I agree on more granularity, but not on the way to achieve it? :) [[User:Cyethiod|Cyethiod]] ([[User talk:Cyethiod|talk]]) 16:18, 12 November 2021 (UTC)<br />
<br />
:::::I doubt that even Wikipedia has a table as large as those on this page... — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:13, 12 November 2021 (UTC)<br />
<br />
::::::Would this serve as a sufficient counter-example? 23 columns (36 rows) - [https://en.wikipedia.org/w/index.php?title=Comparison_of_virtual_reality_headsets&oldid=1052030717#Tethered_VR Comparison of virtual reality headsets #Tethered]. [[User:Cyethiod|Cyethiod]] ([[User talk:Cyethiod|talk]]) 16:12, 12 November 2021 (UTC)<br />
<br />
:::::::That's not nearly as large, since there are over 400 rows in 4 tables on this page. Also none of those 23 columns contains arbitrary-width content like the current "Notes" column here. None of the proposals above removed that column, and one even added another column where arbitrary notes might be added. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:37, 12 November 2021 (UTC)<br />
<br />
:::::For every user on Wikipedia that wants larger, more verbose tables, there are a dozen users that will cite rules about Manual of Style violations, original research, etc. I would not hold Wikipedia articles as a shining example of _the correct way to do something_. If you really want a reference from Wikipedia, I would find a MOS page instead.<br />
:::::In general I am a more-columns person, but having made some effort myself to implement overrides I really think we would need more than six columns to capture **everything** meaningful.<br />
:::::If we wanted more columns, I would suggest following the standard more closely:<br />
:::::{| class="wikitable sortable"<br />
! Application<br />
! Data files<br />
! Configuration files<br />
! State data<br />
! Executable files<br />
! Notes<br />
|-<br />
| Cool-utils<br />
| {{-}}<br />
| {{G|{{ic|$XDG_CONFIG_HOME/cool-utils/}} as of 1.2.0.[https://example.com/example/issues/1]}}<br />
| {{-}}<br />
| {{Y|{{ic|$XDG_CONFIG_HOME/cool-utils/}} Stores extension binaries with config.}}<br />
| {{-}}<br />
|-<br />
| git-xmonad<br />
| {{R|{{ic|.git-xmonad}}[http://example.com/bug/1]}}<br />
| {{R|{{ic|.git-xmonad}}}}<br />
| {{-}}<br />
| {{-}}<br />
| [http://example.com/bug/1 After legacy]<br />
|-<br />
| Dumper<br />
| {{G|{{ic|$XDG_DATA_HOME/dumper/}}}}<br />
| {{G|{{ic|$XDG_CONFIG_HOME/dumper/}}}}<br />
| {{-}}<br />
| {{-}}<br />
| (an example of a program that always had native support for the standard)<br />
|-<br />
| Hostile-app<br />
| {{R|{{ic|.hostileapp/}}[http://example.com/bug/1 WONTFIX]}}<br />
| {{-}}<br />
| {{R|{{ic|.hostileapp/}}}}<br />
| {{R|{{ic|.hostileapp/}}}}<br />
| Workaround: {{ic|1=$ export GARBAGEBIN="$XDG_DATA_HOME"/hostile-app}}<br />
|}<br />
:::::The biggest problem with an extended table like this, is the additional onus on writers to confirm AND AGREE that an implementation is correct. Agreeing on the standard doesn't appear to be easy.<br />
:::::--[[User:Comic-paralyze-image|Comic-paralyze-image]] ([[User talk:Comic-paralyze-image|talk]]) 18:53, 12 November 2021 (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)<br />
<br />
== OpenAL .alsoftrc ==<br />
<br />
i'm pretty sure openal supports xdg base dir since it's in [https://github.com/kcat/openal-soft/blob/9cce3ba/ChangeLog#L587 the changelog], but i don't want to contribute it myself since i don't know how to actually test if what i do is correct.<br />
every other archwiki page i've seen (such as [[Gaming#Binaural_audio_with_OpenAL]]) only mentions {{ic|~/.alsoftrc}}.<br />
can someone help figure out the situation with openal?<br />
<br />
[[User:SArpnt|SArpnt]] ([[User talk:SArpnt|talk]]) 23:32, 5 November 2022 (UTC)<br />
<br />
: [https://github.com/kcat/openal-soft/blob/0526ecd2f95877b167293e50ab8ce0ce614d03f4/alc/alconfig.cpp#L365 {{ic|ReadALConfig()}} in alconfig.cpp] searches xdg paths in addition to legacy ({{ic|~/.alsoftrc}} and {{ic|/etc/alsoft.conf}} so I'll add it to "supported" [[User:wowaname|<span style="color:#f7f">wowaname</span>]] [[User talk:wowaname|<span style="color:#f80">#</span>]] [[Special:Contributions/wowaname|<span style="color:#f80">C</span>]] 22:02, 14 February 2023 (UTC)<br />
<br />
== Adding references to developer communication unavailable on web ==<br />
<br />
Talked to {{ic|xscreensaver}} upstream re XDG, they clearly communicated WONTFIX.<br />
However, since they don't use a bugtracker and instead only communicate via direct email,<br />
there is no webpage to link to.<br />
ATM, just copied their response into the table -- {{ic|<ref>}} doesn't appear to work there.<br />
However, this is clearly suboptimal -- is there a better way of doing this?<br />
[[User:Gesh|Gesh]] ([[User talk:Gesh|talk]]) 10:10, 6 August 2023 (UTC)<br />
<br />
:You can just add a link. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:22, 6 August 2023 (UTC)<br />
<br />
:Am confused. I just spent the entire paragraph above explaining why there is no page to link to -- only an email by upstream to me where they expressed their strong objection to changing the situation. I guess you _could_ bug upstream to add an entry to the FAQ, but I'd rather not prod them for that myself, given the vehemence of the objection (I gather it might be a bit of a sore spot).<br />
:In case my edit is restored, further communication from upstream yesterday (2023-08-06) seems to confirm invoking {{ic|xscreensaver}} with {{ic|HOME{{=}}$XDG_CONFIG_HOME/xscreensaver/}} should work (referring to {{ic|~/.xscreensaver}}) {{bc|Both xscreensaver and xscreensaver-settings use that file and communicate with each other through it. xscreensaver-text, xscreensaver-getimage-file and vidwhacker also read it. xscreensaver-getimage-file and mapscroller.pl use FreeDesktop locations for cache files if those directories exist.}}[[User:Gesh|Gesh]] ([[User talk:Gesh|talk]]) 18:05, 7 August 2023 (UTC)<br />
<br />
::I meant you could add a [https://www.mediawiki.org/wiki/Help:Links#External_links link] instead of {{ic|<ref>}} which ''technically'' does not work on this wiki. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:12, 7 August 2023 (UTC)<br />
:::How would that help? The entire reason I'm asking for {{ic|<ref>}} is to be able to move the contents of the email I'm citing to a footnote or similarly move it to somewhere where it doesn't dominate the page. Where would I link to? Unless you're suggesting I encode it in a data url or pastebin it, a la [data:text/plain;charset=utf-8;base64,SSB0aGluayB3aGF0IHlvdSdyZSBhc2tpbmcgZm9yIGlzOiBzdG9yZSB0aGUgY29uZmlndXJhdGlvbiBmaWxlIHNvbWV3aGVyZSBvdGhlciB0aGFuIGxpdGVyYWxseSB+Ly54c2NyZWVuc2F2ZXIsIGFuZCBubywgSSdtIG5ldmVyLCBldmVyIGdvaW5nIHRvIGRvIHRoYXQuIEl0IGhhcyB0aG]? Note that even that is unsupported -- wiki only allows linking to {{ic|http(s)}} urls. 08:24, 8 August 2023 (UTC)<br />
<br />
::::That would be a blunt abuse of {{ic|<ref>}} as that is intended for verifiable citations. There is no alternative solution for what you want to do. You need a verifiable source to cite, so either convince upstream to make a public statement or disclose the private communication somewhere (which may be unethical in itself). If you don't want to do it, I suggest you just leave it. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:37, 8 August 2023 (UTC)<br />
:::::Fine, talked with upstream, they didn't want to put in the FAQ, so I guess this will remain undocumented. Too bad. 11:25, 11 August 2023 (UTC)<br />
<br />
== Please don't add hacky solutions ==<br />
<br />
Aliasing {{ic|rm -rf}} tastes like a recipe for disaster. If a program does not support XDG Base Directory, please don't propose hacky workarounds. --[[User:AvidSeeker|AvidSeeker]] ([[User talk:AvidSeeker|talk]]) 06:36, 9 August 2023 (UTC)<br />
<br />
:If the partial support for XDG Base Directories is so broken that the entire workflow collapses without a hacky workaround, then the software doesn't deserve to be in the partial support section under this new rule. But there's no section for software whose partial support is so broken that the support may as well not exist. Since {{AUR|python-filetags}} neither fully nor partially supports XDG Base Directories, but also doesn't hardcode a path, I removed the package from the list entirely.<br />
<br />
:The only reason why my original solution didn't use a hacky workaround is because I fixed the bug in my fork. But [https://github.com/novoid/filetags/pull/56 the fix is currently stuck in PR review limbo]. — [[User:Fedora|Fedora]] ([[User talk:Fedora|talk]]) 07:02, 9 August 2023 (UTC)</div>Geshhttps://wiki.archlinux.org/index.php?title=Talk:XDG_Base_Directory&diff=784718Talk:XDG Base Directory2023-08-08T08:24:14Z<p>Gesh: Reiterate that one cannot link to an email</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 />
::Would it be advised to use symbolic links to manually split such offending programs into their corresponding places? There are a lot of offending packages that store their cache inside the {{ic|$XDG_CONFIG_HOME}} instead of in {{ic|$XDG_CACHE_HOME}}. I noticed a pattern, though. Most of the offenders use Electron, or are Chromium-based browsers... could they be nudged to automatically migrate the data to the corresponding places? [[User:Rolandog|Rolandog]] ([[User talk:Rolandog|talk]]) 12:58, 10 February 2022 (UTC)<br />
<br />
:::To answer your first question, for any use cases I can think of, I wouldn't advise it. For the case of having all of your {{ic|~/.config}} in VCS, replacing the offending configurations with symlinks provides no clear advantage over adding a line to a {{ic|.gitignore}}. In fact, this increases the overhead needed to setup a new system, and some might argue that the complexity added to your hierarchy by having the same files in two locations is also undesirable.<br />
<br />
:::As for the Electron programs, this is an even more egregious abuse of {{ic|$XDG_CACHE_HOME}} than [[User:Alad|Alad]] was referring to. This section was, as I understand it, mainly targeting Qt programs who put human-unreadable, non-configuration state in configuration files. Nevertheless, the same principles apply. Add the offending programs to a {{ic|.gitignore}}. Though most Electron programs indeed share a common structure, I feel like {{ic|.gitignore}} is too primitive to do anything very useful with this information. I think you still be best off blocking entire Electron program config directories manually. Cheers, [[User:CodingKoopa|CodingKoopa]] ([[User talk:CodingKoopa|talk]]) 04:42, 2 March 2022 (UTC)<br />
<br />
:I deleted Chromium from the `partial' list because it abuses the ~.config directory. Unfortunately it had some links. I woudn't put it in the `hardcoded' section though. Maybe we could have an `unsupported' section, to be used when we need to explain why we consider some program unsupported and write there some references? [[User:Tétrapyle|Tétrapyle]] ([[User talk:Tétrapyle|talk]]) 08:59, 20 December 2022 (UTC)<br />
<br />
::Programs like Chromium are not "unsupported" in the same way that programs who use {{ic|$HOME/.''directory''}}, and this should be reflected in their placement. Given how prevalent XDG abuse is, I would honestly put them where they would go anyways, and note the abuse in the ''Notes'' column. The alternatives would unneededly complicate the page by adding another "degree" of support, I think. -- [[User:CodingKoopa|CodingKoopa]] ([[User talk:CodingKoopa|talk]]) 02:22, 25 December 2022 (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 />
::::I for one am not fond of 5 (?!) additional colored columns. It leads to visual overload, there's already enough columns in the table as is. Maybe we can just think of some alternative categories if "partial" is deemed misleading. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:24, 11 November 2021 (UTC)<br />
<br />
::::I question the value add for all the extra fields. Especially as compliance in programs tends to be more nuanced than this allows. For example, many programs make use of {{ic|XDG_CONFIG_HOME}} but debatably fail to correctly follow the standard, mixing state with config, etc. The reality is many developers have different interpretations of the standard which would require far more binary options to capture. I propose a simpler table that doesn't try to over-define abstract values for implementations, and just captures the implementation detail.<br />
::::{| class="wikitable sortable"<br />
! Application<br />
! Official paths<br />
! XDG Base Directory Implementation<br />
! Notes<br />
|-<br />
| Cool-utils<br />
| {{ic|.cool-utils/}}, {{ic|$XDG_CONFIG_HOME/cool-utils/}}<br />
| Uses {{ic|$XDG_CONFIG_DIR}} by default as of 1.2.0.[https://example.com/example/issues/1] Stores extension binaries with config.<br />
| {{-}}<br />
|-<br />
| git-xmonad<br />
| {{ic|.git-xmonad}}<br />
| {{No|http://example.com/bug/1}}<br />
| [http://example.com/bug/1 After legacy]<br />
|-<br />
| Dumper<br />
| {{ic|$XDG_DATA_HOME/dumper/}}<br />
| {{Yes}}<br />
| (an example of a program that always had native support for the standard)<br />
|-<br />
| Hostile-app<br />
| {{ic|.hostileapp/}}<br />
| {{No|[http://example.com/bug/1 WONTFIX]}}<br />
| Workaround: {{ic|1=$ export GARBAGEBIN="$XDG_DATA_HOME"/hostile-app}}<br />
|}<br />
::::[[User:Comic-paralyze-image|Comic-paralyze-image]] ([[User talk:Comic-paralyze-image|talk]]) 15:23, 11 November 2021 (UTC)<br />
<br />
::::More columns are better for people…<br />
::::* maintaining this page<br />
::::* looking to move projects towards supporting XDG more<br />
::::* selecting software based on XDG-support<br />
<br />
::::Fewer columns are better for people…<br />
::::* trying to get their particular piece of software to work better with XDG<br />
<br />
::::That's my current impression.<br />
<br />
::::* I've spent more time as part of the more-columns-group, than I have as part of the fewer-columns-group.<br />
::::* I suspect that much more time is spent by the latter group.<br />
::::* The table should imo still stay readable to people who are seeing it for the 1st time (Cpt. Obvious).<br />
::::* But it would be nice to be able to express and sort by more granularity.<br />
::::* I disagree that more columns automatically make it overwhelming; Wikipedia has a lot of these tables. They've probably put a lot of thought into them, and they're still using them. [[User:Cyethiod|Cyethiod]] ([[User talk:Cyethiod|talk]]) 13:55, 12 November 2021 (UTC)<br />
<br />
:::::It doesn't matter what Wikipedia has or hasn't. Adding 5 columns is an extreme measure to add "more granularity". 1 extra column is fine for me. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:01, 12 November 2021 (UTC)<br />
<br />
::::::I disagree. Most, if not all people who arrive at this ArchWiki-article, have seen Wikipedia pages with tables in them. Both projects even use the same software. Worth mentioning: [[User:Lahwaacz|Lahwaacz]]'s doubt that even Wikipedia has a table as large as those on this page.<br />
<br />
::::::Am I right in thinking that you and I agree on more granularity, but not on the way to achieve it? :) [[User:Cyethiod|Cyethiod]] ([[User talk:Cyethiod|talk]]) 16:18, 12 November 2021 (UTC)<br />
<br />
:::::I doubt that even Wikipedia has a table as large as those on this page... — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:13, 12 November 2021 (UTC)<br />
<br />
::::::Would this serve as a sufficient counter-example? 23 columns (36 rows) - [https://en.wikipedia.org/w/index.php?title=Comparison_of_virtual_reality_headsets&oldid=1052030717#Tethered_VR Comparison of virtual reality headsets #Tethered]. [[User:Cyethiod|Cyethiod]] ([[User talk:Cyethiod|talk]]) 16:12, 12 November 2021 (UTC)<br />
<br />
:::::::That's not nearly as large, since there are over 400 rows in 4 tables on this page. Also none of those 23 columns contains arbitrary-width content like the current "Notes" column here. None of the proposals above removed that column, and one even added another column where arbitrary notes might be added. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:37, 12 November 2021 (UTC)<br />
<br />
:::::For every user on Wikipedia that wants larger, more verbose tables, there are a dozen users that will cite rules about Manual of Style violations, original research, etc. I would not hold Wikipedia articles as a shining example of _the correct way to do something_. If you really want a reference from Wikipedia, I would find a MOS page instead.<br />
:::::In general I am a more-columns person, but having made some effort myself to implement overrides I really think we would need more than six columns to capture **everything** meaningful.<br />
:::::If we wanted more columns, I would suggest following the standard more closely:<br />
:::::{| class="wikitable sortable"<br />
! Application<br />
! Data files<br />
! Configuration files<br />
! State data<br />
! Executable files<br />
! Notes<br />
|-<br />
| Cool-utils<br />
| {{-}}<br />
| {{G|{{ic|$XDG_CONFIG_HOME/cool-utils/}} as of 1.2.0.[https://example.com/example/issues/1]}}<br />
| {{-}}<br />
| {{Y|{{ic|$XDG_CONFIG_HOME/cool-utils/}} Stores extension binaries with config.}}<br />
| {{-}}<br />
|-<br />
| git-xmonad<br />
| {{R|{{ic|.git-xmonad}}[http://example.com/bug/1]}}<br />
| {{R|{{ic|.git-xmonad}}}}<br />
| {{-}}<br />
| {{-}}<br />
| [http://example.com/bug/1 After legacy]<br />
|-<br />
| Dumper<br />
| {{G|{{ic|$XDG_DATA_HOME/dumper/}}}}<br />
| {{G|{{ic|$XDG_CONFIG_HOME/dumper/}}}}<br />
| {{-}}<br />
| {{-}}<br />
| (an example of a program that always had native support for the standard)<br />
|-<br />
| Hostile-app<br />
| {{R|{{ic|.hostileapp/}}[http://example.com/bug/1 WONTFIX]}}<br />
| {{-}}<br />
| {{R|{{ic|.hostileapp/}}}}<br />
| {{R|{{ic|.hostileapp/}}}}<br />
| Workaround: {{ic|1=$ export GARBAGEBIN="$XDG_DATA_HOME"/hostile-app}}<br />
|}<br />
:::::The biggest problem with an extended table like this, is the additional onus on writers to confirm AND AGREE that an implementation is correct. Agreeing on the standard doesn't appear to be easy.<br />
:::::--[[User:Comic-paralyze-image|Comic-paralyze-image]] ([[User talk:Comic-paralyze-image|talk]]) 18:53, 12 November 2021 (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)<br />
<br />
== OpenAL .alsoftrc ==<br />
<br />
i'm pretty sure openal supports xdg base dir since it's in [https://github.com/kcat/openal-soft/blob/9cce3ba/ChangeLog#L587 the changelog], but i don't want to contribute it myself since i don't know how to actually test if what i do is correct.<br />
every other archwiki page i've seen (such as [[Gaming#Binaural_audio_with_OpenAL]]) only mentions {{ic|~/.alsoftrc}}.<br />
can someone help figure out the situation with openal?<br />
<br />
[[User:SArpnt|SArpnt]] ([[User talk:SArpnt|talk]]) 23:32, 5 November 2022 (UTC)<br />
<br />
: [https://github.com/kcat/openal-soft/blob/0526ecd2f95877b167293e50ab8ce0ce614d03f4/alc/alconfig.cpp#L365 {{ic|ReadALConfig()}} in alconfig.cpp] searches xdg paths in addition to legacy ({{ic|~/.alsoftrc}} and {{ic|/etc/alsoft.conf}} so I'll add it to "supported" [[User:wowaname|<span style="color:#f7f">wowaname</span>]] [[User talk:wowaname|<span style="color:#f80">#</span>]] [[Special:Contributions/wowaname|<span style="color:#f80">C</span>]] 22:02, 14 February 2023 (UTC)<br />
<br />
== Adding references to developer communication unavailable on web ==<br />
<br />
Talked to {{ic|xscreensaver}} upstream re XDG, they clearly communicated WONTFIX.<br />
However, since they don't use a bugtracker and instead only communicate via direct email,<br />
there is no webpage to link to.<br />
ATM, just copied their response into the table -- {{ic|<ref>}} doesn't appear to work there.<br />
However, this is clearly suboptimal -- is there a better way of doing this?<br />
[[User:Gesh|Gesh]] ([[User talk:Gesh|talk]]) 10:10, 6 August 2023 (UTC)<br />
<br />
:You can just add a link. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:22, 6 August 2023 (UTC)<br />
<br />
:Am confused. I just spent the entire paragraph above explaining why there is no page to link to -- only an email by upstream to me where they expressed their strong objection to changing the situation. I guess you _could_ bug upstream to add an entry to the FAQ, but I'd rather not prod them for that myself, given the vehemence of the objection (I gather it might be a bit of a sore spot).<br />
:In case my edit is restored, further communication from upstream yesterday (2023-08-06) seems to confirm invoking {{ic|xscreensaver}} with {{ic|HOME{{=}}$XDG_CONFIG_HOME/xscreensaver/}} should work (referring to {{ic|~/.xscreensaver}}) {{bc|Both xscreensaver and xscreensaver-settings use that file and communicate with each other through it. xscreensaver-text, xscreensaver-getimage-file and vidwhacker also read it. xscreensaver-getimage-file and mapscroller.pl use FreeDesktop locations for cache files if those directories exist.}}[[User:Gesh|Gesh]] ([[User talk:Gesh|talk]]) 18:05, 7 August 2023 (UTC)<br />
<br />
::I meant you could add a [https://www.mediawiki.org/wiki/Help:Links#External_links link] instead of {{ic|<ref>}} which ''technically'' does not work on this wiki. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:12, 7 August 2023 (UTC)<br />
:::How would that help? The entire reason I'm asking for {{ic|<ref>}} is to be able to move the contents of the email I'm citing to a footnote or similarly move it to somewhere where it doesn't dominate the page. Where would I link to? Unless you're suggesting I encode it in a data url or pastebin it, a la [data:text/plain;charset=utf-8;base64,SSB0aGluayB3aGF0IHlvdSdyZSBhc2tpbmcgZm9yIGlzOiBzdG9yZSB0aGUgY29uZmlndXJhdGlvbiBmaWxlIHNvbWV3aGVyZSBvdGhlciB0aGFuIGxpdGVyYWxseSB+Ly54c2NyZWVuc2F2ZXIsIGFuZCBubywgSSdtIG5ldmVyLCBldmVyIGdvaW5nIHRvIGRvIHRoYXQuIEl0IGhhcyB0aG]? Note that even that is unsupported -- wiki only allows linking to {{ic|http(s)}} urls. 08:24, 8 August 2023 (UTC)</div>Geshhttps://wiki.archlinux.org/index.php?title=Talk:XDG_Base_Directory&diff=784698Talk:XDG Base Directory2023-08-07T18:06:11Z<p>Gesh: Clarify that no upstream page exists to refer to</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 />
::Would it be advised to use symbolic links to manually split such offending programs into their corresponding places? There are a lot of offending packages that store their cache inside the {{ic|$XDG_CONFIG_HOME}} instead of in {{ic|$XDG_CACHE_HOME}}. I noticed a pattern, though. Most of the offenders use Electron, or are Chromium-based browsers... could they be nudged to automatically migrate the data to the corresponding places? [[User:Rolandog|Rolandog]] ([[User talk:Rolandog|talk]]) 12:58, 10 February 2022 (UTC)<br />
<br />
:::To answer your first question, for any use cases I can think of, I wouldn't advise it. For the case of having all of your {{ic|~/.config}} in VCS, replacing the offending configurations with symlinks provides no clear advantage over adding a line to a {{ic|.gitignore}}. In fact, this increases the overhead needed to setup a new system, and some might argue that the complexity added to your hierarchy by having the same files in two locations is also undesirable.<br />
<br />
:::As for the Electron programs, this is an even more egregious abuse of {{ic|$XDG_CACHE_HOME}} than [[User:Alad|Alad]] was referring to. This section was, as I understand it, mainly targeting Qt programs who put human-unreadable, non-configuration state in configuration files. Nevertheless, the same principles apply. Add the offending programs to a {{ic|.gitignore}}. Though most Electron programs indeed share a common structure, I feel like {{ic|.gitignore}} is too primitive to do anything very useful with this information. I think you still be best off blocking entire Electron program config directories manually. Cheers, [[User:CodingKoopa|CodingKoopa]] ([[User talk:CodingKoopa|talk]]) 04:42, 2 March 2022 (UTC)<br />
<br />
:I deleted Chromium from the `partial' list because it abuses the ~.config directory. Unfortunately it had some links. I woudn't put it in the `hardcoded' section though. Maybe we could have an `unsupported' section, to be used when we need to explain why we consider some program unsupported and write there some references? [[User:Tétrapyle|Tétrapyle]] ([[User talk:Tétrapyle|talk]]) 08:59, 20 December 2022 (UTC)<br />
<br />
::Programs like Chromium are not "unsupported" in the same way that programs who use {{ic|$HOME/.''directory''}}, and this should be reflected in their placement. Given how prevalent XDG abuse is, I would honestly put them where they would go anyways, and note the abuse in the ''Notes'' column. The alternatives would unneededly complicate the page by adding another "degree" of support, I think. -- [[User:CodingKoopa|CodingKoopa]] ([[User talk:CodingKoopa|talk]]) 02:22, 25 December 2022 (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 />
::::I for one am not fond of 5 (?!) additional colored columns. It leads to visual overload, there's already enough columns in the table as is. Maybe we can just think of some alternative categories if "partial" is deemed misleading. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:24, 11 November 2021 (UTC)<br />
<br />
::::I question the value add for all the extra fields. Especially as compliance in programs tends to be more nuanced than this allows. For example, many programs make use of {{ic|XDG_CONFIG_HOME}} but debatably fail to correctly follow the standard, mixing state with config, etc. The reality is many developers have different interpretations of the standard which would require far more binary options to capture. I propose a simpler table that doesn't try to over-define abstract values for implementations, and just captures the implementation detail.<br />
::::{| class="wikitable sortable"<br />
! Application<br />
! Official paths<br />
! XDG Base Directory Implementation<br />
! Notes<br />
|-<br />
| Cool-utils<br />
| {{ic|.cool-utils/}}, {{ic|$XDG_CONFIG_HOME/cool-utils/}}<br />
| Uses {{ic|$XDG_CONFIG_DIR}} by default as of 1.2.0.[https://example.com/example/issues/1] Stores extension binaries with config.<br />
| {{-}}<br />
|-<br />
| git-xmonad<br />
| {{ic|.git-xmonad}}<br />
| {{No|http://example.com/bug/1}}<br />
| [http://example.com/bug/1 After legacy]<br />
|-<br />
| Dumper<br />
| {{ic|$XDG_DATA_HOME/dumper/}}<br />
| {{Yes}}<br />
| (an example of a program that always had native support for the standard)<br />
|-<br />
| Hostile-app<br />
| {{ic|.hostileapp/}}<br />
| {{No|[http://example.com/bug/1 WONTFIX]}}<br />
| Workaround: {{ic|1=$ export GARBAGEBIN="$XDG_DATA_HOME"/hostile-app}}<br />
|}<br />
::::[[User:Comic-paralyze-image|Comic-paralyze-image]] ([[User talk:Comic-paralyze-image|talk]]) 15:23, 11 November 2021 (UTC)<br />
<br />
::::More columns are better for people…<br />
::::* maintaining this page<br />
::::* looking to move projects towards supporting XDG more<br />
::::* selecting software based on XDG-support<br />
<br />
::::Fewer columns are better for people…<br />
::::* trying to get their particular piece of software to work better with XDG<br />
<br />
::::That's my current impression.<br />
<br />
::::* I've spent more time as part of the more-columns-group, than I have as part of the fewer-columns-group.<br />
::::* I suspect that much more time is spent by the latter group.<br />
::::* The table should imo still stay readable to people who are seeing it for the 1st time (Cpt. Obvious).<br />
::::* But it would be nice to be able to express and sort by more granularity.<br />
::::* I disagree that more columns automatically make it overwhelming; Wikipedia has a lot of these tables. They've probably put a lot of thought into them, and they're still using them. [[User:Cyethiod|Cyethiod]] ([[User talk:Cyethiod|talk]]) 13:55, 12 November 2021 (UTC)<br />
<br />
:::::It doesn't matter what Wikipedia has or hasn't. Adding 5 columns is an extreme measure to add "more granularity". 1 extra column is fine for me. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:01, 12 November 2021 (UTC)<br />
<br />
::::::I disagree. Most, if not all people who arrive at this ArchWiki-article, have seen Wikipedia pages with tables in them. Both projects even use the same software. Worth mentioning: [[User:Lahwaacz|Lahwaacz]]'s doubt that even Wikipedia has a table as large as those on this page.<br />
<br />
::::::Am I right in thinking that you and I agree on more granularity, but not on the way to achieve it? :) [[User:Cyethiod|Cyethiod]] ([[User talk:Cyethiod|talk]]) 16:18, 12 November 2021 (UTC)<br />
<br />
:::::I doubt that even Wikipedia has a table as large as those on this page... — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:13, 12 November 2021 (UTC)<br />
<br />
::::::Would this serve as a sufficient counter-example? 23 columns (36 rows) - [https://en.wikipedia.org/w/index.php?title=Comparison_of_virtual_reality_headsets&oldid=1052030717#Tethered_VR Comparison of virtual reality headsets #Tethered]. [[User:Cyethiod|Cyethiod]] ([[User talk:Cyethiod|talk]]) 16:12, 12 November 2021 (UTC)<br />
<br />
:::::::That's not nearly as large, since there are over 400 rows in 4 tables on this page. Also none of those 23 columns contains arbitrary-width content like the current "Notes" column here. None of the proposals above removed that column, and one even added another column where arbitrary notes might be added. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:37, 12 November 2021 (UTC)<br />
<br />
:::::For every user on Wikipedia that wants larger, more verbose tables, there are a dozen users that will cite rules about Manual of Style violations, original research, etc. I would not hold Wikipedia articles as a shining example of _the correct way to do something_. If you really want a reference from Wikipedia, I would find a MOS page instead.<br />
:::::In general I am a more-columns person, but having made some effort myself to implement overrides I really think we would need more than six columns to capture **everything** meaningful.<br />
:::::If we wanted more columns, I would suggest following the standard more closely:<br />
:::::{| class="wikitable sortable"<br />
! Application<br />
! Data files<br />
! Configuration files<br />
! State data<br />
! Executable files<br />
! Notes<br />
|-<br />
| Cool-utils<br />
| {{-}}<br />
| {{G|{{ic|$XDG_CONFIG_HOME/cool-utils/}} as of 1.2.0.[https://example.com/example/issues/1]}}<br />
| {{-}}<br />
| {{Y|{{ic|$XDG_CONFIG_HOME/cool-utils/}} Stores extension binaries with config.}}<br />
| {{-}}<br />
|-<br />
| git-xmonad<br />
| {{R|{{ic|.git-xmonad}}[http://example.com/bug/1]}}<br />
| {{R|{{ic|.git-xmonad}}}}<br />
| {{-}}<br />
| {{-}}<br />
| [http://example.com/bug/1 After legacy]<br />
|-<br />
| Dumper<br />
| {{G|{{ic|$XDG_DATA_HOME/dumper/}}}}<br />
| {{G|{{ic|$XDG_CONFIG_HOME/dumper/}}}}<br />
| {{-}}<br />
| {{-}}<br />
| (an example of a program that always had native support for the standard)<br />
|-<br />
| Hostile-app<br />
| {{R|{{ic|.hostileapp/}}[http://example.com/bug/1 WONTFIX]}}<br />
| {{-}}<br />
| {{R|{{ic|.hostileapp/}}}}<br />
| {{R|{{ic|.hostileapp/}}}}<br />
| Workaround: {{ic|1=$ export GARBAGEBIN="$XDG_DATA_HOME"/hostile-app}}<br />
|}<br />
:::::The biggest problem with an extended table like this, is the additional onus on writers to confirm AND AGREE that an implementation is correct. Agreeing on the standard doesn't appear to be easy.<br />
:::::--[[User:Comic-paralyze-image|Comic-paralyze-image]] ([[User talk:Comic-paralyze-image|talk]]) 18:53, 12 November 2021 (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)<br />
<br />
== OpenAL .alsoftrc ==<br />
<br />
i'm pretty sure openal supports xdg base dir since it's in [https://github.com/kcat/openal-soft/blob/9cce3ba/ChangeLog#L587 the changelog], but i don't want to contribute it myself since i don't know how to actually test if what i do is correct.<br />
every other archwiki page i've seen (such as [[Gaming#Binaural_audio_with_OpenAL]]) only mentions {{ic|~/.alsoftrc}}.<br />
can someone help figure out the situation with openal?<br />
<br />
[[User:SArpnt|SArpnt]] ([[User talk:SArpnt|talk]]) 23:32, 5 November 2022 (UTC)<br />
<br />
: [https://github.com/kcat/openal-soft/blob/0526ecd2f95877b167293e50ab8ce0ce614d03f4/alc/alconfig.cpp#L365 {{ic|ReadALConfig()}} in alconfig.cpp] searches xdg paths in addition to legacy ({{ic|~/.alsoftrc}} and {{ic|/etc/alsoft.conf}} so I'll add it to "supported" [[User:wowaname|<span style="color:#f7f">wowaname</span>]] [[User talk:wowaname|<span style="color:#f80">#</span>]] [[Special:Contributions/wowaname|<span style="color:#f80">C</span>]] 22:02, 14 February 2023 (UTC)<br />
<br />
== Adding references to developer communication unavailable on web ==<br />
<br />
Talked to {{ic|xscreensaver}} upstream re XDG, they clearly communicated WONTFIX.<br />
However, since they don't use a bugtracker and instead only communicate via direct email,<br />
there is no webpage to link to.<br />
ATM, just copied their response into the table -- {{ic|<ref>}} doesn't appear to work there.<br />
However, this is clearly suboptimal -- is there a better way of doing this?<br />
[[User:Gesh|Gesh]] ([[User talk:Gesh|talk]]) 10:10, 6 August 2023 (UTC)<br />
<br />
:You can just add a link. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:22, 6 August 2023 (UTC)<br />
<br />
:Am confused. I just spent the entire paragraph above explaining why there is no page to link to -- only an email by upstream to me where they expressed their strong objection to changing the situation. I guess you _could_ bug upstream to add an entry to the FAQ, but I'd rather not prod them for that myself, given the vehemence of the objection (I gather it might be a bit of a sore spot).<br />
:In case my edit is restored, further communication from upstream yesterday (2023-08-06) seems to confirm invoking {{ic|xscreensaver}} with {{ic|HOME{{=}}$XDG_CONFIG_HOME/xscreensaver/}} should work (referring to {{ic|~/.xscreensaver}}) {{bc|Both xscreensaver and xscreensaver-settings use that file and communicate with each other through it. xscreensaver-text, xscreensaver-getimage-file and vidwhacker also read it. xscreensaver-getimage-file and mapscroller.pl use FreeDesktop locations for cache files if those directories exist.}}[[User:Gesh|Gesh]] ([[User talk:Gesh|talk]]) 18:05, 7 August 2023 (UTC)</div>Geshhttps://wiki.archlinux.org/index.php?title=Talk:XDG_Base_Directory&diff=784627Talk:XDG Base Directory2023-08-06T10:10:57Z<p>Gesh: /* Adding references to developer communication unavailable on web */ 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 />
::Would it be advised to use symbolic links to manually split such offending programs into their corresponding places? There are a lot of offending packages that store their cache inside the {{ic|$XDG_CONFIG_HOME}} instead of in {{ic|$XDG_CACHE_HOME}}. I noticed a pattern, though. Most of the offenders use Electron, or are Chromium-based browsers... could they be nudged to automatically migrate the data to the corresponding places? [[User:Rolandog|Rolandog]] ([[User talk:Rolandog|talk]]) 12:58, 10 February 2022 (UTC)<br />
<br />
:::To answer your first question, for any use cases I can think of, I wouldn't advise it. For the case of having all of your {{ic|~/.config}} in VCS, replacing the offending configurations with symlinks provides no clear advantage over adding a line to a {{ic|.gitignore}}. In fact, this increases the overhead needed to setup a new system, and some might argue that the complexity added to your hierarchy by having the same files in two locations is also undesirable.<br />
<br />
:::As for the Electron programs, this is an even more egregious abuse of {{ic|$XDG_CACHE_HOME}} than [[User:Alad|Alad]] was referring to. This section was, as I understand it, mainly targeting Qt programs who put human-unreadable, non-configuration state in configuration files. Nevertheless, the same principles apply. Add the offending programs to a {{ic|.gitignore}}. Though most Electron programs indeed share a common structure, I feel like {{ic|.gitignore}} is too primitive to do anything very useful with this information. I think you still be best off blocking entire Electron program config directories manually. Cheers, [[User:CodingKoopa|CodingKoopa]] ([[User talk:CodingKoopa|talk]]) 04:42, 2 March 2022 (UTC)<br />
<br />
:I deleted Chromium from the `partial' list because it abuses the ~.config directory. Unfortunately it had some links. I woudn't put it in the `hardcoded' section though. Maybe we could have an `unsupported' section, to be used when we need to explain why we consider some program unsupported and write there some references? [[User:Tétrapyle|Tétrapyle]] ([[User talk:Tétrapyle|talk]]) 08:59, 20 December 2022 (UTC)<br />
<br />
::Programs like Chromium are not "unsupported" in the same way that programs who use {{ic|$HOME/.''directory''}}, and this should be reflected in their placement. Given how prevalent XDG abuse is, I would honestly put them where they would go anyways, and note the abuse in the ''Notes'' column. The alternatives would unneededly complicate the page by adding another "degree" of support, I think. -- [[User:CodingKoopa|CodingKoopa]] ([[User talk:CodingKoopa|talk]]) 02:22, 25 December 2022 (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 />
::::I for one am not fond of 5 (?!) additional colored columns. It leads to visual overload, there's already enough columns in the table as is. Maybe we can just think of some alternative categories if "partial" is deemed misleading. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:24, 11 November 2021 (UTC)<br />
<br />
::::I question the value add for all the extra fields. Especially as compliance in programs tends to be more nuanced than this allows. For example, many programs make use of {{ic|XDG_CONFIG_HOME}} but debatably fail to correctly follow the standard, mixing state with config, etc. The reality is many developers have different interpretations of the standard which would require far more binary options to capture. I propose a simpler table that doesn't try to over-define abstract values for implementations, and just captures the implementation detail.<br />
::::{| class="wikitable sortable"<br />
! Application<br />
! Official paths<br />
! XDG Base Directory Implementation<br />
! Notes<br />
|-<br />
| Cool-utils<br />
| {{ic|.cool-utils/}}, {{ic|$XDG_CONFIG_HOME/cool-utils/}}<br />
| Uses {{ic|$XDG_CONFIG_DIR}} by default as of 1.2.0.[https://example.com/example/issues/1] Stores extension binaries with config.<br />
| {{-}}<br />
|-<br />
| git-xmonad<br />
| {{ic|.git-xmonad}}<br />
| {{No|http://example.com/bug/1}}<br />
| [http://example.com/bug/1 After legacy]<br />
|-<br />
| Dumper<br />
| {{ic|$XDG_DATA_HOME/dumper/}}<br />
| {{Yes}}<br />
| (an example of a program that always had native support for the standard)<br />
|-<br />
| Hostile-app<br />
| {{ic|.hostileapp/}}<br />
| {{No|[http://example.com/bug/1 WONTFIX]}}<br />
| Workaround: {{ic|1=$ export GARBAGEBIN="$XDG_DATA_HOME"/hostile-app}}<br />
|}<br />
::::[[User:Comic-paralyze-image|Comic-paralyze-image]] ([[User talk:Comic-paralyze-image|talk]]) 15:23, 11 November 2021 (UTC)<br />
<br />
::::More columns are better for people…<br />
::::* maintaining this page<br />
::::* looking to move projects towards supporting XDG more<br />
::::* selecting software based on XDG-support<br />
<br />
::::Fewer columns are better for people…<br />
::::* trying to get their particular piece of software to work better with XDG<br />
<br />
::::That's my current impression.<br />
<br />
::::* I've spent more time as part of the more-columns-group, than I have as part of the fewer-columns-group.<br />
::::* I suspect that much more time is spent by the latter group.<br />
::::* The table should imo still stay readable to people who are seeing it for the 1st time (Cpt. Obvious).<br />
::::* But it would be nice to be able to express and sort by more granularity.<br />
::::* I disagree that more columns automatically make it overwhelming; Wikipedia has a lot of these tables. They've probably put a lot of thought into them, and they're still using them. [[User:Cyethiod|Cyethiod]] ([[User talk:Cyethiod|talk]]) 13:55, 12 November 2021 (UTC)<br />
<br />
:::::It doesn't matter what Wikipedia has or hasn't. Adding 5 columns is an extreme measure to add "more granularity". 1 extra column is fine for me. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:01, 12 November 2021 (UTC)<br />
<br />
::::::I disagree. Most, if not all people who arrive at this ArchWiki-article, have seen Wikipedia pages with tables in them. Both projects even use the same software. Worth mentioning: [[User:Lahwaacz|Lahwaacz]]'s doubt that even Wikipedia has a table as large as those on this page.<br />
<br />
::::::Am I right in thinking that you and I agree on more granularity, but not on the way to achieve it? :) [[User:Cyethiod|Cyethiod]] ([[User talk:Cyethiod|talk]]) 16:18, 12 November 2021 (UTC)<br />
<br />
:::::I doubt that even Wikipedia has a table as large as those on this page... — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:13, 12 November 2021 (UTC)<br />
<br />
::::::Would this serve as a sufficient counter-example? 23 columns (36 rows) - [https://en.wikipedia.org/w/index.php?title=Comparison_of_virtual_reality_headsets&oldid=1052030717#Tethered_VR Comparison of virtual reality headsets #Tethered]. [[User:Cyethiod|Cyethiod]] ([[User talk:Cyethiod|talk]]) 16:12, 12 November 2021 (UTC)<br />
<br />
:::::::That's not nearly as large, since there are over 400 rows in 4 tables on this page. Also none of those 23 columns contains arbitrary-width content like the current "Notes" column here. None of the proposals above removed that column, and one even added another column where arbitrary notes might be added. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:37, 12 November 2021 (UTC)<br />
<br />
:::::For every user on Wikipedia that wants larger, more verbose tables, there are a dozen users that will cite rules about Manual of Style violations, original research, etc. I would not hold Wikipedia articles as a shining example of _the correct way to do something_. If you really want a reference from Wikipedia, I would find a MOS page instead.<br />
:::::In general I am a more-columns person, but having made some effort myself to implement overrides I really think we would need more than six columns to capture **everything** meaningful.<br />
:::::If we wanted more columns, I would suggest following the standard more closely:<br />
:::::{| class="wikitable sortable"<br />
! Application<br />
! Data files<br />
! Configuration files<br />
! State data<br />
! Executable files<br />
! Notes<br />
|-<br />
| Cool-utils<br />
| {{-}}<br />
| {{G|{{ic|$XDG_CONFIG_HOME/cool-utils/}} as of 1.2.0.[https://example.com/example/issues/1]}}<br />
| {{-}}<br />
| {{Y|{{ic|$XDG_CONFIG_HOME/cool-utils/}} Stores extension binaries with config.}}<br />
| {{-}}<br />
|-<br />
| git-xmonad<br />
| {{R|{{ic|.git-xmonad}}[http://example.com/bug/1]}}<br />
| {{R|{{ic|.git-xmonad}}}}<br />
| {{-}}<br />
| {{-}}<br />
| [http://example.com/bug/1 After legacy]<br />
|-<br />
| Dumper<br />
| {{G|{{ic|$XDG_DATA_HOME/dumper/}}}}<br />
| {{G|{{ic|$XDG_CONFIG_HOME/dumper/}}}}<br />
| {{-}}<br />
| {{-}}<br />
| (an example of a program that always had native support for the standard)<br />
|-<br />
| Hostile-app<br />
| {{R|{{ic|.hostileapp/}}[http://example.com/bug/1 WONTFIX]}}<br />
| {{-}}<br />
| {{R|{{ic|.hostileapp/}}}}<br />
| {{R|{{ic|.hostileapp/}}}}<br />
| Workaround: {{ic|1=$ export GARBAGEBIN="$XDG_DATA_HOME"/hostile-app}}<br />
|}<br />
:::::The biggest problem with an extended table like this, is the additional onus on writers to confirm AND AGREE that an implementation is correct. Agreeing on the standard doesn't appear to be easy.<br />
:::::--[[User:Comic-paralyze-image|Comic-paralyze-image]] ([[User talk:Comic-paralyze-image|talk]]) 18:53, 12 November 2021 (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)<br />
<br />
== OpenAL .alsoftrc ==<br />
<br />
i'm pretty sure openal supports xdg base dir since it's in [https://github.com/kcat/openal-soft/blob/9cce3ba/ChangeLog#L587 the changelog], but i don't want to contribute it myself since i don't know how to actually test if what i do is correct.<br />
every other archwiki page i've seen (such as [[Gaming#Binaural_audio_with_OpenAL]]) only mentions {{ic|~/.alsoftrc}}.<br />
can someone help figure out the situation with openal?<br />
<br />
[[User:SArpnt|SArpnt]] ([[User talk:SArpnt|talk]]) 23:32, 5 November 2022 (UTC)<br />
<br />
: [https://github.com/kcat/openal-soft/blob/0526ecd2f95877b167293e50ab8ce0ce614d03f4/alc/alconfig.cpp#L365 {{ic|ReadALConfig()}} in alconfig.cpp] searches xdg paths in addition to legacy ({{ic|~/.alsoftrc}} and {{ic|/etc/alsoft.conf}} so I'll add it to "supported" [[User:wowaname|<span style="color:#f7f">wowaname</span>]] [[User talk:wowaname|<span style="color:#f80">#</span>]] [[Special:Contributions/wowaname|<span style="color:#f80">C</span>]] 22:02, 14 February 2023 (UTC)<br />
<br />
== Adding references to developer communication unavailable on web ==<br />
<br />
Talked to {{ic|xscreensaver}} upstream re XDG, they clearly communicated WONTFIX.<br />
However, since they don't use a bugtracker and instead only communicate via direct email,<br />
there is no webpage to link to.<br />
ATM, just copied their response into the table -- {{ic|<ref>}} doesn't appear to work there.<br />
However, this is clearly suboptimal -- is there a better way of doing this?<br />
[[User:Gesh|Gesh]] ([[User talk:Gesh|talk]]) 10:10, 6 August 2023 (UTC)</div>Geshhttps://wiki.archlinux.org/index.php?title=XDG_Base_Directory&diff=784625XDG Base Directory2023-08-06T10:07:35Z<p>Gesh: Add xscreensaver situation</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 {{man|8|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|atuin}}<br />
| {{ic|~/.config/atuin}} {{ic|~/.local/share/atuin}}<br />
| [https://github.com/ellie/atuin/commit/156893d774b4da5b541fdbb08428f9ec392949a0 156893d]<br />
|<br />
|<br />
XDG_CONFIG_HOME/atuin/config.toml<br />
XDG_DATA_HOME/atuin/history.db<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 />
| Uses new locations if legacy do not exist:<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 />
| [[CUPS]]<br />
| {{ic|~/.cups/}}<br />
| [https://github.com/OpenPrinting/libcups/pull/45/commits/23b1be68803128ed701d374981c4583bcf9e7bf6 23b1be6]<br />
| [https://github.com/OpenPrinting/cups/issues/10]<br />
| <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 />
| {{Pkg|hunspell}}<br />
| {{ic|~/.hunspell_default.}}<br />
| <br />
| [https://github.com/hunspell/hunspell/pull/637]<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}}{{Broken package link|replaced by {{Pkg|texlive-basic}}}})<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://hg.mozilla.org/projects/nss/rev/da45424cb9a0b4d8e45e5040e2e3b574d994e254 3.42 (da45424)]<br />
| [https://bugzilla.mozilla.org/show_bug.cgi?id=818686]<br />
|<br />
|-<br />
| [[Haskell#Stack]]<br />
| {{ic|~/.stack}}<br />
| [https://github.com/commercialhaskell/stack/releases/tag/v2.9.3 2.9.3]<br />
| [https://github.com/commercialhaskell/stack/issues/4243]<br />
| Defaults to legacy. Use {{ic|1=export STACK_XDG=1}} to make it compliant with the spec.<br />
The old method of {{ic|1=export STACK_ROOT="$XDG_DATA_HOME"/stack}} still works and takes priority [https://docs.haskellstack.org/en/stable/environment_variables/#stack_xdg].<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 />
| {{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-pipx}}<br />
| {{ic|~/.local/pipx}}<br />
| [https://github.com/pypa/pipx/pull/1001 c3d8de9]<br />
| [https://github.com/pypa/pipx/issues/722]<br />
| For compatibility, pipx will revert to {{ic|~/.local/pipx}} if it exists. Implemented using {{Pkg|python-platformdirs}}<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://code.videolan.org/videolan/vlc/-/commit/16f32e1500887c0dcd33cb06ad71759a81a52878 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]{{Dead link|2023|05|06|status=404}}<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 />
$XDG_CONFIG_HOME/zim/preferences.conf<br />
$XDG_CONFIG_HOME/zim/notebooks.list<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 />
The remote's {{ic|~/.ansible/tmp}} can be moved by setting {{ic|1=remote_tmp = ${XDG_CONFIG_HOME}/ansible/tmp}} in an appropriate {{ic|ansible.cfg}}. [https://docs.ansible.com/archive/ansible/2.4/intro_configuration.html#remote-tmp] [https://github.com/ayekat/localdir/issues/7#issuecomment-998286490]<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://gitlab.archlinux.org/archlinux/packaging/packages/cataclysm-dda/-/commit/0947de440817c9c418cac615275edbf1cc0abdbb 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 />
| Deliberatly (according to these sources) clobbers {{ic|~/.config}} by writing hundreds of megabytes of '''cache''' data into it. Quite unsupported.<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 />
| [[discord]]<br />
| {{ic|1=${XDG_CONFIG_HOME}/discord}}<br />
|<br />
| <br />
| As of version 0.0.27:<br />
Undocumented, though actively used:<br />
{{ic|1=export DISCORD_USER_DATA_DIR="${XDG_DATA_HOME}"}}<br />
<br />
Source: {{ic|1=<discord_system_package_root>/resources/app.asar}}.<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|python-filetags}}<br />
| {{ic|~/.filetags_tagfilter}}<br />
|<br />
| [https://github.com/novoid/filetags/issues/57]<br />
| {{ic|1=alias filetags="filetags --tagtrees-dir ${XDG_STATE_HOME:-$HOME/.local/state}/filetags"}}<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 />
[https://github.com/gradle/gradle/issues/8262]<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/3.2.2/stdlibs/irb/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 />
| {{Pkg|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 />
| {{AUR|python-easyocr}}<br />
| {{ic|~/.EasyOCR}}<br />
| <br />
|<br />
| {{ic|1=export EASYOCR_MODULE_PATH="$XDG_CONFIG_HOME/EasyOCR"}}<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/platform/PlatformUtils-posix.cc#L105 hard-codes] {{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 />
| {{AUR|platformio}}<br />
| {{ic|~/.platformio}}<br />
|<br />
| [https://github.com/platformio/platformio-core/issues/2872]<br />
| {{ic|1=export PLATFORMIO_CORE_DIR="$XDG_DATA_HOME"/platformio}}<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}}{{Broken package link|package not found}}<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 />
| {{Pkg|ruff}}<br />
| {{ic|.ruff_cache}}<br />
|<br />
| [https://github.com/charliermarsh/ruff/issues/1292]<br />
| {{ic|1=export RUFF_CACHE_DIR=$XDG_CACHE_HOME/ruff}}<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 />
| {{AUR|singularity-ce}}<br />
| {{ic|~/.singularity}}<br />
| [https://github.com/sylabs/singularity/releases/tag/v3.11.4 3.11.4]<br />
| <br />
| {{ic|1=export SINGULARITY_CONFIGDIR="$XDG_CONFIG_HOME/singularity"}}, {{ic|1=export SINGULARITY_CACHEDIR="$XDG_CACHE_HOME/singularity"}}<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 />
| {{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 />
| {{Pkg|cmus}}<br />
| {{ic|~/.config/cmus}}<br />
| [https://github.com/cmus/cmus/pull/69]<br />
| [https://github.com/cmus/cmus/issues/1283]<br />
| <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 />
| [https://man.archlinux.org/man/dig.1 dig]<br />
| {{ic|~/.digrc}}<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 />
| {{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}} (repo was deleted)<br />
| Added in [https://repo.or.cz/w/llpp.git/commit/3ab86f0 3ab86f0] but subsequently reverted in [https://repo.or.cz/w/llpp.git/commit/e253c9f1 old:e253c9f1]/[https://github.com/criticic/llpp/commit/e253c9f1ca971b4298cfee889820ad60bded54af new:e253c9f1]<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 />
| {{AUR|jitsi-meet}}<br />
| {{ic|~/Downloads}}<br />
| [https://github.com/jitsi/libjitsi/issues/518 libjitsi#518]<br />
| Download dir hardcoded to {{ic|~/Downloads}} rather than {{ic|XDG_DOWNLOAD_DIR}} (from [[XDG user directories]])<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 />
| {{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 />
| {{ic|1=export KUBECONFIG="$XDG_CONFIG_HOME/kube"}}<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 />
| [[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 />
|-<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 />
| [[R]]<br />
| {{ic|~/.Rprofile, ~/.Rdata, ~/.Rhistory}}<br />
| <br />
| <br />
R_HOME_USER="$HOME/.config/R"<br />
R_PROFILE_USER="$HOME/.config/R/profile"<br />
R_HISTFILE="$HOME/.config/R/history"<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 />
| [[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|stremio}}<br />
| {{ic|~/.stremio-server/|}}<br />
| [https://github.com/Stremio/stremio-features/issues/268]<br />
|<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://jorengarenar.github.io/blog/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 />
| [[xscreensaver]]<br />
| {{ic|~/.xscreensaver}}<br />
| Personal communication 2023-08-04: "I think what you're asking for is: store the configuration file somewhere other than literally ~/.xscreensaver, and no, I'm never, ever going to do that. It has the potential to break too many things, and for *absoutely no* tangible benefit of any kind."<br />
| Since the only file {{ic|xscreensaver}} touches under {{ic|HOME}} is {{ic|~/.xscreensaver}}, it should be safe to move it and call {{ic|xscreensaver}} with {{ic|HOME}} pointing to the appropriate place under {{ic|XDG_CONFIG_HOME}}<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 />
: [https://github.com/ActiveState/appdirs appdirs] (abandoned)<br />
: [https://github.com/platformdirs/platformdirs platformdirs]<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 />
== Tips and tricks ==<br />
<br />
=== Hiding unwanted directories ===<br />
<br />
For directories which cannot be relocated, some desktop environments such as [[KDE]] allow you to hide them:<br />
<br />
$ echo ''path'' >> ~/.hidden<br />
<br />
''path'' is the path of the file/directory, relative to the parent directory of {{ic|.hidden}}.<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>Geshhttps://wiki.archlinux.org/index.php?title=Talk:Pacman/Tips_and_tricks&diff=700433Talk:Pacman/Tips and tricks2021-11-01T01:23:29Z<p>Gesh: Note implication of paccache options</p>
<hr />
<div>== Leading slash ==<br />
<br />
[[Pacman/Tips_and_tricks#aria2]] doesn't work without leading slash, i.e. {{ic|-d /}} turning file names to {{ic|//var/cache/...}}. The article mentions this, but it doesn't mention why. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 05:28, 16 October 2015 (UTC)<br />
<br />
:You would have to go [https://wiki.archlinux.org/index.php?title=Improve_pacman_performance&diff=32104&oldid=30674 way] [https://wiki.archlinux.org/index.php?title=Improve_pacman_performance&diff=next&oldid=115292 back] to track this. It seems to have worked without {{ic|-d /}} even in 2006: [https://wiki.archlinux.org/index.php?title=Faster_Pacman_Downloads&oldid=15627], [https://wiki.archlinux.org/index.php?title=Improve_pacman_performance&oldid=17759]. <s>I guess that simply nobody asked the right question...</s> -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:30, 16 October 2015 (UTC)<br />
:Oops, it does ''not'' work without {{ic|-d /}}. Then the problem must be on aria's side, which expects a file name for the {{ic|-o}} option, which is then catenated with {{ic|-d}} into the full path. Assuming that {{ic|-d}} defaults to the cwd, {{ic|/var/cache/}} would appear twice in the result. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:43, 16 October 2015 (UTC)<br />
<br />
== pacman cache ==<br />
<br />
I still think we should warn people not to symlink /var or anything under it. It leaves the whole system unusable because if the cache disappears during a pacman transaction, you're left with missing /usr/lib libraries, and nothing works, including pacman itself. This is a serious enough problem that it can take hours to figure out how to recover. If the wiki had mentioned this problem it would have saved me a lot of time and effort, and I'm not the only one who has run in to this. It is not, however, considered a bug. See https://bugs.archlinux.org/task/50298. [[User:JimRees|JimRees]] ([[User talk:JimRees|talk]]) 23:15, 29 April 2017 (UTC)<br />
<br />
:This revisions says that: [https://wiki.archlinux.org/index.php?title=Pacman%2FTips_and_tricks&type=revision&diff=475454&oldid=475438]. But to make it more clear: [https://wiki.archlinux.org/index.php?title=Pacman%2FTips_and_tricks&type=revision&diff=475492&oldid=475482] -- [[User:Rdeckard|Rdeckard]] ([[User_talk:Rdeckard|talk]]) 00:13, 30 April 2017 (UTC)<br />
<br />
::Actually, I undid my change since I think that first change is more accurate (mentioning {{ic|/var/cache/pacman/pkg}} and ancestors), so I went back to that but explicitly mentioned {{ic|/var}} as an example. -- [[User:Rdeckard|Rdeckard]] ([[User_talk:Rdeckard|talk]]) 01:11, 30 April 2017 (UTC)<br />
<br />
: Thanks for the background information. I was not aware of the bug report and now clearly understand why you altered the section the way you did. I hope the [https://wiki.archlinux.org/index.php?title=Pacman/Tips_and_tricks&diff=475548&oldid=475495 recent change] is sufficient for you. Since every misbehaving program might leave a system unbootable if it plays a role in the boot process, it should be unnecessary to add this redundant information. However the problem you described is still severe and I hope you agree that the recent edits made to the article do the topic justice. Thanks for clarifying the topic and adding this to the article and sorry for reverting your edits at first. -- [[User:Edh|Edh]] ([[User talk:Edh|talk]]) 21:07, 30 April 2017 (UTC)<br />
<br />
Just figured the following out, noting here since I'm not sure it's worth noting in the page itself: {{ic|paccache}} won't remove uninstalled packages, even with {{ic|-u}}, unless {{ic|-k}} is given a value lower than the number of instances in cache. In particular, oneshot AUR experiments won't be removed without {{ic|-k0}}.<br />
[[User:Gesh|Gesh]] ([[User talk:Gesh|talk]]) 01:23, 1 November 2021 (UTC)<br />
<br />
== local repository database extension/compression recomendation ==<br />
<br />
If you opt to not compress a pacman database, the files database can become very large, 10x larger than a gzipped one in my case, which cause issues when trying to update the local pacman files db (pacman -Fy) since apparently there is a max (expected) size. Should we include a warning about uncompressed databases?<br />
<br />
{{unsigned|00:35, 29 January 2019|JoshH100}}<br />
<br />
== Use a new nginx.conf for [[Pacman/Tips_and_tricks#Dynamic_reverse_proxy_cache_using_nginx|Dynamic reverse proxy cache using nginx]] ==<br />
<br />
I propose to replace the [https://gist.github.com/anonymous/97ec4148f643de925e433bed3dc7ee7d current nginx.conf] with an [https://github.com/nastasie-octavian/nginx_pacman_cache_config/blob/master/nginx.conf improved nginx.conf] and update the section. The new config doesn't make the upstream servers directly available on the network and it allows having mirrors with different relative paths to package files. It also removes directives that are not needed and has some other minor cleanups. I've been using a similar config for a few months now without any problems, so I believe it should be fine. [[User:Noctavian|Noctavian]] ([[User talk:Noctavian|talk]]) 16:05, 28 February 2019 (UTC)<br />
<br />
:What do you mean by "The new config doesn't make the upstream servers directly available on the network"? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:54, 28 February 2019 (UTC)<br />
<br />
:: In the new config the server blocks for the upstream mirrors are set to listen to 127.0.0.1:800X. Only the computer that is running the nginx cache can send requests to 127.0.0.1. Other computers on the network can't. The current config exposes the upstream mirrors to the network, a nmap scan will show the 8080 port of the cache as open and the ports 8001, 8002, 8003 of the upstream mirrors as open. One can browse to cache.domain.example:8002 and have direct access to whatever package mirror website is used by the cache bypassing the cache config order and locations. The upstream mirrors don't need to be available to the entire network for the cache to work; they only need to be available to the computer that is hosting the nginx cache. I believe ports should not be left open on the network if they don't have to be open. [[User:Noctavian|Noctavian]] ([[User talk:Noctavian|talk]]) 08:37, 1 March 2019 (UTC)<br />
<br />
: I have written a draft for the section update on my [[User:Noctavian|user page]]. I made some small changes to the config file since last week, added comments and mirror examples and turned off IPv6 address resolution to prevent some errors that can happen sometimes. Suggestions.are welcome. I haven't seen objections to my proposal, so I'm going to wait a few more days for feedback and then update the section on the main page with my draft and the new nginx.conf file if that's ok. [[User:Noctavian|Noctavian]] ([[User talk:Noctavian|talk]]) 11:43, 8 March 2019 (UTC)<br />
<br />
::Feel free to go ahead. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:11, 16 March 2019 (UTC)<br />
<br />
== Definition of virtual package ==<br />
Regarding undoing revision 624446. I have found such a term in [[PKGBUILD]] article. I was specifically thinking about opencl-driver virtual package, but I did not mentioned that, to be more generic. [[User:Lahwaacz|Lahwaacz]], what do you think? Maybe it is better to introduce ''virtual package'' term in the [[Pacman]] article, and reapply my edit? [[User:Ashark|Ashark]] ([[User talk:Ashark|talk]]) 20:54, 9 July 2020 (UTC)<br />
<br />
:Yes, it should have a proper definition instead of "definition" by example. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:57, 10 July 2020 (UTC)<br />
<br />
::Please, take a look: [[Pacman#Virtual_packages]]. [[User:Ashark|Ashark]] ([[User talk:Ashark|talk]]) 15:12, 11 July 2020 (UTC)<br />
<br />
:::It's a good start, thanks. I made a small change: [https://wiki.archlinux.org/index.php?title=Pacman&diff=624921&oldid=624800] -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:46, 12 July 2020 (UTC)<br />
<br />
== Warning about listing changed backup files ==<br />
<br />
I understand it's obvious the command doesn't track files not owned by any packages. But the introduction to that part is about backup up your /etc folder. Hence it is innacurate that this command suffice to list the modified files in /etc, because you (or a package from the AUR) might have created some new files. Shouldn't there be a mention about this inaccuracy ?<br />
[[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 18:44, 23 October 2020 (UTC)<br />
<br />
:No, it is about [[PKGBUILD#backup|backup files specified in the PKGBUILD]]. It is obvious from the definition that such files must be tracked by pacman. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:55, 23 October 2020 (UTC)<br />
<br />
::So it should be considered a bug if those folders are not in the PKGBUILD backup ? There seems to be some important packages that do not list those files correctly (for example systemd doesn't list /etc/systemd/system, or pacman /etc/pacman.d/hooks). This seems like a risky method to backup your /etc folder.<br />
::[[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 19:28, 23 October 2020 (UTC)<br />
<br />
:::It's not a bug - the {{ic|backup}} array makes sense only for files owned by the package. You are completely missing the point of the {{ic|backup}} field - it has nothing to do with [[System backup]]. Please read [[PKGBUILD#backup]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:34, 23 October 2020 (UTC)<br />
<br />
::::Ok, I think I better understand what the backup in the PKGBUILD means. But when the part begins with `If you want to back up your system configuration files`, shouldn't it be expected that the part explains a method to backup your system configuration files, not just the ones specified in the backup fields of the PKGBUILD ?<br />
::::[[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]])<br />
<br />
:::::I've added an accuracy flag, maybe somebody can clear up the introduction. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:55, 25 October 2020 (UTC)<br />
<br />
== Parallel download natively supported in pacman version 6 ==<br />
That should be definetly mentioned somewhere in the performance section. So powerpill doesn't really seem necessary anymore. Maybe it still does some things different/better, but I'd still mention that you can get parallel downloads even without it now.<br />
{{Unsigned|08:57, 1 June 2021 (UTC)|Elimik31}}</div>Geshhttps://wiki.archlinux.org/index.php?title=Power_management/Suspend_and_hibernate&diff=699030Power management/Suspend and hibernate2021-10-13T19:44:38Z<p>Gesh: Simplify conditional in suggested awk command</p>
<hr />
<div>[[Category:Power management]]<br />
[[de:Bereitschaft und Ruhezustand]]<br />
[[es:Power management (Español)/Suspend and hibernate]]<br />
[[ja:サスペンドとハイバネート]]<br />
[[ru:Power management (Русский)/Suspend and hibernate]]<br />
[[zh-hans:Power management (简体中文)/Suspend and hibernate]]<br />
{{Related articles start}}<br />
{{Related|Uswsusp}}<br />
{{Related|systemd}}<br />
{{Related|Power management}}<br />
{{Related articles end}}<br />
<br />
Currently there are three methods of suspending available:<br />
<br />
; Suspend to RAM (aka suspend, aka sleep): The '''S3''' sleeping state as defined by ACPI. Works by cutting off power to most parts of the machine aside from the RAM, which is required to restore the machine's state. Because of the large power savings, it is advisable for laptops to automatically enter this mode when the computer is running on batteries and the lid is closed (or the user is inactive for some time).<br />
; Suspend to disk (aka hibernate): The '''S4''' sleeping state as defined by ACPI. Saves the machine's state into [[swap space]] and completely powers off the machine. When the machine is powered on, the state is restored. Until then, there is [[Wikipedia:Standby power|zero]] power consumption.<br />
; Suspend to both: A hybrid of the aforementioned methods, sometimes called '''hybrid suspend'''. Saves the machine's state into swap space, but does not power off the machine. Instead, it invokes usual suspend to RAM. Therefore, if the battery is not depleted, the system can resume from RAM. If the battery is depleted, the system can be resumed from disk, which is much slower than resuming from RAM, but the machine's state has not been lost.<br />
<br />
There are multiple low level interfaces (backends) providing basic functionality, and some high level interfaces providing tweaks to handle problematic hardware drivers/kernel modules (e.g. video card re-initialization).<br />
<br />
{{Expansion|Document "suspend to idle" (called [https://www.kernel.org/doc/html/latest/admin-guide/pm/sleep-states.html#suspend-to-idle S2Idle] by the kernel, [https://01.org/blogs/qwang59/2018/how-achieve-s0ix-states-linux S0ix] by Intel and [https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/modern-standby Modern Standby] by Microsoft) and {{ic|/sys/power/mem_sleep}} values.}}<br />
<br />
== Low level interfaces ==<br />
<br />
Though these interfaces can be used directly, it is advisable to use some of [[#High level interfaces|high level interfaces]] to suspend/hibernate. Using low level interfaces directly is significantly faster than using any high level interface, since running all the pre- and post-suspend hooks takes time, but hooks can properly set hardware clock, restore wireless etc.<br />
<br />
=== kernel (swsusp) ===<br />
<br />
The most straightforward approach is to directly inform the in-kernel software suspend code (swsusp) to enter a suspended state; the exact method and state depends on the level of hardware support. On modern kernels, writing appropriate strings to {{ic|/sys/power/state}} is the primary mechanism to trigger this suspend.<br />
<br />
See [https://www.kernel.org/doc/html/latest/admin-guide/pm/sleep-states.html kernel documentation] for details.<br />
<br />
=== uswsusp ===<br />
<br />
The uswsusp ('Userspace Software Suspend') is a wrapper around the kernel's suspend-to-RAM mechanism, which performs some graphics adapter manipulations from userspace before suspending and after resuming.<br />
<br />
See main article [[Uswsusp]].<br />
<br />
== High level interfaces ==<br />
<br />
The end goal of these packages is to provide binaries/scripts that can be invoked to perform suspend/hibernate. Actually hooking them up to power buttons or menu clicks or laptop lid events is usually left to other tools. To automatically suspend/hibernate on certain power events, such as laptop lid close or battery depletion percentage, you may want to look into running [[Acpid]].<br />
<br />
=== systemd ===<br />
<br />
[[systemd]] provides native commands for suspend, hibernate and a hybrid suspend, see [[Power management#Power management with systemd]] for details. This is the default interface used in Arch Linux.<br />
<br />
See [[Power management#Sleep hooks]] for additional information on configuring suspend/hibernate hooks. Also see {{man|1|systemctl}}, {{man|8|systemd-sleep}}, and {{man|7|systemd.special}}.<br />
<br />
== Hibernation ==<br />
<br />
In order to use hibernation, you need to create a [[swap]] partition or file. You will need to point the kernel to your swap using the {{ic|1=resume=}} kernel parameter, which is configured via the boot loader. You will also need to [[#Configure the initramfs|configure the initramfs]]. This tells the kernel to attempt resuming from the specified swap in early userspace. These three steps are described in detail below.<br />
<br />
{{Note|<br />
* See [[Dm-crypt/Swap encryption#With suspend-to-disk support]] when using [[encryption]].<br />
* {{Pkg|linux-hardened}} does not support hibernation, see {{Bug|63648}}.<br />
}}<br />
<br />
=== About swap partition/file size ===<br />
<br />
Even if your swap partition is smaller than RAM, you still have a big chance of hibernating successfully. See "image_size" in the [https://www.kernel.org/doc/html/latest/admin-guide/pm/sleep-states.html?highlight=image_size#basic-sysfs-interfaces-for-system-suspend-and-hibernation kernel documentation] for information on the {{ic|image_size}} {{man|5|sysfs}} pseudo-file.<br />
<br />
You may either decrease the value of {{ic|/sys/power/image_size}} to make the suspend image as small as possible (for small swap partitions), or increase it to possibly speed up the hibernation process. For systems with a large amount of RAM, smaller values may drastically increase the speed of resuming a hibernating system. See [[systemd#systemd-tmpfiles - temporary files]] to make this change persistent.<br />
<br />
The suspend image cannot span multiple swap partitions and/or swap files. It must fully fit in one swap partition or one swap file.[https://www.kernel.org/doc/html/latest/power/swsusp.html]<br />
<br />
=== Required kernel parameters ===<br />
<br />
The [[kernel parameter]] {{ic|1=resume=''swap_device''}} must be used. Any of the [[persistent block device naming]] methods can be used as {{ic|''swap_device''}}. For example:<br />
<br />
* {{ic|1=resume=UUID=4209c845-f495-4c43-8a03-5363dd433153}}<br />
* {{ic|1=resume="PARTLABEL=Swap partition"}}<br />
* {{ic|1=resume=/dev/archVolumeGroup/archLogicalVolume}} -- if swap is on a [[LVM]] logical volume<br />
<br />
The kernel parameters will only take effect after rebooting. To be able to hibernate right away, obtain the volume's major and minor device numbers from [[lsblk]] and echo them in format {{ic|''major'':''minor''}} to {{ic|/sys/power/resume}}. If using a swap file, additionally echo the resume offset to {{ic|/sys/power/resume_offset}}.[https://www.kernel.org/doc/html/latest/power/swsusp.html]<br />
<br />
For example, if the swap device is {{ic|8:3}}:<br />
<br />
# echo 8:3 > /sys/power/resume<br />
<br />
Or when hibernating to a swap file, if the swap file is on volume {{ic|8:2}} and has the offset {{ic|38912}}:<br />
<br />
# echo 8:2 > /sys/power/resume<br />
# echo 38912 > /sys/power/resume_offset<br />
<br />
==== Hibernation into swap file ====<br />
<br />
{{Warning|[[Btrfs#Swap file|Btrfs]] on Linux kernel before version 5.0 does not support swap files. Failure to heed this warning may result in file system corruption. While a swap file may be used on Btrfs when mounted through a loop device, this will result in severely degraded swap performance.}}<br />
<br />
Using a swap file requires also setting the {{ic|1=resume=''swap_device''}} and additionally a {{ic|1=resume_offset=''swap_file_offset''}} [[kernel parameters]]. See [https://www.kernel.org/doc/html/latest/power/swsusp-and-swap-files.html the kernel documentation].<br />
<br />
{{ic|''swap_device''}} is the volume where the swap file resides and it follows the same format as for the [[Persistent block device naming#Kernel parameters|root parameter]]. The value of {{ic|''swap_file_offset''}} can be obtained by running {{ic|filefrag -v ''swap_file''}}, the output is in a table format and the required value is located in the first row of the {{ic|physical_offset}} column. For example:<br />
<br />
{{hc|# filefrag -v /swapfile|<br />
Filesystem type is: ef53<br />
File size of /swapfile is 4294967296 (1048576 blocks of 4096 bytes)<br />
ext: logical_offset: physical_offset: length: expected: flags:<br />
0: 0.. 0: '''38912'''.. 38912: 1: <br />
1: 1.. 22527: 38913.. 61439: 22527: unwritten<br />
2: 22528.. 53247: 899072.. 929791: 30720: 61440: unwritten<br />
...<br />
}}<br />
<br />
In the example the value of {{ic|''swap_file_offset''}} is the first {{ic|38912}} with the two periods.<br />
<br />
{{Tip|<br />
* The following command may be used to identify {{ic|''swap_device''}}: {{ic|1=findmnt -no UUID -T /swapfile}}<br />
* The following command may be used to identify {{ic|''swap_file_offset''}}: {{ic|1=filefrag -v /swapfile {{!}} awk '$1=="0:" {print substr($4, 1, length($4)-2)}'}}<br />
* The value of {{ic|''swap_file_offset''}} can also be obtained by running {{ic|swap-offset ''swap_file''}}. The ''swap-offset'' binary is provided within the set of tools [[uswsusp]]. If using this method, then these two parameters have to be provided in {{ic|/etc/suspend.conf}} via the keys {{ic|resume device}} and {{ic|resume offset}}. No reboot is required in this case.<br />
}}<br />
<br />
{{Note|<br />
* For a stacked block device such as an encrypted container (LUKS), RAID or LVM, the {{ic|resume}} parameter must point to the unlocked/mapped device that contains the file system with the swap file.<br />
* If the swap file is in {{ic|/home/}}, ''systemd-logind'' will not be able to determine its size and thus will prevent hibernation with the following message: {{ic|Failed to hibernate system via logind: Not enough swap space for hibernation}}. See [https://github.com/systemd/systemd/issues/15354 systemd issue 15354] for two workarounds.<br />
}}<br />
<br />
{{Tip|You might want to decrease the [[swappiness]] for your swap file if the only purpose is to be able to hibernate and not expand RAM.}}<br />
<br />
==== Hibernation into swap file on Btrfs ====<br />
<br />
The resume_offset number can be computed using the [https://github.com/osandov/osandov-linux/blob/master/scripts/btrfs_map_physical.c tool btrfs_map_physical.c].<br />
Do not try to use the filefrag tool, on [[Btrfs]] the "physical" offset you get from filefrag is not the real physical offset on disk; there is a virtual disk address space in order to support multiple devices. [https://bugzilla.kernel.org/show_bug.cgi?id=202803]<br />
<br />
Download or copy the [https://github.com/osandov/osandov-linux/blob/master/scripts/btrfs_map_physical.c tool btrfs_map_physical.c] into a file named {{ic|btrfs_map_physical.c}}, then compile it,<br />
<br />
$ gcc -O2 -o btrfs_map_physical btrfs_map_physical.c<br />
<br />
and run it. An example output is shown below.<br />
<br />
{{hc|# ./btrfs_map_physical ''/path/to/swapfile''|<br />
FILE OFFSET EXTENT TYPE LOGICAL SIZE LOGICAL OFFSET PHYSICAL SIZE DEVID PHYSICAL OFFSET<br />
0 regular 4096 2927632384 268435456 1 '''4009762816'''<br />
4096 prealloc 268431360 2927636480 268431360 1 4009766912<br />
268435456 prealloc 268435456 3251634176 268435456 1 4333764608<br />
536870912 prealloc 268435456 3520069632 268435456 1 4602200064<br />
805306368 prealloc 268435456 3788505088 268435456 1 4870635520<br />
1073741824 prealloc 268435456 4056940544 268435456 1 5139070976<br />
1342177280 prealloc 268435456 4325376000 268435456 1 5407506432<br />
1610612736 prealloc 268435456 4593811456 268435456 1 5675941888<br />
}}<br />
<br />
Note the the first physical offset returned by this tool. In this example, we use {{ic|4009762816}}. Also note the pagesize that can be found with {{ic|getconf PAGESIZE}}.<br />
<br />
To compute the {{ic|resume_offset}} value, divide the physical offset by the pagesize. In this example, it is {{ic|1=4009762816 / 4096 = 978946}}.<br />
<br />
==== Hibernation into a thinly-provisioned LVM volume ====<br />
<br />
Hibernation into a thinly-provisioned [[LVM]] volume is possible, but you have to make sure that the volume is fully allocated. Otherwise resuming from it will fail, see {{Bug|50703}}.<br />
<br />
You can fully allocate the LVM volume by simply filling it with zeros. E.g.:<br />
<br />
# dd if=/dev/zero of=/dev/vg0/swap bs=1M status=progress<br />
<br />
To verify the volume is fully allocated, you can use:<br />
<br />
{{hc|# lvs|<br />
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert<br />
swap vg0 Vwi-aot--- 10.00g pool 100<br />
}}<br />
<br />
A fully allocated volume will show up as having 100% data usage.<br />
<br />
{{Warning|Do not to use [[TRIM]] on thinly-provisioned swap volumes that are used for hibernation, i.e. do not use {{ic|discard}} in {{ic|/etc/fstab}} and the {{ic|-d}}/{{ic|--discard}} option of ''swapon''. Otherwise the used space will be deallocated.}}<br />
<br />
=== Configure the initramfs ===<br />
<br />
* When an [[initramfs]] with the {{ic|base}} hook is used, which is the default, the {{ic|resume}} hook is required in {{ic|/etc/mkinitcpio.conf}}. Whether by label or by UUID, the swap partition is referred to with a udev device node, so the {{ic|resume}} hook must go ''after'' the {{ic|udev}} hook. This example was made starting from the default hook configuration:<br />
<br />
:{{bc|1=HOOKS=(base udev autodetect keyboard modconf block filesystems '''resume''' fsck)}}<br />
<br />
:Remember to [[regenerate the initramfs]] for these changes to take effect.<br />
<br />
:{{Note|[[LVM]] users should add the {{ic|resume}} hook after {{ic|lvm2}}.}}<br />
<br />
* When an initramfs with the {{ic|systemd}} hook is used, a resume mechanism is already provided, and no further hooks need to be added.<br />
<br />
== Intel Rapid Start Technology (IRST) ==<br />
<br />
With Intel Rapid Start Technology (IRST) enabled, resuming from a deep sleep takes "[https://mjg59.dreamwidth.org/26022.html a few seconds longer than resuming from S3 but is far faster than resuming from hibernation]".<br />
<br />
Many Intel-based systems have firmware support for IRST but require a special partition on an SSD (rather than an HDD). OEM deployments of Windows may already have a preexisting IRST partition which can be retained during the Arch Linux installation process (rather than wiping and repartitioning the whole SSD). It should show up as an unformatted partition equal in size to the system's RAM.<br />
<br />
{{Warning|The Intel Rapid Start partition is not encrypted; "Intel recommends disabling Intel Rapid Start Technology if you are using software-based disk encryption".[https://www.intel.com/content/www/us/en/support/articles/000024080/technologies.html]}}<br />
<br />
However, if you intend to wipe and repartition the whole drive (or have already done so), then the IRST partition must be recreated if you also plan on using the technology. This can be done by creating an empty partition equal in size to the system's RAM and by setting its partition type to [[Wikipedia:GUID Partition Table#Partition type GUIDs|GUID]] {{ic|D3BFE2DE-3DAF-11DF-BA40-E3A556D89593}} for a [[GPT]] partition or [[Wikipedia:Partition type|ID]] {{ic|0x84}} for an [[MBR]] partition. You may also need to enable support for IRST in your system's firmware settings.<br />
<br />
{{Tip|The duration of time before IRST kicks in (after suspending) can be adjusted in the system's firmware settings.}}<br />
<br />
The duration of the IRST hibernation process (i.e., copying the "entire contents of RAM to a special partition") is dependant on the system's RAM size and SSD speed and can thus take 20–60 seconds. Some systems may indicate the process's completion with an LED indicator, e.g., when it stops blinking.<br />
<br />
See also the [https://www.intel.com/content/www/us/en/support/articles/000024078/technologies.html general Q&A] and [https://www.intel.com/content/www/us/en/support/articles/000005836/boards-and-kits/desktop-boards.html user guides] for Intel Rapid Start Technology.<br />
<br />
== Troubleshooting ==<br />
<br />
=== ACPI_OS_NAME ===<br />
<br />
You might want to tweak your '''DSDT table''' to make it work. See [[DSDT]].<br />
<br />
=== Suspend/hibernate does not work, or does not work consistently ===<br />
<br />
There have been many reports about the screen going black without easily viewable errors or the ability to do anything when going into and coming back from suspend and/or hibernate. These problems have been seen on both laptops and desktops. This is not an official solution, but switching to an older kernel, especially the LTS-kernel, will probably fix this.<br />
<br />
Also problem may arise when using hardware watchdog timer (disabled by default, see {{ic|1=RuntimeWatchdogSec=}} in {{man|5|systemd-system.conf|OPTIONS}}). Bugged watchdog timer may reset the computer before the system finished creating the hibernation image.<br />
<br />
Sometimes the screen goes black due to device initialization from within the initramfs. Removing any modules you might have in [[Mkinitcpio#MODULES]] and rebuilding the initramfs, can possibly solve this issue, specially graphics drivers for [[Kernel_mode_setting#Early_KMS_start|early KMS]]. Initializing such devices before resuming can cause inconsistencies that prevents the system resuming from hibernation. This does not affect resuming from RAM. Also, check the blog article [https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues best practices to debug suspend issues].<br />
<br />
Moving from the [[radeon]] video driver to the newer [[AMDGPU]] driver could also help to make the hibernation and awakening process successful.<br />
<br />
For Intel graphics drivers, enabling early KMS may help to solve the blank screen issue. Refer to [[Kernel mode setting#Early KMS start]] for details.<br />
<br />
After upgrading to kernel 4.15.3, resume may fail with a static (non-blinking) cursor on a black screen. [[Blacklisting]] the module {{ic|nvidiafb}} might help. [https://bbs.archlinux.org/viewtopic.php?id=234646]<br />
<br />
Laptops with Intel CPU that load {{ic|intel_lpss_pci}} module for touchpad, may face kernel panic on resume (blinking caps lock) [https://bbs.archlinux.org/viewtopic.php?id=231881]. The module needs to be added to [[initramfs]] as:<br />
<br />
{{hc|head=/etc/mkinitcpio.conf|output=<br />
MODULES=(... intel_lpss_pci ...)<br />
}}<br />
<br />
Then [[regenerate the initramfs]].<br />
<br />
=== Wake-on-LAN ===<br />
<br />
If [[Wake-on-LAN]] is active, the network interface card will consume power even if the computer is hibernated.<br />
<br />
=== Instantaneous wakeups from suspend ===<br />
<br />
For some Intel Haswell systems with the LynxPoint and LynxPoint-LP chipset, instantaneous wakeups after suspend are reported. They are linked to erroneous BIOS ACPI implementations and how the {{ic|xhci_hcd}} module interprets it during boot. As a work-around reported affected systems are added to a denylist (named {{ic|XHCI_SPURIOUS_WAKEUP}}) by the kernel case-by-case.[https://bugzilla.kernel.org/show_bug.cgi?id=66171#c6] <br />
<br />
Instantaneous resume may happen, for example, if a USB device is plugged during suspend and ACPI wakeup triggers are enabled. A viable work-around for such a system, if it is not on the denylist yet, is to disable the wakeup triggers. An example to disable wakeup through USB is described as follows.[https://bbs.archlinux.org/viewtopic.php?pid=1575617] <br />
<br />
To view the current configuration:<br />
<br />
{{hc|$ cat /proc/acpi/wakeup|<br />
Device S-state Status Sysfs node<br />
...<br />
EHC1 S3 *enabled pci:0000:00:1d.0<br />
EHC2 S3 *enabled pci:0000:00:1a.0<br />
XHC S3 *enabled pci:0000:00:14.0<br />
...<br />
}}<br />
<br />
The relevant devices are {{ic|EHC1}}, {{ic|EHC2}} and {{ic|XHC}} (for USB 3.0). To toggle their state you have to echo the device name to the file as root.<br />
<br />
# echo EHC1 > /proc/acpi/wakeup<br />
# echo EHC2 > /proc/acpi/wakeup<br />
# echo XHC > /proc/acpi/wakeup<br />
<br />
This should result in suspension working again. However, this settings are only temporary and would have to be set at every reboot. To automate this take a look at [[systemd#systemd-tmpfiles - temporary files]] or see [https://bbs.archlinux.org/viewtopic.php?pid=1575617#p1575617 BBS thread] for a possible solution and more information.<br />
<br />
Example solution with disabling PTXH and XHC0 at the same time. For some reason, two lines with PTXH and XHC0 one per line or in different files does not work.<br />
{{hc|# cat /etc/tmpfiles.d/100-disable-usb-wake.conf|<br />
# Path Mode UID GID Age Argument<br />
w /proc/acpi/wakeup - - - - PTXHXHC0<br />
}}<br />
<br />
If you use {{ic|nouveau}} driver, the reason of instantaneous wakeup may be a bug in that driver, which sometimes prevents graphics card from suspension. One possible workaround is unloading {{ic|nouveau}} kernel module right before going to sleep and loading it back after wakeup. To do this, create the following script:<br />
<br />
{{hc|/usr/lib/systemd/system-sleep/10-nouveau.sh|2=<br />
#!/bin/bash<br />
<br />
case $1/$2 in<br />
pre/*)<br />
# echo "Going to $2..."<br />
/usr/bin/echo "0" > /sys/class/vtconsole/vtcon1/bind<br />
/usr/bin/rmmod nouveau<br />
;;<br />
post/*)<br />
# echo "Waking up from $2..."<br />
/usr/bin/modprobe nouveau<br />
/usr/bin/echo "1" > /sys/class/vtconsole/vtcon1/bind<br />
;;<br />
esac<br />
}}<br />
<br />
The first echo line unbinds nouveaufb from the framebuffer console driver (fbcon). Usually it is {{ic|vtcon1}} as in this example, but it may also be another {{ic|vtcon*}}. See {{ic|/sys/class/vtconsole/vtcon*/name}} which one of them is a "frame buffer device" [https://nouveau.freedesktop.org/wiki/KernelModeSetting/].<br />
<br />
=== System does not power off when hibernating ===<br />
<br />
When you hibernate your system, the system should power off (after saving the state on the disk). Sometimes, you might see the power LED is still glowing. If that happens, it might be instructive to set the {{ic|HibernateMode}} to {{ic|shutdown}} in {{man|5|sleep.conf.d}}:<br />
<br />
{{hc|/etc/systemd/sleep.conf.d/hibernatemode.conf|2=<br />
[Sleep]<br />
HibernateMode=shutdown<br />
}}<br />
<br />
With the above configuration, if everything else is set up correctly, on invocation of a {{ic|systemctl hibernate}} the machine will shutdown saving state to disk as it does so.</div>Geshhttps://wiki.archlinux.org/index.php?title=XDG_Base_Directory&diff=692219XDG Base Directory2021-08-19T20:13:45Z<p>Gesh: Note adb hardcodes public key location, despite commit message promising alternatives</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 />
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 />
| [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] doesn't 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 />
| {{AUR|antimicro}}{{Broken package link|package not found}}<br />
| {{ic|~/.antimicro}}<br />
| [https://github.com/Antimicro/antimicro/commit/edba864 edba864]<br />
| [https://github.com/Antimicro/antimicro/issues/5]<br />
| Package moved to {{AUR|antimicrox}} - this entry needs to be migrated<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|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 />
| [[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 />
| {{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]<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 />
| {{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 />
|<br />
|-<br />
| [[dwb]]<br />
|<br />
|<br />
|<br />
|<br />
<br />
|-<br />
| [[fish]]<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| [[fontconfig]]<br />
| {{ic|~/.fontconfig}} {{ic|~/.fonts}}<br />
| [https://cgit.freedesktop.org/fontconfig/commit/?id=8c255fb 8c255fb], [https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commit/437f03299bd1adc9673cd576072f1657be8fd4e0]<br />
|<br />
| Use {{ic|XDG_DATA_HOME/fonts}} to store fonts instead.<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|freerdp}}<br />
| {{ic|~/.freerdp}}<br />
| [https://github.com/FreeRDP/FreeRDP/commit/edf6e72 edf6e72]<br />
|<br />
|<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 />
| [[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 />
|-<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 />
| [[GStreamer]]<br />
| {{ic|~/.gstreamer-0.10}}<br />
| [https://cgit.freedesktop.org/gstreamer/gstreamer/commit/?id=4e36f93 4e36f93]<br />
| [https://bugzilla.gnome.org/show_bug.cgi?id=518597]<br />
|<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 />
| [[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|i3status}}<br />
| {{ic|~/.i3status.conf}}<br />
| [http://code.stapelberg.de/git/i3status/commit/?id=c3f7fc4 c3f7fc4]<br />
|<br />
|<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 />
| [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 />
| [[Kakoune]]<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| [[Core utilities|less]]<br />
| {{ic|~/.lesshst}}, {{ic|~/.lesskey}}<br />
| [https://www.greenwoodsoftware.com/less/news.590.html 590]<br />
| [https://github.com/gwsw/less/issues/153]<br />
| The environment variables {{ic|XDG_CONFIG_HOME}} and {{ic|XDG_DATA_HOME}} '''must''' be set.<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 />
| [[llpp]]<br />
|<br />
| [https://repo.or.cz/w/llpp.git/commit/3ab86f0 3ab86f0]<br />
|<br />
| Currently ''llpp'' places the configuration directly under {{ic|XDG_CONFIG_HOME}} instead of creating a directory.<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://cgit.freedesktop.org/mesa/mesa/commit/?id=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 />
| [[newsbeuter]]<br />
| {{ic|~/.newsbeuter}}<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 [http://newsbeuter.org/doc/newsbeuter.html#_xdg_base_directory_support]:<br />
<br />
{{ic|1=mkdir -p "$XDG_DATA_HOME"/newsbeuter "$XDG_CONFIG_HOME"/newsbeuter}}<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 />
| Only available on master as of 2018-12-04.<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 />
| {{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 />
|<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 />
| {{Pkg|pandoc}}<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 />
| {{Pkg|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 />
| [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 />
| {{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 />
| {{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 />
| {{AUR|orbment-git}}<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| [[pacman]]<br />
| {{ic|~/.makepkg.conf}}<br />
| [https://gitlab.archlinux.org/pacman/pacman/commit/80eca94 80eca94]<br />
| [https://mailman.archlinux.org/pipermail/pacman-dev/2014-July/019178.html]<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://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=59a8618 59a8618]<br />
[https://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=87ae830 87ae830]<br />
[https://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=9ab510a 9ab510a]<br />
[https://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=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 />
| {{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 />
|<br />
|<br />
| Cache is placed in {{ic|XDG_CONFIG_HOME/sublime-text-3/Cache}} instead of expected {{ic|XDG_CACHE_HOME/sublime-text-3}}.<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 />
|<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 />
|-<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]<br />
|<br />
|<br />
|-<br />
| [[Xsettingsd]]<br />
| {{ic|~/.xsettingsd}}<br />
| [https://github.com/derat/xsettingsd/commit/b4999f5 b4999f5]<br />
|<br />
|<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 />
| Alternatively the environments {{ic|XMONAD_CONFIG_HOME}}, {{ic|XMONAD_DATA_HOME}}, and {{ic|XMONAD_CACHE_HOME}} are also available.<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 />
<br />
=== Partial ===<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 />
| {{Aur|anaconda}}<br />
| {{ic|~/.conda/.condarc}}, {{ic|~/.conda/condarc}}, {{ic|~/.conda/condarc.d/}}, {{ic|~/.condarc}}<br />
|<br />
| [https://conda.io/projects/conda/en/latest/user-guide/configuration/use-condarc.html#searching-for-condarc]<br />
| {{ic|1=export CONDARC="$XDG_CONFIG_HOME/conda/condarc"}}<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 />
| [[Anki]]<br />
| {{ic|~/Anki}}, {{ic|~/Documents/Anki}}<br />
|<br />
| [https://github.com/dae/anki/pull/49] [https://github.com/dae/anki/pull/58]<br />
| {{ic|1=anki -b "$XDG_DATA_HOME"/Anki}}<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 />
| [[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 />
| {{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 />
| {{Aur|buchhaltung-git}}<br />
| {{ic|~/.buchhaltung}}<br />
|<br />
| [https://github.com/johannesgerer/buchhaltung/issues/44]<br />
| {{ic|1=export BUCHHALTUNG="$XDG_CONFIG_HOME"/buchhaltung}}<br />
|-<br />
| [[Ruby#Bundler]]<br />
| {{ic|~/.bundle}}<br />
| 2.1.0<br />
| [https://github.com/bundler/bundler/pull/6024] [https://github.com/bundler/bundler/issues/4333] [https://github.com/rubygems/rubygems/issues/1599]<br />
|<br />
export BUNDLE_USER_CONFIG="$XDG_CONFIG_HOME"/bundle<br />
export BUNDLE_USER_CACHE="$XDG_CACHE_HOME"/bundle<br />
export BUNDLE_USER_PLUGIN="$XDG_DATA_HOME"/bundle<br />
<br />
Is considered as fixed by the environment variables.<br />
|-<br />
| [https://www.haskell.org/cabal cabal]<br />
| {{ic|~/.cabal/}}<br />
|<br />
| [https://github.com/haskell/cabal/issues/680]<br />
|<br />
export CABAL_CONFIG="$XDG_CONFIG_HOME"/cabal/config<br />
export CABAL_DIR="$XDG_CACHE_HOME"/cabal<br />
<br />
See documentation on [https://cabal.readthedocs.io/en/3.4/installing-packages.html#environment-variables environment variables].<br />
<br />
CABAL_DIR may be put into DATA if you consider downloaded files as such.<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 />
| {{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 />
|<br />
[https://groups.google.com/forum/#!topic/chromium-dev/QekVQxF3nho]<br />
[https://code.google.com/p/chromium/issues/detail?id=16976]<br />
[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 />
| [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 />
| {{AUR|flutter}}<br />
| {{ic|~/.flutter}}, {{ic|~/.flutter_settings}}, {{ic|~/.flutter_tool_state}}<br />
|<br />
| [https://github.com/flutter/flutter/issues/59430]<br />
|<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 />
| {{Pkg|freecad}}<br />
| {{ic|~/.FreeCAD}}<br />
|<br />
| [https://tracker.freecadweb.org/view.php?id=2956]<br />
| {{ic|1=freecad -u "$XDG_CONFIG_HOME"/FreeCAD/user.cfg -s "$XDG_CONFIG_HOME"/FreeCAD/system.cfg}}<br />
<br />
Despite these options, {{Pkg|freecad}} will still create the file {{ic|.FreeCAD/cookie}} as the web module has it [https://github.com/FreeCAD/FreeCAD/blob/master/src/Mod/Web/Gui/CookieJar.cpp#L55 hard coded]<br />
|-<br />
| [[GDB]]<br />
| {{ic|~/.gdbinit}}, {{ic|~/.gdb_history}}<br />
|<br />
|<br />
| {{ic|1=export GDBHISTFILE="$XDG_DATA_HOME"/gdb/history}}, {{ic|gdb -nh -x "$XDG_CONFIG_HOME"/gdb/init}}<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 />
| {{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}}<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 />
| {{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 />
| [http://ipython.org ipython]/[[jupyter]]<br />
| {{ic|~/.ipython}}<br />
|<br />
| [https://github.com/ipython/ipython/pull/4457 won't fix],[https://github.com/ipython/ipython/issues/12431 won't fix]<br />
| {{ic|1=export IPYTHONDIR="$XDG_CONFIG_HOME"/jupyter}}, {{ic|1=export JUPYTER_CONFIG_DIR="$XDG_CONFIG_HOME"/jupyter}}<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 />
| {{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 />
| [[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 />
| {{AUR|librewolf}}<br />
| {{ic|~/.mozilla}}<br />
{{ic|~/.librewolf}}<br />
|<br />
|<br />
| {{ic|1=mkdir $XDG_DATA_HOME/librewolf && mv librewolf.AppImage $XDG_DATA_HOME/librewolf}}, {{ic|$XDG_DATA_HOME/librewolf/librewolf.AppImage --appimage-portable-home}}, {{ic|sudo ln -s $XDG_DATA_HOME/librewolf/librewolf.AppImage /usr/local/bin/librewolf}}<br />
<br />
This is not a perfect solution - you will have to create symlinks to your downloads and other XDG directories to get the browser to use them properly. However, it is workable. Of course, you could do this in any directory, not just {{ic|$XDG_DATA_HOME}}<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 />
| {{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 />
| [[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|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 />
| {{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://netbeans.org/bugzilla/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 />
|<br />
| {{ic|1=export NODE_REPL_HISTORY="$XDG_DATA_HOME"/node_repl_history}} [https://nodejs.org/api/repl.html#repl_environment_variable_options]<br />
|-<br />
| [[notmuch]]<br />
| {{ic|~/.notmuch-config}}<br />
|<br />
| [https://notmuchmail.org/pipermail/notmuch/2011/007007.html]<br />
| {{ic|1=export NOTMUCH_CONFIG="$XDG_CONFIG_HOME"/notmuch/notmuchrc}}, {{ic|1=export NMBGIT="$XDG_DATA_HOME"/notmuch/nmbug}}<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 />
tmp=${XDG_RUNTIME_DIR}/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 />
| {{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] {{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_CACHE_HOME/pg/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_CACHE_HOME/pg"}}<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 />
| {{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|python-pylint}}<br />
| {{ic|~/.pylint.d}}<br />
|<br />
| [https://github.com/PyCQA/pylint/issues/1364 won't fix]<br />
| {{ic|1=export PYLINTHOME="$XDG_CACHE_HOME"/pylint}}<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 />
| [[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|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 />
| [[Ruby#RubyGems]]<br />
| {{ic|~/.gem}}<br />
|<br />
|<br />
| {{ic|1=export GEM_HOME="$XDG_DATA_HOME"/gem}}, {{ic|1=export GEM_SPEC_CACHE="$XDG_CACHE_HOME"/gem}}<br />
<br />
Make sure to remove {{ic|gem: --user-install}} from {{ic|/etc/gemrc}}<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 />
| {{Pkg|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://spacemacs.org/ spacemacs]{{Dead link|2021|05|17|status=SSL error}}<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 />
| [[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=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]<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 />
| {{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 />
| {{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 />
| {{Pkg|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 />
| [[AUR|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 />
| [[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 />
Note that these variables are respected by ''xinit'', but not by ''startx''. Instead, specify the filename as an argument:<br />
<br />
{{ic|1=startx "$XDG_CONFIG_HOME/X11/xinitrc" -- "$XDG_CONFIG_HOME/X11/xserverrc" vt1}}<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 made 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 />
| [[Ansible]]<br />
| {{ic|~/.ansible}}<br />
| [https://github.com/ansible/ansible/issues/52354] [https://github.com/ansible/ansible/issues/68587]<br />
|<br />
|-<br />
| [[AMule]]<br />
| {{ic|~/.aMule}}<br />
|<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 />
|<br />
|<br />
|-<br />
| [[Arduino]]<br />
| {{ic|~/.arduino15}}, {{ic|~/.jssc}}<br />
| [https://github.com/arduino/Arduino/issues/3915 won't fix] [https://github.com/arduino/Arduino/issues/10486]<br />
|<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 />
<br />
|-<br />
| [https://www.audacityteam.org/ Audacity]<br />
| {{ic|~/.audacity-data/}}<br />
| [https://bugzilla.audacityteam.org/show_bug.cgi?id=2201]<br />
|<br />
<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 />
|-<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_DATA_HOME"/bash}}<br />
{{ic|1=export HISTFILE="$XDG_DATA_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 />
|<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 />
|<br />
|-<br />
| {{AUR|cryptomator}}<br />
| {{ic|~/.Cryptomator}}<br />
| [https://github.com/cryptomator/cryptomator/issues/710]<br />
|<br />
|-<br />
| [[CUPS]]<br />
| {{ic|~/.cups/}}<br />
| [https://github.com/apple/cups/issues/4243 won't fix]<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 />
| [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 />
| {{Pkg|fltk}}<br />
| {{ic|~/.fltk/}}<br />
| [https://www.fltk.org/str.php?L3370+P0+S0+C0+I0+E0+V%25+Qxdg]<br />
|<br />
|-<br />
| [https://github.com/rwestlund/freesweep freesweep]<br />
| {{ic|~/.sweeprc}}<br />
| [https://github.com/rwestlund/freesweep/issues/9]<br />
|<br />
|-<br />
| {{Pkg|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 />
| [https://www.haskell.org/ghc/ GHC]<br />
| {{ic|~/.ghc}}<br />
| [https://ghc.haskell.org/trac/ghc/ticket/6077]<br />
|<br />
|-<br />
| {{Pkg|ghidra}}<br />
|<br />
| [https://github.com/NationalSecurityAgency/ghidra/issues/908]<br />
|<br />
|-<br />
| [[GoldenDict]]<br />
| {{ic|~/.goldendict/}}<br />
| [https://github.com/goldendict/goldendict/issues/151]<br />
|<br />
|-<br />
| {{Pkg|gramps}}<br />
| {{ic|~/.gramps/}}<br />
| [https://gramps-project.org/bugs/view.php?id=8025]<br />
|<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-sdk}}<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 />
| {{AUR|kite}}<br />
| {{ic|~/.kite/}}<br />
| [https://github.com/kiteco/issue-tracker/issues/242]<br />
|<br />
|-<br />
| [[Kubernetes]]<br />
| {{ic|~/.kube/}}<br />
| [https://github.com/kubernetes/kubectl/issues/942][https://github.com/kubernetes/kubernetes/issues/56402]<br />
|<br />
|-<br />
| {{Pkg|hplip}}<br />
| {{ic|~/.hplip/}}<br />
| [https://bugs.launchpad.net/hplip/+bug/307152]<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 />
| [[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 />
| {{Pkg|kotlin}}<br />
| {{ic|~/.kotlinc_history}}<br />
|<br />
|<br />
|-<br />
| [http://www.linux-pam.org/ Linux PAM]<br />
| {{ic|~/.pam_environment}}<br />
| [https://github.com/linux-pam/linux-pam/issues/7]<br />
| Hardcoded in [https://github.com/linux-pam/linux-pam/blob/master/modules/pam_env/pam_env.c modules/pam_env/pam_env.c]<br />
|-<br />
| [https://lldb.llvm.org/ lldb]<br />
| {{ic|~/.lldb}}, {{ic|~/.lldbinit}}<br />
|<br />
|<br />
|-<br />
| [[LMMS|LMMS]]<br />
| {{ic|~/.lmmsrc.xml}}<br />
| [https://avidemux.org/smif/index.php/topic,19596.0.html]<br />
|<br />
|-<br />
| [http://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 />
|<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 />
| [http://0ldsk00l.ca/nestopia/ Nestopia UE]<br />
| {{ic|~/.nestopia/}}<br />
| [https://github.com/0ldsk00l/nestopia/pull/292 won't fix]<br />
|<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 />
|<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 />
| [[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/master/tools/perf/util/config.c#L29 tools/perf/util/config.c:29].<br />
|-<br />
| [[perl]]<br />
| {{ic|~/.cpan}}<br />
|<br />
| Perl5's [https://github.com/andk/cpanpm CPAN] expects {{ic|~/.cpan}}.<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 />
| [[PuTTY]]<br />
| {{ic|~/.putty/}}<br />
|<br />
| [https://www.chiark.greenend.org.uk/~sgtatham/putty/faq.html#faq-settings]<br />
|-<br />
| [[python]]<br />
| {{ic|~/.python_history}}<br />
| [https://bugs.python.org/issue29779] [https://bugs.python.org/issue20886]<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 />
| {{Pkg|python-poetry}}<br />
| {{ic|~/.poetry}}<br />
| [https://github.com/python-poetry/poetry/issues/2148]<br />
| {{ic|POETRY_HOME}} can be used but it does not separate data and config.<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 />
|<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 />
| [[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 />
| {{Pkg|scribus}}<br />
| {{ic|~/.scribus}}<br />
|<br />
|<br />
|-<br />
| [https://www.seamonkey-project.org/ SeaMonkey]<br />
| {{ic|~/.mozilla/seamonkey}}<br />
| [https://bugzil.la/726939]<br />
|<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 />
| [[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 />
| [http://www.texmacs.org/ TeXmacs]<br />
| {{ic|~/.TeXmacs}}<br />
|<br />
|<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|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|<br />
set runtimepath^&#61;$XDG_CONFIG_HOME/vim<br />
set runtimepath+&#61;$XDG_DATA_HOME/vim<br />
set runtimepath+&#61;$XDG_CONFIG_HOME/vim/after<br />
<br />
set packpath^&#61;$XDG_DATA_HOME/vim,$XDG_CONFIG_HOME/vim<br />
set packpath+&#61;$XDG_CONFIG_HOME/vim/after,$XDG_DATA_HOME/vim/after<br />
<br />
let g:netrw_home &#61; $XDG_DATA_HOME."/vim"<br />
call mkdir($XDG_DATA_HOME."/vim/spell", 'p')<br />
set viewdir&#61;$XDG_DATA_HOME/vim/view &#124; call mkdir(&viewdir, 'p')<br />
<br />
set backupdir&#61;$XDG_CACHE_HOME/vim/backup &#124; call mkdir(&backupdir, 'p')<br />
set directory&#61;$XDG_CACHE_HOME/vim/swap &#124; call mkdir(&directory, 'p')<br />
set undodir&#61;$XDG_CACHE_HOME/vim/undo &#124; call mkdir(&undodir, 'p')<br />
<br />
if !has('nvim') &#124; set viminfofile&#61;$XDG_CACHE_HOME/vim/viminfo &#124; endif<br />
}}<br />
<br />
{{hc|~/.profile|2=<br />
export VIMINIT='source "$XDG_CONFIG_HOME/vim/vimrc"'<br />
}}<br />
<br />
{{ic|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 VIMINIT='let $MYVIMRC = !has("nvim") ? "$XDG_CONFIG_HOME/vim/vimrc" : "$XDG_CONFIG_HOME/nvim/init.vim" | so $MYVIMRC'<br />
<br />
* https://tlvince.com/vim-respect-xdg<br />
* https://blog.joren.ga/tools/vim-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 />
| {{AUR|visidata}}<br />
| {{ic|~/.visidata}}<br />
| [https://github.com/saulpw/visidata/issues/487]<br />
|<br />
|-<br />
| {{Pkg|w3m}}<br />
| {{ic|~/.w3m}}<br />
| [https://sourceforge.net/p/w3m/feature-requests/31/] [https://github.com/tats/w3m/issues/130]<br />
|<br />
|-<br />
| [https://w1.fi/ wpa_cli]<br />
| {{ic|~/.wpa_cli_history}}<br />
|<br />
|<br />
|-<br />
| {{Pkg|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|gnome_user_dir&#61;"$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 />
| [https://web.archive.org/web/20160417005824/https://opensource.conformal.com/wiki/xombrero xombrero]<br />
| {{ic|~/.xombrero}}<br />
| [https://github.com/conformal/xombrero/issues/74]{{Dead link|2021|05|17|status=404}}<br />
|<br />
|-<br />
| {{Pkg|xournalpp}}<br />
| {{ic|~/.xournalpp}}<br />
| [https://github.com/xournalpp/xournalpp/issues/1101]<br />
| XDG will be honored in the next version [https://github.com/xournalpp/xournalpp/pull/1384]<br />
|-<br />
| {{Pkg|xpdf}}<br />
| {{ic|~/.xpdfrc}}<br />
|<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 />
| {{ic|1=export SSB_HOME="$XDG_DATA_HOME"/zoom}}<br />
|-<br />
| {{AUR|zotero}}<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 />
== Libraries ==<br />
<br />
; C<br />
: [https://github.com/Jorengarenar/libXDGdirs libXDGdirs]<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/ProtonMail/go-appdir go-appdir]<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/rubyworks/xdg rubyworks/xdg]<br />
<br />
; Rust<br />
: [https://github.com/soc/directories-rs directories-rs]<br />
: [https://github.com/whitequark/rust-xdg rust-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>Geshhttps://wiki.archlinux.org/index.php?title=Talk:XDG_Base_Directory&diff=650720Talk:XDG Base Directory2021-02-03T19:47:25Z<p>Gesh: adb: XDG advice doesn't work</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)</div>Geshhttps://wiki.archlinux.org/index.php?title=XDG_Base_Directory&diff=650340XDG Base Directory2021-01-31T13:35:23Z<p>Gesh: Add moving adb keys</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 />
=== 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_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 />
<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 />
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. This is here to demonstrate the viability of this specification by listing commonly found dotfiles and their support status. 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. 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. Additionally if the process is too error prone or difficult, such as [https://www.haskell.org/cabal/ Haskell's cabal] or Eclipse, they should also be considered 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 />
| [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 />
| {{ic|$XDG_CONFIG_HOME/Google/AndroidStudioX.X}}<br />
{{ic|$XDG_DATA_HOME/Google/AndroidStudioX.X}}<br />
{{ic|$XDG_CACHE_HOME/Google/AndroidStudioX.X}}<br />
[https://developer.android.com/studio/intro/studio-config#file_location Location overview by Google] doesn't 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 />
| {{AUR|antimicro}}{{Broken package link|package not found}}<br />
| {{ic|~/.antimicro}}<br />
| [https://github.com/Antimicro/antimicro/commit/edba864 edba864]<br />
| [https://github.com/Antimicro/antimicro/issues/5]<br />
| Package moved to {{AUR|antimicrox}} - this entry needs to be migrated<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 />
| {{ic|$XDG_CONFIG_HOME/aria2/}}<br />
{{ic|$XDG_CACHE_HOME/aria2/}}<br />
|-<br />
| {{Pkg|asunder}}<br />
|<br />
{{ic|~/.asunder<br><br />
~/.asunder_album_artist<br><br />
~/.asunder_album_genre<br><br />
~/.asunder_album_title}}<br />
| [https://littlesvr.ca/bugs/show_bug.cgi?id=31 2.9.0]<br />
| [https://littlesvr.ca/bugs/show_bug.cgi?id=52]<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|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 />
| [[Blender]]<br />
| {{ic|~/.blender}}<br />
| [http://git.blender.org/gitweb/gitweb.cgi/blender.git/commit/4293f47 4293f47]<br />
| [https://developer.blender.org/T28943]<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 />
| {{ic|XDG_CONFIG_HOME/calcurse}}<br />
<br />
{{ic|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 />
| {{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]<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 />
| {{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 />
|<br />
|-<br />
| [[dwb]]<br />
|<br />
|<br />
|<br />
|<br />
<br />
|-<br />
| [[fish]]<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| [[fontconfig]]<br />
|<br />
{{ic|~/.fontconfig<br><br />
~/.fonts}}<br />
| [https://cgit.freedesktop.org/fontconfig/commit/?id=8c255fb 8c255fb], [https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commit/437f03299bd1adc9673cd576072f1657be8fd4e0]<br />
|<br />
| Use {{ic|"$XDG_DATA_HOME"/fonts}} to store fonts instead.<br />
|-<br />
| {{Pkg|fontforge}}<br />
|<br />
{{ic|~/.FontForge<br><br />
~/.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|freerdp}}<br />
| {{ic|~/.freerdp}}<br />
| [https://github.com/FreeRDP/FreeRDP/commit/edf6e72 edf6e72]<br />
|<br />
|<br />
|-<br />
| [[Emacs]]<br />
| {{ic|~/.emacs<br>~/.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 />
| [[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 />
|-<br />
| [[GIMP]]<br />
|<br />
{{ic|~/.gimp-x.y<br><br />
~/.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 />
| [[GStreamer]]<br />
| {{ic|~/.gstreamer-0.10}}<br />
| [https://cgit.freedesktop.org/gstreamer/gstreamer/commit/?id=4e36f93 4e36f93]<br />
| [https://bugzilla.gnome.org/show_bug.cgi?id=518597]<br />
|<br />
|-<br />
| [[GTK]] 3<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/jakubroztocil/httpie/commit/5af0874ed302e9ef79cec97836529ccf353e53f7 5af0874]<br />
| [https://github.com/jakubroztocil/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|i3status}}<br />
| {{ic|~/.i3status.conf}}<br />
| [http://code.stapelberg.de/git/i3status/commit/?id=c3f7fc4 c3f7fc4]<br />
|<br />
|<br />
|-<br />
| {{Pkg|imagemagick}}<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| [[Inkscape]]<br />
| {{ic|~/.inkscape}}<br />
| [http://wiki.inkscape.org/wiki/index.php/Release_notes/0.47#Preferences 0.47]<br />
| [https://bugs.launchpad.net/inkscape/+bug/199720]<br />
|<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 />
| {{ic|$XDG_CONFIG_HOME/Jetbrains/IntelliJIdeaXXXX.X}}<br />
{{ic|$XDG_DATA_HOME/Jetbrains/IntelliJIdeaXXXX.X}}<br />
{{ic|$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 />
| [[Kakoune]]<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| latexmk (in {{Pkg|texlive-core}})<br />
| {{ic|~/.latexmkrc}}<br />
|<br />
|<br />
|<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 />
| [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 />
| [[llpp]]<br />
|<br />
| [http://repo.or.cz/w/llpp.git/commit/3ab86f0 3ab86f0]<br />
|<br />
| Currently ''llpp'' places the configuration directly under {{ic|XDG_CONFIG_HOME}} instead of creating a directory.<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://cgit.freedesktop.org/mesa/mesa/commit/?id=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 />
|<br />
{{ic|~/.nano/<br><br />
~/.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 />
|<br />
{{ic|~/.nvim<br><br />
~/.nvimlog<br><br />
~/.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 />
| [[newsbeuter]]<br />
| {{ic|~/.newsbeuter}}<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 [http://newsbeuter.org/doc/newsbeuter.html#_xdg_base_directory_support]:<br />
<br />
{{ic|1=$ mkdir -p "$XDG_DATA_HOME"/newsbeuter "$XDG_CONFIG_HOME"/newsbeuter}}<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 />
| Only available on master as of 2018-12-04.<br />
|-<br />
| {{AUR|np2kai-git}}<br />
|<br />
{{ic|~/.config/np2kai<br><br />
~/.config/xnp2kai}}<br />
| [https://github.com/AZO234/NP2kai/commit/56a1cc2 56a1cc2]<br />
| [https://github.com/AZO234/NP2kai/pull/50]<br />
|<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 />
|<br />
|-<br />
| {{AUR|opentyrian}}<br />
| {{ic|~/.opentyrian}}<br />
| [https://bitbucket.org/opentyrian/opentyrian/commits/8d45ff2 8d45ff2]<br />
| [https://web.archive.org/web/20140815181350/http://code.google.com/p/opentyrian/issues/detail?id=125]<br />
|<br />
|-<br />
| {{Pkg|pandoc}}<br />
| {{ic|~/.pandoc/}}<br />
| [https://github.com/jgm/pandoc/commit/0bed0ab5a308f5e72a01fa9bee76488556288862 0bed0ab]<br />
| [https://github.com/jgm/pandoc/issues/3582]<br />
|<br />
|-<br />
| {{Pkg|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 />
| [http://pryrepl.org/ Pry]<br />
| {{ic|~/.pryrc<br>~/.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 />
| {{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 />
| {{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 />
| {{AUR|orbment-git}}<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| [[pacman]]<br />
| {{ic|~/.makepkg.conf}}<br />
| [https://projects.archlinux.org/pacman.git/commit/?id=80eca94 80eca94]<br />
| [https://mailman.archlinux.org/pipermail/pacman-dev/2014-July/019178.html]<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 />
|<br />
{{ic|~/.pulse<br><br />
~/.pulse-cookie}}<br />
|<br />
[https://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=59a8618 59a8618]<br />
[https://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=87ae830 87ae830]<br />
[https://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=9ab510a 9ab510a]<br />
[https://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=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 />
| {{Pkg|sdcv}}<br />
|<br />
{{ic|~/.stardict/<br><br />
~/.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 />
|<br />
|<br />
| Cache is placed in {{ic|$XDG_CONFIG_HOME/sublime-text-3/Cache}} instead of expected {{ic|$XDG_CACHE_HOME/sublime-text-3}}.<br />
|-<br />
| [[surfraw]]<br />
|<br />
{{ic|~/.surfraw.conf<br><br />
~/.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 />
|<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 />
|-<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 />
| [http://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 />
| [[Wireshark]]<br />
| {{ic|~/.wireshark}}<br />
| [https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=b0b53fa b0b53fa]<br />
|<br />
|<br />
|-<br />
| {{AUR|xsettingsd-git}}<br />
| {{ic|~/.xsettingsd}}<br />
| [https://github.com/derat/xsettingsd/commit/b4999f5 b4999f5]<br />
|<br />
|<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 />
| Alternatively the environments {{ic|XMONAD_CONFIG_HOME}}, {{ic|XMONAD_DATA_HOME}}, and {{ic|XMONAD_CACHE_HOME}} are also available.<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 />
<br />
=== Partial ===<br />
{| class="wikitable sortable" style="width: 100%"<br />
! Application<br />
! Legacy Path<br />
! Supported Since<br />
! Discussion<br />
! Notes<br />
|-<br />
| {{Pkg|abook}}<br />
| {{ic|~/.abook}}<br />
|<br />
|<br />
| {{ic|1=$ abook --config "$XDG_CONFIG_HOME"/abook/abookrc --datafile "$XDG_DATA_HOME"/abook/addressbook}}<br />
|-<br />
| {{Aur|anaconda}}<br />
| {{ic|~/.conda/.condarc<br>~/.conda/condarc<br>~/.conda/condarc.d/<br>~/.condarc}}<br />
| <br />
| [https://conda.io/projects/conda/en/latest/user-guide/configuration/use-condarc.html#searching-for-condarc]<br />
| {{ic|1=$ export CONDARC="$XDG_CONFIG_HOME/conda/condarc"}}<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 />
| [[Anki]]<br />
|<br />
{{ic|~/Anki<br><br />
~/Documents/Anki}}<br />
|<br />
| [https://github.com/dae/anki/pull/49] [https://github.com/dae/anki/pull/58]<br />
| {{ic|1=$ anki -b "$XDG_DATA_HOME"/Anki}}<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 />
|<br />
{{ic|1=$ export AWS_SHARED_CREDENTIALS_FILE="$XDG_CONFIG_HOME"/aws/credentials<br><br />
$ 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 />
| [[bazaar]]<br />
|<br />
{{ic|~/.bazaar<br><br />
~/.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 />
| {{Aur|buchhaltung-git}}<br />
|<br />
{{ic|~/.buchhaltung}}<br />
|<br />
| [https://github.com/johannesgerer/buchhaltung/issues/44]<br />
| {{ic|1=$ export BUCHHALTUNG="$XDG_CONFIG_HOME"/buchhaltung}}<br />
|-<br />
| [[Ruby#Bundler]]<br />
| {{ic|~/.bundle}}<br />
|<br />
| [https://github.com/bundler/bundler/pull/6024] [https://github.com/bundler/bundler/issues/4333]<br />
| {{ic|1=$ export BUNDLE_USER_CONFIG="$XDG_CONFIG_HOME"/bundle BUNDLE_USER_CACHE="$XDG_CACHE_HOME"/bundle BUNDLE_USER_PLUGIN="$XDG_DATA_HOME"/bundle}}<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 />
| [[ccache]]<br />
| {{ic|~/.ccache}}<br />
|<br />
| [https://github.com/ccache/ccache/issues/191]<br />
| {{ic|1=$ export CCACHE_CONFIGPATH="$XDG_CONFIG_HOME"/ccache.config}}<br><br />
{{ic|1=$ export CCACHE_DIR="$XDG_CACHE_HOME"/ccache}}<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<br><br />
~/.pki}}<br />
| [https://src.chromium.org/viewvc/chrome?revision=23057&view=revision 23057]<br />
|<br />
[https://groups.google.com/forum/#!topic/chromium-dev/QekVQxF3nho]<br />
[https://code.google.com/p/chromium/issues/detail?id=16976]<br />
[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 />
| [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 />
| {{AUR|flutter}}<br />
|<br />
{{ic|~/.flutter<br><br />
~/.flutter_settings<br><br />
~/.flutter_tool_state}}<br />
|<br />
| [https://github.com/flutter/flutter/issues/59430]<br />
|<br />
|-<br />
| {{Pkg|emscripten}}<br />
|<br />
{{ic|~/.emscripten<br><br />
~/.emscripten_sanity<br><br />
~/.emscripten_ports<br><br />
~/.emscripten_cache__last_clear}}<br />
|<br />
| [https://github.com/kripken/emscripten/issues/3624]<br />
|<br />
{{ic|1=$ export EM_CONFIG="$XDG_CONFIG_HOME"/emscripten/config<br><br />
$ export EM_CACHE="$XDG_CACHE_HOME"/emscripten/cache<br><br />
$ export EM_PORTS="$XDG_DATA_HOME"/emscripten/cache<br><br />
$ emcc --em-config "$XDG_CONFIG_HOME"/emscripten/config --em-cache "$XDG_CACHE_HOME"/emscripten/cache}}<br />
|-<br />
| {{Pkg|freecad}}<br />
| {{ic|~/.FreeCAD}}<br />
|<br />
| [https://www.freecadweb.org/tracker/view.php?id=2956]<br />
| {{ic|1=$ freecad -u "$XDG_CONFIG_HOME"/FreeCAD/user.cfg -s "$XDG_CONFIG_HOME"/FreeCAD/system.cfg}}<br />
<br />
Despite these options, {{Pkg|freecad}} will still create the file {{ic|.FreeCAD/cookie}} as the web module has it [https://github.com/FreeCAD/FreeCAD/blob/master/src/Mod/Web/Gui/CookieJar.cpp#L55 hard coded]<br />
|-<br />
| [[GDB]]<br />
| {{ic|~/.gdbinit}}<br />
|<br />
|<br />
| {{ic|1=$ gdb -nh -x "$XDG_CONFIG_HOME"/gdb/init}}<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 />
| {{AUR|gliv}}<br />
| {{ic|~/.glivrc}}<br />
|<br />
|<br />
| {{ic|1=$ gliv --glivrc="$XDG_CONFIG_HOME"/gliv/glivrc}}<br />
|-<br />
| [[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 />
|<br />
{{ic|1=$ export GNUPGHOME="$XDG_DATA_HOME"/gnupg<br><br />
$ gpg2 --homedir "$XDG_DATA_HOME"/gnupg}}<br><br />
Note that this currently does not work out-of-the-box using systemd user units and socket-based activation, since<br />
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}},<br />
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 />
|<br />
{{ic|1=$ export GOPATH="$XDG_DATA_HOME"/go}}<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 />
|<br />
{{ic|~/.gq<br><br />
~/.gq-state}}<br />
| [https://sourceforge.net/p/gqclient/mailman/message/2053978 1.51]<br />
|<br />
|<br />
{{ic|1=$ export GQRC="$XDG_CONFIG_HOME"/gqrc<br><br />
$ export GQSTATE="$XDG_DATA_HOME"/gq/gq-state<br><br />
$ 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 />
| {{AUR|imapfilter}}<br />
| {{ic|~/.imapfilter}}<br />
|<br />
|<br />
| {{ic|1=$ export IMAPFILTER_HOME="$XDG_CONFIG_HOME/imapfilter"}}<br />
|-<br />
| [http://ipython.org ipython]/[[jupyter]]<br />
| {{ic|~/.ipython}}<br />
|<br />
| [https://github.com/ipython/ipython/pull/4457 won't fix],[https://github.com/ipython/ipython/issues/12431 won't fix]<br />
|<br />
{{ic|1=$ export IPYTHONDIR="$XDG_CONFIG_HOME"/jupyter<br><br />
$ export JUPYTER_CONFIG_DIR="$XDG_CONFIG_HOME"/jupyter}}<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 />
|<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 />
| {{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}}<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 />
| [[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 />
| [[Core utilities|less]]<br />
| {{ic|~/.lesshst}}<br />
|<br />
|<br />
|<br />
{{ic|1=$ mkdir -p "$XDG_CACHE_HOME"/less<br><br />
$ export LESSKEY="$XDG_CONFIG_HOME"/less/lesskey<br><br />
$ export LESSHISTFILE="$XDG_CACHE_HOME"/less/history}}<br />
<br />
{{ic|1=$ export LESSHISTFILE=-}} can be used to disable this feature.<br />
|-<br />
| [[Leiningen]]<br />
| {{ic|~/.lein<br><br />
~/.m2}}<br />
|<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 />
| {{AUR|librewolf}}<br />
| {{ic|~/.mozilla}}<br />
{{ic|~/.librewolf}}<br />
|<br />
|<br />
|<br />
{{ic|1=$ mkdir $XDG_DATA_HOME/librewolf && mv librewolf.AppImage $XDG_DATA_HOME/librewolf<br><br />
$ $XDG_DATA_HOME/librewolf/librewolf.AppImage --appimage-portable-home<br><br />
$ sudo ln -s $XDG_DATA_HOME/librewolf/librewolf.AppImage /usr/local/bin/librewolf}}<br />
<br />
This is not a perfect solution - you will have to create symlinks to your downloads and other XDG directories to get the browser to use them properly. However, it is workable. Of course, you could do this in any directory, not just {{ic|$XDG_DATA_HOME}}<br />
|-<br />
| [[Xorg|libx11]]<br />
|<br />
{{ic|~/.XCompose<br><br />
~/.compose-cache}}<br />
|<br />
|<br />
|<br />
{{ic|1=$ export XCOMPOSEFILE="$XDG_CONFIG_HOME"/X11/xcompose<br><br />
$ 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|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 [http://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|mitmproxy}}<br />
| {{ic|~/.mitmproxy}}<br />
|<br />
|<br />
|<br />
{{ic|1=$ alias mitmproxy="mitmproxy --set confdir=$XDG_CONFIG_HOME/mitmproxy"<br><br />
$ alias mitmweb="mitmweb --set confdir=$XDG_CONFIG_HOME/mitmproxy"}}<br />
|-<br />
| [[MOC]]<br />
| {{ic|~/.moc}}<br />
|<br />
|<br />
|<br />
{{ic|1=$ mocp -M "$XDG_CONFIG_HOME"/moc<br><br />
$ 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 />
| [[MySQL]]<br />
|<br />
{{ic|~/.mysql_history<br><br />
~/.my.cnf <br><br />
~/.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|ncurses}}<br />
| {{ic|~/.terminfo}}<br />
|<br />
|<br />
| Precludes system path searching:<br />
<br />
{{ic|1=$ export TERMINFO="$XDG_DATA_HOME"/terminfo<br><br />
$ export TERMINFO_DIRS="$XDG_DATA_HOME"/terminfo:/usr/share/terminfo}}<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://netbeans.org/bugzilla/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 />
|<br />
| {{ic|1=$ export NODE_REPL_HISTORY="$XDG_DATA_HOME"/node_repl_history}} [https://nodejs.org/api/repl.html#repl_environment_variable_options]<br />
|-<br />
| [[notmuch]]<br />
| {{ic|~/.notmuch-config}}<br />
|<br />
| [http://notmuchmail.org/pipermail/notmuch/2011/007007.html]<br />
|<br />
{{ic|1=$ export NOTMUCH_CONFIG="$XDG_CONFIG_HOME"/notmuch/notmuchrc<br><br />
$ export NMBGIT="$XDG_DATA_HOME"/notmuch/nmbug}}<br />
|-<br />
| {{Pkg|npm}}<br />
|<br />
{{ic|~/.npm<br><br />
~/.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 />
tmp=${XDG_RUNTIME_DIR}/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 />
| {{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 />
|<br />
{{ic|~/octave<br><br />
~/.octave_packages<br><br />
~/.octave_hist}}<br />
|<br />
|<br />
|<br />
{{ic|1=$ export OCTAVE_HISTFILE="$XDG_CACHE_HOME/octave-hsts"<br><br />
$ 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] {{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 />
|<br />
{{ic|~/.psqlrc<br><br />
~/.psql_history<br><br />
~/.pgpass<br><br />
~/.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 />
|<br />
{{ic|1=$ export PSQLRC="$XDG_CONFIG_HOME/pg/psqlrc"<br><br />
$ export PSQL_HISTORY="$XDG_CACHE_HOME/pg/psql_history"<br><br />
$ export PGPASSFILE="$XDG_CONFIG_HOME/pg/pgpass"<br><br />
$ 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_CACHE_HOME/pg"}}<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 />
| {{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|python-pylint}}<br />
| {{ic|~/.pylint.d}}<br />
|<br />
| [https://github.com/PyCQA/pylint/issues/1364 won't fix]<br />
| {{ic|1=$ export PYLINTHOME="$XDG_CACHE_HOME"/pylint}}<br />
|-<br />
| {{Pkg|racket}}<br />
| {{ic|~/.racketrc<br><br />
~/.racket}}<br />
|<br />
| [https://github.com/racket/racket/issues/2740]<br />
| {{ic|1=$ export PLTUSERHOME="$XDG_DATA_HOME"/racket}}<br />
|-<br />
| [[readline]]<br />
| {{ic|~/.inputrc}}<br />
|<br />
|<br />
| {{ic|1=$ export INPUTRC="$XDG_CONFIG_HOME"/readline/inputrc}}<br />
|-<br />
| [[redis]]<br />
|<br />
{{ic|~/.rediscli_history<br><br />
~/.redisclirc}}<br />
|<br />
|<br />
|{{ic|1=$ export REDISCLI_HISTFILE="$XDG_DATA_HOME"/redis/rediscli_history<br><br />
$ export REDISCLI_RCFILE="$XDG_CONFIG_HOME"/redis/redisclirc}}<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 />
| [[Ruby#RubyGems]]<br />
| {{ic|~/.gem}}<br />
|<br />
|<br />
|<br />
{{ic|1=$ export GEM_HOME="$XDG_DATA_HOME"/gem<br><br />
$ export GEM_SPEC_CACHE="$XDG_CACHE_HOME"/gem}}<br />
<br />
Make sure to remove {{ic|gem: --user-install}} from {{ic|/etc/gemrc}}<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 />
| {{Pkg|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://spacemacs.org/ spacemacs]<br />
|<br />
{{ic|~/.spacemacs<br><br />
~/.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<br><br />
$ 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 />
| [[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][http://mail-archives.apache.org/mod_mbox/subversion-dev/201509.mbox/%3c20150917222954.GA20331@teapot%3e]<br />
| {{ic|1=$ svn --config-dir "$XDG_CONFIG_HOME"/subversion}}<br />
|-<br />
| {{Pkg|task}}<br />
|<br />
{{ic|~/.task<br><br />
~/.taskrc}}<br />
|<br />
|<br />
|<br />
{{ic|1=$ export TASKDATA="$XDG_DATA_HOME"/task<br><br />
$ export TASKRC="$XDG_CONFIG_HOME"/task/taskrc}}<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 />
|<br />
{{ic|1=$ export TEXMFHOME=$XDG_DATA_HOME/texmf<br><br />
$ export TEXMFVAR=$XDG_CACHE_HOME/texlive/texmf-var<br><br />
$ export TEXMFCONFIG=$XDG_CONFIG_HOME/texlive/texmf-config}}<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 />
| {{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 />
| {{Pkg|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 />
|<br />
{{ic|~/.vagrant.d<br><br />
~/.vagrant.d/aliases}}<br />
|<br />
| [https://www.vagrantup.com/docs/other/environmental-variables.html]<br />
|<br />
{{ic|1=$ export VAGRANT_HOME="$XDG_DATA_HOME"/vagrant<br><br />
$ 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/argv.json}}<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 />
|-<br />
| [[AUR|WakaTime]]<br />
|<br />
{{ic|~/.wakatime.cfg<br><br />
~/.wakatime.data<br><br />
~/.wakatime.db<br><br />
~/.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 />
| [[WeeChat]]<br />
| {{ic|~/.weechat}}<br />
|<br />
| [http://savannah.nongnu.org/task/?10934] [https://github.com/ipython/ipython/pull/4457]<br />
|<br />
{{ic|1=$ export WEECHAT_HOME="$XDG_CONFIG_HOME"/weechat<br><br />
$ weechat -d "$XDG_CONFIG_HOME"/weechat}}<br />
|-<br />
| [[wget]]<br />
|<br />
{{ic|~/.wgetrc<br><br />
~/.wget-hsts}}<br />
|<br />
|<br />
|<br />
{{ic|1=$ export WGETRC="$XDG_CONFIG_HOME/wgetrc"<br><br />
and add the following as an alias for wget:<br><br />
$ wget --hsts-file="$XDG_CACHE_HOME/wget-hsts"<br><br />
or set the hsts-file variable with an absolute path as wgetrc does not support environment variables:<br><br />
$ 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<br><br />
$ 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 />
| [[xinit]]<br />
|<br />
{{ic|~/.xinitrc<br><br />
~/.xserverrc}}<br />
|<br />
| [https://gitlab.freedesktop.org/xorg/app/xinit/issues/14]<br />
|<br />
{{ic|1=$ export XINITRC="$XDG_CONFIG_HOME"/X11/xinitrc<br><br />
$ export XSERVERRC="$XDG_CONFIG_HOME"/X11/xserverrc}}<br />
<br />
Note that these variables are respected by ''xinit'', but not by ''startx''. Instead, specify the filename as an argument:<br />
<br />
{{ic|1=$ startx "$XDG_CONFIG_HOME/X11/xinitrc" -- "$XDG_CONFIG_HOME/X11/xserverrc" vt1}}<br />
|-<br />
| {{Pkg|xorg-xrdb}}<br />
|<br />
{{ic|~/.Xresources<br><br />
~/.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 />
|<br />
{{ic|~/.xsession<br><br />
~/.xsessionrc<br><br />
~/.Xsession<br><br />
~/.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 made 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 />
|<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 />
|<br />
{{ic|~/.yarnrc<br><br />
~/.yarn/<br><br />
~/.yarncache/<br><br />
~/.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 />
| [https://developer.android.com/studio/command-line/variables.html#android_sdk_root]<br />
| {{ic|1=$ export ANDROID_PREFS_ROOT="$XDG_CONFIG_HOME"/android}} {{ic|1=$ export ADB_KEYS_PATH="$ANDROID_PREFS_ROOT"}}<br />
{{ic|1=$ export ANDROID_EMULATOR_HOME="$XDG_DATA_HOME"/android/emulator}}<br />
|-<br />
| [[Ansible]]<br />
| {{ic|~/.ansible}}<br />
| [https://github.com/ansible/ansible/issues/52354] [https://github.com/ansible/ansible/issues/68587]<br />
|<br />
|-<br />
| [[AMule]]<br />
| {{ic|~/.aMule}}<br />
|<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 />
|<br />
|<br />
|-<br />
| [[Arduino]]<br />
|<br />
{{ic|~/.arduino15<br><br />
~/.jssc}}<br />
| [https://github.com/arduino/Arduino/issues/3915 won't fix] [https://github.com/arduino/Arduino/issues/10486]<br />
|<br />
<br />
|-<br />
| [https://www.audacityteam.org/ Audacity]<br />
| {{ic|~/.audacity-data/}}<br />
| [https://bugzilla.audacityteam.org/show_bug.cgi?id=2201]<br />
|<br />
<br />
|-<br />
| [http://fixounet.free.fr/avidemux/ Avidemux]<br />
| {{ic|~/.avidemux6}}<br />
|<br />
|<br />
<br />
|-<br />
| [[Bash]]<br />
|<br />
{{ic|~/.bashrc<br><br />
~/.bash_history<br><br />
~/.bash_profile<br><br />
~/.bash_login<br><br />
~/.bash_logout}}<br />
| [https://savannah.gnu.org/support/?108134 won't fix]<br />
| {{ic|1=$ mkdir -p "$XDG_DATA_HOME"/bash}}<br />
{{ic|1=$ export HISTFILE="$XDG_DATA_HOME"/bash/history}}<br />
A specified {{ic|bashrc}} can be sourced from {{ic|/etc/bash.bashrc}}.<br />
<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 />
| [https://www.haskell.org/cabal/ cabal]<br />
| {{ic|~/.cabal/}}<br />
| [https://github.com/haskell/cabal/issues/680]<br />
| See discussion for potential workarounds. It is not very easy or straightforward but may be possible to emulate Base Directory compliance.<br />
|-<br />
| {{AUR|chatty}}<br />
| {{ic|~/.chatty/}}<br />
| [https://github.com/chatty/chatty/issues/273]<br />
|<br />
|-<br />
| {{Pkg|cmake}}<br />
| {{ic|~/.cmake/}}<br />
|<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 />
|<br />
|-<br />
| {{AUR|cryptomator}}<br />
| {{ic|~/.Cryptomator}}<br />
| [https://github.com/cryptomator/cryptomator/issues/710]<br />
|<br />
|-<br />
| [[CUPS]]<br />
| {{ic|~/.cups/}}<br />
| [https://github.com/apple/cups/issues/4243 won't fix]<br />
|<br />
|-<br />
| [[darcs]]<br />
| {{ic|~/.darcs/}}<br />
| [http://bugs.darcs.net/issue2453]<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 />
| [http://www.fetchmail.info/ Fetchmail]<br />
| {{ic|~/.fetchmailrc}}<br />
|<br />
|<br />
|-<br />
| [[Firefox]]<br />
| {{ic|~/.mozilla/}}<br />
| [https://bugzil.la/259356]<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 />
| {{Pkg|fltk}}<br />
| {{ic|~/.fltk/}}<br />
| [https://www.fltk.org/str.php?L3370+P0+S0+C0+I0+E0+V%25+Qxdg]<br />
|<br />
|-<br />
| [https://github.com/rwestlund/freesweep freesweep]<br />
| {{ic|~/.sweeprc}}<br />
| [https://github.com/rwestlund/freesweep/issues/9]<br />
|<br />
|-<br />
| {{Pkg|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 />
| [https://www.haskell.org/ghc/ GHC]<br />
| {{ic|~/.ghc}}<br />
| [https://ghc.haskell.org/trac/ghc/ticket/6077]<br />
|<br />
|-<br />
| {{Pkg|ghidra}}<br />
|<br />
| [https://github.com/NationalSecurityAgency/ghidra/issues/908]<br />
|<br />
|-<br />
| [[GoldenDict]]<br />
| {{ic|~/.goldendict/}}<br />
| [https://github.com/goldendict/goldendict/issues/151]<br />
|<br />
|-<br />
| {{Pkg|gramps}}<br />
| {{ic|~/.gramps/}}<br />
| [https://gramps-project.org/bugs/view.php?id=8025]<br />
|<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-sdk}}<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 />
| {{AUR|kite}}<br />
| {{ic|~/.kite/}}<br />
| [https://github.com/kiteco/issue-tracker/issues/242]<br />
|<br />
|-<br />
| [[Kubernetes]]<br />
| {{ic|~/.kube/}}<br />
| [https://github.com/kubernetes/kubectl/issues/942][https://github.com/kubernetes/kubernetes/issues/56402]<br />
|<br />
|-<br />
| {{Pkg|hplip}}<br />
| {{ic|~/.hplip/}}<br />
| [https://bugs.launchpad.net/hplip/+bug/307152]<br />
|<br />
|-<br />
| [http://www.idris-lang.org/ idris]<br />
| {{ic|~/.idris}}<br />
| [https://github.com/idris-lang/Idris-dev/pull/3456]<br />
|<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 />
| [http://julialang.org/ julia]<br />
|<br />
{{ic|~/.juliarc.jl<br><br />
~/.julia_history<br><br />
~/.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 />
| [http://www.linux-pam.org/ Linux PAM]<br />
| {{ic|~/.pam_environment}}<br />
| [https://github.com/linux-pam/linux-pam/issues/7]<br />
| Hardcoded in [https://github.com/linux-pam/linux-pam/blob/master/modules/pam_env/pam_env.c modules/pam_env/pam_env.c]<br />
|-<br />
| [http://lldb.llvm.org/ lldb]<br />
|<br />
{{ic|~/.lldb<br><br />
~/.lldbinit}}<br />
|<br />
|<br />
|-<br />
| [http://www.mathomatic.org/ mathomatic]<br />
|<br />
{{ic|~/.mathomaticrc<br><br />
~/.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]<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 />
| <br />
|<br />
|-<br />
| [https://www.mongodb.org/ mongodb]<br />
|<br />
{{ic|~/.mongorc.js<br><br />
~/.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 />
| [http://0ldsk00l.ca/nestopia/ Nestopia UE]<br />
| {{ic|~/.nestopia/}}<br />
| [https://github.com/0ldsk00l/nestopia/pull/292 won't fix]<br />
|<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 />
|<br />
| Hardcoded to {{ic|g_get_home_dir()}}[https://developer.gnome.org/glib/stable/glib-Miscellaneous-Utility-Functions.html#g-get-home-dir] [https://github.com/freedesktop/NetworkManager/blob/master/clients/cli/connections.c#L6575]<br />
|-<br />
| [[Networkmanager-openvpn]]<br />
| {{ic|~/.cert/nm-openvpn}}<br />
| [https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/issues/35]<br />
|<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 />
| [[PCManFM]]<br />
| {{ic|~/.thumbnails}}<br />
| [https://github.com/lxde/libfm/issues/57]<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/master/tools/perf/util/config.c#L29 tools/perf/util/config.c:29].<br />
|-<br />
| [[perl]]<br />
| {{ic|~/.cpan}}<br />
|<br />
| Perl5's [https://github.com/andk/cpanpm CPAN] expects {{ic|~/.cpan}}.<br />
|-<br />
| various [[shell]]s and [[display manager]]s<br />
| {{ic|~/.profile}}<br />
|<br />
|<br />
|-<br />
| [[PuTTY]]<br />
| {{ic|~/.putty/}}<br />
|<br />
| [https://www.chiark.greenend.org.uk/~sgtatham/putty/faq.html#faq-settings]<br />
|-<br />
| [[python]]<br />
| {{ic|~/.python_history}}<br />
| [https://bugs.python.org/issue29779] [https://bugs.python.org/issue20886]<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 />
| {{Pkg|python-poetry}}<br />
| {{ic|~/.poetry}}<br />
| [https://github.com/python-poetry/poetry/issues/2148]<br />
| {{ic|POETRY_HOME}} can be used but it does not separate data and config.<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 />
|<br />
|-<br />
| [http://rednotebook.sourceforge.net/ RedNotebook]<br />
| {{ic|~/.rednotebook}}<br />
|<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 />
| [[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 />
| {{Pkg|scribus}}<br />
| {{ic|~/.scribus}}<br />
|<br />
|<br />
|-<br />
| [http://www.seamonkey-project.org/ SeaMonkey]<br />
| {{ic|~/.mozilla/}}<br />
| [https://bugzil.la/726939]<br />
|<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 />
|<br />
{{ic|~/.solfege<br><br />
~/.solfegerc<br><br />
~/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 />
|<br />
{{ic|~/.sqlite_history<br><br />
~/.sqliterc}}<br />
| [https://www.sqlite.org/src/info/696e82f7c82d1720]<br />
| {{ic|1=$ export SQLITE_HISTORY=$XDG_DATA_HOME/sqlite_history<br><br />
$ sqlite3 -init "$XDG_CONFIG_HOME"/sqlite3/sqliterc}}<br />
|-<br />
| [[Steam]]<br />
|<br />
{{ic|~/.steam<br><br />
~/.steampath<br><br />
~/.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 />
| [[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 />
| [http://www.texmacs.org/ TeXmacs]<br />
| {{ic|~/.TeXmacs}}<br />
|<br />
|<br />
|-<br />
| [[Thunderbird]]<br />
| {{ic|~/.thunderbird/}}<br />
| [https://bugzil.la/735285]<br />
|<br />
|-<br />
| [[TigerVNC]]<br />
| {{ic|~/.vnc}}<br />
|<br />
|<br />
|-<br />
| [https://git.archlinux.org/users/remy/texlive-localmanager.git/ tllocalmgr]<br />
| {{ic|~/.texlive}}<br />
|<br />
|<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 />
|<br />
{{ic|~/.vim<br><br />
~/.vimrc<br><br />
~/.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|<br />
set runtimepath^&#61;$XDG_CONFIG_HOME/vim<br />
set runtimepath+&#61;$XDG_DATA_HOME/vim<br />
set runtimepath+&#61;$XDG_CONFIG_HOME/vim/after<br />
<br />
set packpath^&#61;$XDG_DATA_HOME/vim,$XDG_CONFIG_HOME/vim<br />
set packpath+&#61;$XDG_CONFIG_HOME/vim/after,$XDG_DATA_HOME/vim/after<br />
<br />
let g:netrw_home &#61; $XDG_DATA_HOME."/vim"<br />
call mkdir($XDG_DATA_HOME."/vim/spell", 'p')<br />
set viewdir&#61;$XDG_DATA_HOME/vim/view &#124; call mkdir(&viewdir, 'p')<br />
<br />
set backupdir&#61;$XDG_CACHE_HOME/vim/backup &#124; call mkdir(&backupdir, 'p')<br />
set directory&#61;$XDG_CACHE_HOME/vim/swap &#124; call mkdir(&directory, 'p')<br />
set undodir&#61;$XDG_CACHE_HOME/vim/undo &#124; call mkdir(&undodir, 'p')<br />
<br />
if !has('nvim') &#124; set viminfofile&#61;$XDG_CACHE_HOME/vim/viminfo &#124; endif<br />
}}<br />
<br />
{{hc|~/.profile|2=<br />
export VIMINIT='source "$XDG_CONFIG_HOME/vim/vimrc"'<br />
}}<br />
<br />
{{ic|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 VIMINIT='if !has('nvim') | source "$XDG_CONFIG_HOME/vim/vimrc" | endif'<br />
<br />
* https://tlvince.com/vim-respect-xdg<br />
* https://blog.joren.ga/tools/vim-xdg<br />
|-<br />
| [http://www.vimperator.org/ vimperator]<br />
| {{ic|~/.vimperatorrc}}<br />
| [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 />
| {{AUR|visidata}}<br />
| {{ic|~/.visidata}}<br />
| [https://github.com/saulpw/visidata/issues/487]<br />
| <br />
|-<br />
| {{Pkg|w3m}}<br />
| {{ic|~/.w3m}}<br />
| [https://sourceforge.net/p/w3m/feature-requests/31/] [https://github.com/tats/w3m/issues/130]<br />
|<br />
|-<br />
| [https://w1.fi/ wpa_cli]<br />
| {{ic|~/.wpa_cli_history}}<br />
|<br />
|<br />
|-<br />
| {{Pkg|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|gnome_user_dir&#61;"$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 />
| [https://opensource.conformal.com/wiki/xombrero xombrero]{{Dead link|2020|02|26}}<br />
| {{ic|~/.xombrero}}<br />
| [https://github.com/conformal/xombrero/issues/74]{{Dead link|2020|02|26}}<br />
|<br />
|-<br />
| {{Pkg|xournalpp}}<br />
| {{ic|~/.xournalpp}}<br />
| [https://github.com/xournalpp/xournalpp/issues/1101]<br />
| XDG will be honored in the next version [https://github.com/xournalpp/xournalpp/pull/1384]<br />
|-<br />
| {{Pkg|xpdf}}<br />
| {{ic|~/.xpdfrc}}<br />
|<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 />
| [http://seclists.org/nmap-dev/2012/q2/163] [https://github.com/nmap/nmap/issues/590]<br />
|<br />
|-<br />
| {{AUR|zoom}}<br />
| {{ic|~/.zoom}}<br />
|<br />
|<br />
|-<br />
| {{AUR|zotero}}<br />
| {{ic|~/.zotero}} {{ic|~/Zotero}}<br />
| [https://github.com/zotero/zotero/issues/1203]<br />
|<br />
|-<br />
| [[zsh]]<br />
|<br />
{{ic|~/.zshrc<br><br />
~/.zprofile<br><br />
~/.zshenv<br><br />
~/.zlogin<br><br />
~/.zlogout<br><br />
~/.histfile<br><br />
~/.zcompdump}}<br />
| [http://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_DATA_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 />
|}<br />
<br />
== Libraries ==<br />
<br />
; C<br />
: [https://github.com/Jorengarenar/libXDGdirs libXDGdirs]<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/ProtonMail/go-appdir go-appdir]<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 />
: [http://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/rubyworks/xdg rubyworks/xdg]<br />
<br />
; Rust<br />
: [https://github.com/soc/directories-rs directories-rs]<br />
: [https://github.com/whitequark/rust-xdg rust-xdg]<br />
<br />
; Vala<br />
: Builtin support via [http://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>Geshhttps://wiki.archlinux.org/index.php?title=Talk:VCS_package_guidelines&diff=646087Talk:VCS package guidelines2020-12-20T15:22:56Z<p>Gesh: forgot to sign</p>
<hr />
<div>== Numeric vs Date Standard in Git pkgver ==<br />
<br />
I'd like to see a standard emerge in AUR Git packages, but standards have to work down to the lowest common denominator. Only a small minority of GitHub projects properly tag their releases, so there can be only two LCD standards for Git packages: the Numeric standard, e.g. ("r1581.2b039da") and the Date standard, e.g. ("2014-01-01"). The date standard is much more readable, and actionable, and has the additional benefit of being backwards compatible with older Git packages.<br />
<br />
I don't know if any standard can emerge even if we wanted it to, but please allow me to at least add the Date standard to the VCS package guidelines wiki (as opposed to scrubbing it, :).<br />
<br />
:Using the commit date would be incorrect because it doesn't refer to a specific commit and the dates are not always sequential. It would be even more wrong if it was the build date, as that doesn't refer to anything to do with the version. -- [[User:thestinger|thestinger]] 21:33, 23 January 2015 (UTC)<br />
<br />
::''it doesn't refer to a specific commit''<br />
::<br />
::Neither does "r1581.2b039da" refer to a specific commit without the .git repo cmdline interaction, and it is considered best practice to prune $pkgdir of .git:<br />
::<br />
find "$pkgdir" -type d -name .git -exec rm -r '{}' +<br />
::<br />
::Can you explain what you mean by "the dates are not always sequential"? The Date standard looks like this:<br />
::<br />
git log -1 --format="%cd" --date=short | sed "s|-||g"<br />
::<br />
::It displays the latest commit date from the upstream Git repo.<br />
::<br />
::In the edge case of breaking changes occurring upstream in Git repos on the same day, then package maintainers should increment pkgrel. In practice, "2014-01-01" is much more readable and useful than "r1581.2b039da". The readability benefits of "2014-01-01" vs. "r1581.2b039da" should not be underestimated due to edge cases. --[[User:Atweiden|Atweiden]] ([[User talk:Atweiden|talk]]) 18:39, 24 January 2015 (UTC)<br />
:::A git commit id certainly refers to a specific commit. I don't know why you think this has anything to do with shipping the VCS repository in the package. The commit date of the most recent commit may be from 20 weeks ago while the earlier commits were from last week. Git does not have a linear history. It's not going to be changed to use a version format where it can go both backwards and forwards with no way of tracing it back to the commit. Readability is worthless if the information isn't meaningful... There are 2 hard requirements: newer revisions must have higher package versions without exceptions, and it must be possible to trace it back to a commit to properly identify and report bugs. -- [[User:thestinger|thestinger]] 18:53, 24 January 2015<br />
:::<br />
::::<br />
::::I am quite certain of what a commit ID looks like, e.g. 2d5749d0315a59f4a8bf73ebbe757b227c8c17a3, not r1581.2b039da.<br />
::::<br />
::::Can you show me where to find "r1581.2b039da" on a GitHub/BitBucket repo? It doesn't exist anywhere that I can see. You need to have the repo locally, then cd into the Git repo and run:<br />
::::<br />
git rev-list --count HEAD<br />
::::<br />
::::That is work-intensive, and it conflicts with the best practice of pruning AUR packages of .git repos.<br />
::::<br />
::::I previously used the Wiki-recommended Numeric standard, so it's not like I haven't used it. I switched to the Date standard, updating hundreds of packages to reflect it. Why do you suppose that is?<br />
::::<br />
:::: ''Readability is worthless if the information isn't meaningful''<br />
::::You'd be hard pressed to convince me that the date "2014-01-01" is somehow *less* semantically meaningful or actionable than "r1581". I say this after maintaining for years, hundreds of Git packages in the AUR. You can tell by grepping `pacman -Q` exactly which AUR git packages are out of date with a two-second visit to GitHub. The Date standard is incredibly actionable and pragmatic not to mention simple and immediately understandable by anyone.<br />
::::<br />
:::: ''newer revisions must have higher package versions without exceptions''<br />
::::<br />
::::Not a problem: "2014-01-01" < "2014-01-02"<br />
::::<br />
:::: ''it must be possible to trace it back to a commit to properly identify and report bugs''<br />
::::<br />
:::: Given how frequently "stable" Go packages and C packages pull in Git dependencies as part of their build process without specifying a certain commit, I disagree with this proposition. Why would recording the version of acmedaemon as 1.5, when it pulls in Git packages without specifying commit ID, be all that different in bug reports than "2014-01-01"? In both cases, you will not be able to track down the exact cause of the bug by commit. In both cases, you will in all likelihood end up consulting the build date. --[[User:Atweiden|Atweiden]] ([[User talk:Atweiden|talk]]) 03:32, 25 January 2015 (UTC)<br />
<br />
:::::''I am quite certain of what a commit ID looks like, e.g. 2d5749d0315a59f4a8bf73ebbe757b227c8c17a3, not r1581.2b039da.''<br />
:::::In your scenerio, 2b039da is the short version of the commit hash and does point to a specific commit. As for where you find it on Github, it's listed on the commit log, of course. Just look at the right hand side of the page.<br />
:::::''You'd be hard pressed to convince me that the date "2014-01-01" is somehow *less* semantically meaningful or actionable than "r1581".''<br />
:::::In this case, human readability really is meaningless. Machine readability is all that matters.<br />
:::::''Not a problem: "2014-01-01" < "2014-01-02"''<br />
:::::And what happens when the commit after that is dated 2013-12-31? As thestinger pointed out, Git is not linear.<br />
:::::[[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 03:40, 25 January 2015 (UTC)<br />
<br />
::::::''2b039da is the short version of the commit hash''<br />
::::::<br />
::::::Can this information be easily compared on GitHub to your local package version to check if it is out of date? The answer is no.<br />
::::::<br />
::::::It is not actionable, except by cloning the repo yourself, running the Git command, and then manually scanning the Git log for short versions. It's very work-intensive.<br />
::::::<br />
::::::''Git is not linear''<br />
::::::<br />
::::::Neither are stable packages on PyPi: https://pypi.python.org/pypi/tackpy/0.9.9a<br />
::::::<br />
::::::Pacman views the upgrade of 0.9.9 -> 0.9.9a as a downgrade. See https://aur.archlinux.org/packages/python2-tackpy for a real world example of this edge case. Edge cases should be no reason to prevent readers of the wiki to make informed choices about Git packaging standards. --[[User:Atweiden|Atweiden]] ([[User talk:Atweiden|talk]]) 04:08, 25 January 2015 (UTC)<br />
<br />
:::::::Yes, the short hash of each commit is listed in the commit log. Also note that the revision count (the "r" number listed first) is also listed at the top of each repo's page.<br />
:::::::As for PyPi's versioning scheme, their choice is different than what Arch's vercmp assumes. The packager needs to take this into account, just as all packagers must take upstream's idiosyncrasies into account. I don't see how it's relevant here.<br />
:::::::You also never answered my question, what happens when the last commit is dated before the commit previous to it? This question is critical, as it would cause your versioning scheme to go backwards by any and all measures. That makes it unacceptable.<br />
:::::::[[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 04:15, 25 January 2015 (UTC)<br />
<br />
::::::::Incorrect.<br />
::::::::<br />
printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)<br />
::::::::<br />
::::::::The output of the above command does not correspond to any piece of information on GitHub.<br />
::::::::<br />
::::::::If PyPi packagers should take edge cases into account for PyPi packages, then they should do the same for Git packages. Edge cases aren't reason enough to scrub a competing standard from the wiki. --[[User:Atweiden|Atweiden]] ([[User talk:Atweiden|talk]]) 04:23, 25 January 2015 (UTC)<br />
<br />
:::::::::I'm sorry if you can't find this information on GitHub. It's very, very plainly displayed in the places I already pointed you to. If you would take a minute to check instead of just jumping at me, you might find it.<br />
:::::::::[[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 04:31, 25 January 2015 (UTC)<br />
<br />
::::::::::''the short hash of each commit is listed in the commit log. Also note that the revision count (the "r" number listed first) is also listed at the top of each repo's page''.<br />
::::::::::<br />
::::::::::This is (partially) incorrect. The short hash of each commit is not listed. What is listed in the commit log is the truncated commit ID.<br />
::::::::::<br />
::::::::::The revision count point I will retract. It didn't appear to work for my own Git repos, but that was because I ran the command from a Git subrepo (edge case :). The date still has the advantage of being more human readable than r1582. If a package has version 2011-10-22, I will know this project is either unmaintained, or it's been a really long time since I last rebuilt it. All without leaving the terminal. --[[User:Atweiden|Atweiden]] ([[User talk:Atweiden|talk]]) 07:33, 25 January 2015 (UTC)<br />
<br />
::::::::::It's also very easy to look up or link to commits via the abbreviated commit hashes or proper identifiers produced by {{ic|git describe}}. -- [[User:thestinger|thestinger]] 04:33, 25 January 2015 (UTC)<br />
<br />
::::::That has nothing to do with non-linear history. It has to do with an incompatibility between Pacman's version comparison and the one chosen by the project. There are ways of dealing with that, but it has nothing to do with this discussion. -- [[User:thestinger|thestinger]] 04:24, 25 January 2015 (UTC)<br />
<br />
:::::The ideal version is the one produced by {{ic|git describe}}, because it's easily understood by humans (last tag, commits since last tag, abbreviated commit), is also understood by the various Git commands and GitHub and is monotonically increasing thanks to the inclusion of the last version and revision count since then. The versions it produces ({{ic|10-7-g8537989}}) can be directly used with commands like {{ic|git show}}. Unlike the build date, it identifies a unique revision of the project, including the state of any submodules.<br />
<br />
:::::The only case where another method should be used is when the project doesn't yet have any tagged release or does the releases in a way that's not very sane. The releases ''should'' be tagged on master with additional tags in stable branches for fixes backported to old releases. If this isn't the case, the {{ic|git describe}} output needs to be emulated. A date is a poor way of doing that, because it's not connected to a specific point in the revision history.<br />
<br />
:::::The only case where the commit date would work is if Git is being used as a crippled centralized version control system. If all commits get created against master (no merging branches or patches) in a centralized repository where the system clock is never moved backwards, it could work... but that's not the reality of non-linear, distributed version control.<br />
<br />
:::::A build date is even worse, because it only refers to the local state of time and the local state of the repository. Commits from before that timestamp will often be pushed to the repository.<br />
<br />
:::::-- [[User:thestinger|thestinger]] 04:24, 25 January 2015 (UTC)<br />
<br />
::::::A packaging standard must be compatible with the lowest common denominator. A minority of Git repos are properly tagged. The Date works as a standard, tags do not.<br />
::::::<br />
git log -1 --format="%cd" --date=short | sed "s|-||g"<br />
::::::<br />
::::::The output of the above command shows the date of the most recent commit. If the most recent commit date happens to come before the date of a previous commit, I do understand this is suboptimal, but I consider it an edge case. Even in big projects with contributors in different time zones you will typically see branches merged in with PRs. PRs reset the date to something recent. The linearity of Git is rarely problematic, but I do see where you're coming from (I'm also a happy user of archversion for keeping packages up to date, though archversion works with the Date standard too :) --[[User:Atweiden|Atweiden]] ([[User talk:Atweiden|talk]]) 04:59, 25 January 2015 (UTC)<br />
<br />
:::::::The {{ic|git describe}} versioning system is the standard defined and used by Git itself. The dashes need to be converted into dots for {{ic|pkgver}} and an {{ic|r}} ''may'' be inserted to make it clearer which part is the revision number. If version-based tags on master are available, this is the only sane way to do it.<br />
<br />
:::::::Git defaults to fast-forwarding / applying patches without merge commits, as long as there are no conflicts. GitHub will ''always'' generate a merge commit but that's not true for anything applied / merged by the developers and then pushed to master. -- [[User:thestinger|thestinger]] 05:24, 25 January 2015 (UTC)<br />
<br />
:::::::You've made the claim that most git repos aren't properly tagged, not only now but to me previously. Do you have anything to back that up? IME, the large majority of projects that are in a usable state are either tagged or get tagged as they become stable.<br />
:::::::[[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 05:27, 25 January 2015 (UTC)<br />
<br />
::::::::OK:<br />
::::::::<br />
git init<br />
::::::::<br />
::::::::You now have your very own untagged Git repo :).<br />
::::::::<br />
::::::::The majority of Git repos are untagged. If you want to have a standard compatible with the lowest common denominator, by definition you cannot depend on tags being there.<br />
::::::::<br />
::::::::I regularly package Git software in the alpha stages and software maintained by people who are unfamiliar with tagging or aren't bothered to tag. --[[User:Atweiden|Atweiden]] ([[User talk:Atweiden|talk]]) 07:15, 25 January 2015 (UTC)<br />
<br />
::::As suggested in [[VCS package guidelines#Fallback]], I think the only date that can be used is the build date: for example I've recently used it in [https://aur.archlinux.org/packages/te/textadept-common-git/PKGBUILD a PKGBUILD] for a repo without tags or branches, also appending the first 7 characters of the commit hash (the repo is not cloned, so I could only use ''git-ls-remote''). — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:30, 25 January 2015 (UTC)<br />
<br />
== Updating a CVS repo ==<br />
<br />
I don't use cvs. How can you describe the pkgver for cvs (for pacman 4.1)? <br><br />
-- [[User:Dracorp|Dracorp]] ([[User talk:Dracorp|talk]]) 09:31, 6 April 2013 (UTC)<br />
<br />
:CVS is not supported in pacman 4.1 like the other VCS tools. You will need to update pkgver manually until CVS support is added.<br />
:-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 22:44, 15 April 2013 (UTC)<br />
<br />
::Yeah, but how about mentioning that in the article (as well as giving a download example)? Even if it's not that common anymore.<br />
::--[[User:Det|Det]] ([[User talk:Det|talk]]) 22:39, 2 May 2013 (UTC)<br />
<br />
:::The download example can still be found in {{ic|/usr/share/pacman/}}. The next version of the ABS package should update it a bit so the download happens in the prepare function where it belongs. As for pkgver, I think the generic example using date covers that, as there's not a way to get a version number from a CVS repo. Maybe a note to that effect?<br />
::: -- [[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 07:17, 15 May 2013 (UTC)<br />
<br />
::::That makes the most sense, but it might also be a good idea to rename the [[VCS PKGBUILD Guidelines#Fallback|"Fallback"]] section to something like "Fallback / CVS" to make it more obvious even when you're just checking out the table of contents.<br />
<br />
::::But as for ABS, as far as I can tell the last commit was over [https://projects.archlinux.org/abs.git/log/ 8 months] ago.<br />
::::--[[User:Det|Det]] ([[User talk:Det|talk]]) 05:54, 19 May 2013 (UTC)<br />
<br />
:::::Hmm, there were a number of patches submitted last month for cleaning up the prototypes, looks like none have been committed yet. I do remember a discussion (IRC maybe?) questioning the proper place for the prototypes, so maybe that's why? Looking at the patches, I was mistaken anyway; they didn't update the darcs or cvs prototypes. Simple enough, I'll send in a patch myself.<br />
:::::--[[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 08:22, 19 May 2013 (UTC)<br />
<br />
: I use this dirty hack: {{ic|<nowiki>cvs history -c -a | cut -d' ' -f2 | sort -u | tail -n 1 | sed 's|-||g"</nowiki>}} ; could probably be improved.<br />
:--[[User:Buhman|Buhman]] ([[User talk:Buhman|talk]]) 18:00, 6 June 2013 (UTC)<br />
<br />
<br />
== pkgver function for hg based on tags ==<br />
<br />
I recent came across a way with hg to show the most recent tag, as well as the number of commits from this tag (similar to the output of {{ic|git describe}}.) <br />
<br />
{{hc|<nowiki>pkgver() {<br />
cd local_repo<br />
hg log -r . --template '{latesttag}.{latesttagdistance}.{node|short}\n'<br />
}</nowiki>|<br />
3.0.1.40.ee9a2543fcd6<br />
}}<br />
<br />
Please could this be included in the page.<br />
<br />
[[User:Garyvdm|Garyvdm]] ([[User talk:Garyvdm|talk]]) 09:03, 23 July 2013 (UTC)<br />
<br />
== shorten hg version ==<br />
<br />
To prevent long package file name,<br />
It is proper to use this format<br />
<br />
{{bc|<nowiki>pkgver() {<br />
cd $_repo<br />
_id=$(hg identify -i)<br />
echo $(hg identify -n).${_id:0:4}<br />
}</nowiki><br />
}}<br />
--[[User:Dlin|Dlin]] ([[User talk:Dlin|talk]]) 05:30, 26 August 2013 (UTC)<br />
<br />
== fossil ==<br />
<br />
{{bc|<nowiki>pkgver() {<br />
cd local_repo<br />
_id=$(cat manifest.uuid 2>/dev/null)<br />
echo ${_id:0:4}<br />
}</nowiki><br />
}}<br />
--[[User:Dlin|Dlin]] ([[User talk:Dlin|talk]]) 05:36, 26 August 2013 (UTC)<br />
<br />
== set -o pipefail ==<br />
<br />
[https://wiki.archlinux.org/index.php?title=VCS_package_guidelines&diff=prev&oldid=363918 This change] mentioned {{ic|set -o ...}} as one of the reasons for reverting, nevertheless one example using {{ic|set -o pipefail}} still remains: [[VCS_package_guidelines#Git]] (the last example in that section). -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:41, 6 March 2015 (UTC)<br />
<br />
== Guidelines on updating version numbers ==<br />
<br />
There are a few version control AUR packages out there which use the correct combined format of release and git commit. However, sometimes the maintainers refuse to update the default pkgver upon new releases of the software, stating that it's unnecessary since it's updated automatically during installation anyway. While this is true, I personally feel it should still be the maintainer's responsibility to update the default pkgver upon actual releases (not individual commits) as otherwise a user will never receive an automatic update and instead has to force-reinstall all(!) such packages regularly.<br />
<br />
Should we add this to the guidelines or how do others feel about this?<br />
<br />
{{unsigned|09:51, 10 September 2015|Airblader}}<br />
<br />
:There's no official update mechanism for AUR packages, so this argument only applies to those using unofficial [[AUR helpers]]. Otherwise there's soname bumps; if the package is a library, then pkgver should likely be updated. If it is a library the package depends ''on'', I don't know of a reliable way as pkg''rel'' is stuck to 1 on VCS packages. After all, a soname bump could happen between releases or even commits. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:00, 10 September 2015 (UTC)<br />
<br />
:If you're using a VCS package, you should be paying attention to what is happening upstream and choose when you rebuild the package. Managing them the same way as release packages makes no sense.<br />
:[[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 13:25, 10 September 2015 (UTC)<br />
<br />
::Can you explain why it doesn't make sense to manage them the same way? One example is the package i3-git. As of writing this, it's version in the AUR is 4.10.2-xxxxx. The current i3 release is 4.10.4. So why *shouldn't* the package maintainer feel responsible to update it to 4.10.4-xxxxx? It's part of the Arch "feel" to be close to current development of software and I feel that if you maintain a package, you are responsible to update its version even if the actual installation process doesn't change. Sure I can rebuild my git packages, but that's really time intensive. I also cannot monitor all of those packages upstream with reasonable effort. This is exactly what a package management system has version numbers for and keeping them up to date is exactly what package maintainers are for, IMHO. [[User:Airblader|Airblader]] ([[User talk:Airblader|talk]]) 11:39, 11 September 2015 (UTC)<br />
<br />
:::VCS packages will ''always'' build the latest revision, regardless of what pkgver on the AUR contains. If a package maintainer bumps pkgver of a VCS package, there is no assurance that the users will actually build the same (working) revision, hence the bumping makes no sense. If you need to track multiple git repos, use something like [https://github.com/kynikos/repocheck repocheck] to find out if you actually ''need'' to rebuild the package. I'm sure there are similar tools for other VCS, or just write your own. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:13, 11 September 2015 (UTC)<br />
<br />
::::I don't think that bumping makes no sense just because you build the latest version and not the one stated by pkgver. This is *always* the case, even if the version isn't bumped. The bump isn't meant to build exactly that version, it is meant to trigger an automatic update in the user's package management system that doesn't require checking out the repository and verifying it themselves. Again, IMHO this is what version numbers are for. If we don't care about such packages triggering an update or having any kind of comparable version number, what's the point in even giving them a (meaningful) number? We might as well just set pkgver=1 and be done with it, no? So why all the fancy pkgver() functions for VCS packages? I don't see how the repocheck you linked to is relevant for this. I don't have the repositories of my VCS packages laying around (only in /tmp right after I update them and only until I reboot). I'd like to approach this with a pragmatic argument: I hope we can agree that triggering the update for official releases of the package is some benefit. Given that, what's the *harm* in recommending to update pkgver? If there's an opinion that it makes no sense, that's one thing, but as long as it doesn't harm I think the small benefit sounds like reason enough to me. It's not like updating the pkgver of a package is difficult work. [[User:Airblader|Airblader]] ([[User talk:Airblader|talk]]) 13:20, 11 September 2015 (UTC)<br />
<br />
:::::"I hope we can agree that triggering the update for official releases of the package is some benefit." We can't. I really see no benefit there at all. "Given that, what's the *harm* in recommending to update pkgver?" The harm comes from annoying people using those AUR helpers you mentioned. They have correctly chosen when they want to rebuild that package, now their helper is complaining all of the time even though they don't want to rebuild right now. Trigger automatic rebuilds of VCS packages is rarely a good thing, as there are no upsides and real downsides.<br />
:::::Your argument that it is really time intensive to rebuild your VCS packages makes no sense here, as you have to rebuild them either way. If you're unable to monitor upstream, why are you using a VCS package anyway? If you have no idea what's going on, you have no idea what you're getting when you build/rebuild it.<br />
:::::[[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 13:38, 11 September 2015 (UTC)<br />
<br />
::::::I don't think that you choose VCS packages because you don't want your package management system to annoy you with updates. If that's something you don't want, then you don't use one at all (why would I choose to not receive updates for *that one* package, but for all 500 others?). IMHO, you choose VCS packages because you want to be close to current development, either "just because" or because you need(ed) it for something else. Also, sometimes there just is *only* the VCS version and no package for the release. Also, if you don't want to receive updates about a certain package, you can always ignore it in the config. I don't think it's good to deny *all* users the notification of updates just because *some* might not want them. <br />
::::::I also can't agree with "triggering automatic rebuilds of VCS packages is rarely a good thing". I never see upront what I actually build, so there's always that "risk". You don't install VCS packages if you want the release version. Furthermore, in practice, it seems rare that rebuilding a VCS package causes any issues since they usually point to the master branches which in most projects have some QA before merging.<br />
::::::Your point about having to rebuild them anyway and hence not saving time is not correct. You're arguing that I should just rebuild all VCS packages all the time just in case there was an update. I'm suggesting the information whether a package needs to be rebuilt is transported in the pkgver. This saves a *drastic* amount of time as I'm not speculating. Of course I can check the Github page of each package's upstream URL before rebuilding it, but this puts the work of versioning the package onto each and every user rather than the package maintainer. Again, if this is the desired behavior, we should recommend that VCS packages just set pkgver=1. I don't see why they need to provide any version info if it's completely unnecessary that it ever be updated. [[User:Airblader|Airblader]] ([[User talk:Airblader|talk]]) 13:48, 11 September 2015 (UTC)<br />
:::::::"I'm suggesting the information whether a package needs to be rebuilt is transported in the pkgver." This is really the heart of the matter. This is completely and totally wrong for VCS packages. Whether the package needs a rebuild is up to your judgement, not the pkgver.<br />
:::::::There's nothing wrong with setting pkgver=1 (unless the actual version is less than 1). Some AUR package already do this, using "LATEST". The important thing is that the correct pkgver appears on the build package.<br />
:::::::[[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 13:59, 11 September 2015 (UTC)<br />
::::::::I just don't agree that it's "completely and totally" wrong. Yeah, sure, I can always decide to rebuild it myself. No one is taking this option away from anybody. But setting the pkgver when the actual release changes means the user is notified of this without having to care about it themselves (all n of them). Anyway, I don't think this is going anywhere. To me, letting the pkgver rot destroys a major point to why I use a package manager in the first place and makes me wonder why that person wants to be a package maintainer if they don't maintain the package, but clearly there's very different views on this. Thanks for the discussion anyway, at least I know now that there's no common view on it so there's no point in pushing for a change of guideline. [[User:Airblader|Airblader]] ([[User talk:Airblader|talk]]) 22:58, 11 September 2015 (UTC)<br />
<br />
:::::::::Sorry for reopening, I didn't make it in time to reply earlier...<br />
:::::::::I'll start by saying that I agree that VCS package maintainers shouldn't bump pkgver manually. However, suggesting to use a less confusing pkgvar value would seem sensible to me, e.g. we could indeed give "LATEST" as an example.<br />
:::::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:04, 13 September 2015 (UTC)<br />
<br />
:::::::::I also wanted to try to give @Airblader another perspective. You have mentioned 2 different cases:<br />
:::::::::* A package has both a "stable" and a "vcs" version, e.g. {{Pkg|i3}} and {{AUR|i3-git}}: why are you using {{AUR|i3-git}} in this case if you want to follow the normal upstream releases?<br />
:::::::::* A package only has a "vcs" version, e.g. {{AUR|wmfs2-git}} (dead, I know, but take it as an example): in this case the AUR maintainer can't be blamed for not bumping pkgver manually, so the problem is actually that there's nobody maintaining a "stable" PKGBUILD, and you could be the one filling that gap!<br />
:::::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:04, 13 September 2015 (UTC)<br />
<br />
<br />
== Add information about sub-modules in GIT section ==<br />
<br />
Git has submodules that can be updated rather than having to download the entire git repo for an update. Someone shared this with me: http://sprunge.us/HKdJ?md and I think it could be useful to document this sort of thing in the wiki. I'd try to myself but I'm not super familiar with git submodules.[[User:Meskarune|Meskarune]] ([[User talk:Meskarune|talk]]) 23:35, 8 December 2016 (UTC)<br />
:That's what https://wiki.archlinux.org/index.php/VCS_package_guidelines#Git_Submodules already says, isn't it?<br />
:[[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 00:14, 9 December 2016 (UTC)<br />
:: I was thinking it should be in the git section and expanded with a better explanation or at the very least links to more information on git sub-modules. Also why someone would want to even mess with sub-modules. I just don't feel like I know enough to write something further up myself. [[User:Meskarune|Meskarune]] ([[User talk:Meskarune|talk]]) 01:54, 9 December 2016 (UTC)<br />
<br />
<br />
== Warn against trivial pkgver bumps ==<br />
<br />
As mentioned previously on this page, there is no need (but it is okay to) commit a bumped pkgver to the AUR on upstream releases. But I think it is important to go one step further and actually instruct people not to commit a bumped pkgver every time they locally rebuild the package with a handful of new upstream commits.<br />
<br />
This is depressingly more common than it should be, and I can't actually find anywhere on the Wiki where it actually talks about this right now.<br />
[[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 16:55, 9 June 2017 (UTC)<br />
<br />
:I second this. However, this page is about how the PKGBUILD should be written, not about how packages should be managed on the [[AUR]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:07, 9 June 2017 (UTC)<br />
<br />
::Hmm, this is... actually a good point. I have added a note here[[Arch User Repository#Foo in the AUR is outdated; what do I do?|[1]]] instead, what do you think? <br />
::That could use a "Consider whether the package is actually outdated to begin with" section... -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 18:39, 9 June 2017 (UTC)<br />
<br />
:::Looks good, maybe adding something like "Tracking of upstream updates for VCS packages is the responsibility of users, not maintainers." would make it more explicit. Regarding soname bumps, pushing them does not hurt but I tend to support the same strategy as with pkgver, because people might prefer {{ic|makepkg -ef}} to keep the same revision. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:13, 9 June 2017 (UTC)<br />
<br />
::::I reject this argument. :p {{ic|makepkg -ef}} is not meant to guarantee an identical package when the PKGBUILD has been modified between runs. Why would you even want that anyway?<br />
::::Also, by preference I do generally do a pkgver bump on upstream stable releases, on the grounds that per-commit notifications are ugly but stable releases should be updated to as soon as possible. But maybe now that we are writing actual guidelines, maybe we can decide whether that is something the AUR wishes to firmly rule against. -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 22:26, 9 June 2017 (UTC)<br />
<br />
:::::I have an AUR package where the maintainer bumps the package in every single new commit. He asked for a guideline where this is written down, as he doesnt believe my "good practice" argument. I think it would be best to write it down into the guideline section of this page, as its the first place I'd search for. The AUR page might be also a suitable place, but this is not where you start searching. Please add a note, thanks. --[[User:NicoHood|NicoHood]] ([[User talk:NicoHood|talk]]) 13:32, 16 June 2017 (UTC)<br />
<br />
::::::It's been already added to [[Arch User Repository#Foo in the AUR is outdated; what do I do?]], which is the page for AUR guidelines. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:52, 16 June 2017 (UTC)<br />
<br />
:::::::Yes, but it only says you should not flag it out of date. But it does not tell the maintainer to stop version bumping. This is not clear enough and people will always ignore it then, if you tell them to stop. --[[User:NicoHood|NicoHood]] ([[User talk:NicoHood|talk]]) 15:04, 16 June 2017 (UTC)<br />
<br />
::::::::Aaaaaaand, you have now confirmed that you '''haven't actually read''' the change I made there. (I cannot believe you think I would go modify the AUR page in reference to this conversation, and then ''completely'' fail to say the one thing this discussion was about in the first place.)<br />
::::::::So I will just ignore anything you say now, I guess. At least until I have some reason to think it is actually worth my time to even consider what you are saying. :(<br />
::::::::Addendum: You could always have just added it yourself, this is a Wiki after all... -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 21:40, 16 June 2017 (UTC)<br />
<br />
:::::Hi, I'm the maintainer [[User:NicoHood|NicoHood]] is talking about, [https://aur.archlinux.org/packages/dino-git/ here] the discussion. I failed to find a guideline about how a maintainer should behave in this circumstance and as it wasn't discouraged or forbidden I decided to act as I did. One of my points is that I find annoying, as a user with more than a bounce of packages from AUR, that I have to clone every time, every repo for every package just to check for updates (some of the projects are quite big and I find this a waste of time and bandwidth). In this particular case we are talking about a project which is rapidly implementing new features and as I check periodically for updates regarding new functionalities I think other users may benefit from being notified about them. I share the point of not bumping the pkgver for every commit but I think that if a maintainer has time to update the pkgver on new features and will to do so it's not making damages to anyone. Please correct me if I'm missing something. Re-reading my commits I noticed some of them were not needed and I'll avoid to push unnecessary updates. <br />
:::::What I'm missing as well is the role of pkgver for vcs packages, expecially for those projects that don't have a release yet. Clarifying this maybe would also close the discussion. [[User:Valo|Valo]] ([[User talk:Valo|talk]]) 08:04, 19 June 2017 (UTC)<br />
<br />
::::::You can use $SRCDEST to specify a cache directory where makepkg will store the repositories in between makepkg runs. For a package which someone wants to update frequently, it makes sense to use this. :) This goes double for a rapidly-developing software which gets frequent commits. And that still isn't an excuse to "have time to update the pkgver". Strictly speaking, it is '''never''' necessary, unless changes to the dependencies or the build()/package() functions are involved. People who are that interested in the software's development, are likely already following it elsewhere, and everyone else doesn't really need to know "oh, how exciting, a couple more commits for this VCS software. There is also the matter that for looking at the history of the PKGBUILD itself, to see what changed, it requires more effort to mentally filter through many pkgver-only changes and see what actually changed with regard to the metadata/build process/etc. Noise is, well, noisy.<br />
::::::I only justify upstream releases as it is, by telling myself that users of the non-development version are expected to update immediately, so users of the development version should as well -- and because even if a user doesn't bother to update for each commit, they should definitely aspire to be running the latest official stable release.<br />
::::::Regarding the purpose of the pkgver for VCS packages, it is to ensure that users can query their installed packages to see what version of the software they have installed, and to ensure a monotonically increasing pkgver for more recent snapshots of the source code it is built from. The fact that pkgver is also something an AUR helper can compare when emulating {{ic|pacman -Syu}} is not really relevant to a VCS package, except as an added redundancy which you should be judicious about using.<br />
::::::Anyway, we now have a guideline. -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 04:29, 26 June 2017 (UTC)<br />
<br />
:On a similar note, it is also annoying to {{ic|git checkout PKGBUILD}} before {{ic|git pull}} each time there ''is'' a substantial change pushed to the AUR, but my local {{ic|pkgver}} was newer than the previous version on AUR. It's not just about running one more command, I always have to {{ic|git diff}} before to check that I don't have some other unstaged changes. Perhaps if there was some better technical solution for this (perhaps the {{ic|pkgver}} variable could be completely removed when there is a {{ic|pkgver}} function?), then maybe people would not feel the unbearable urge to immediately commit and push all unstaged changes. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:18, 9 June 2017 (UTC)<br />
<br />
::Well, you probably aren't supposed to make local changes. :p What is wrong with the AUR maintainer that you need to fix, but don't feel like asking for a better maintainer? That being said, I do actually have cases (very personal patches) where I make a local change and commit that, then use {{ic|git fetch && git rebase}}. This works quite well, so I am not sure we need a better technical solution at all. -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 18:39, 9 June 2017 (UTC)<br />
<br />
:::Not that I care about these, but at least [https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=mpv-git#n6 here] people are actually supposed to make local changes. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:13, 9 June 2017 (UTC)<br />
<br />
::::Sure, it is sometimes "supposed to" happen, but it isn't really the norm. :) As I said, {{ic|git rebase}} is a powerful tool to use there. -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 22:26, 9 June 2017 (UTC)<br />
<br />
== Git submodules: sometimes not all submodules are needed ==<br />
<br />
As per this writeup by Earnestly (which I understand is the initial source of that section): https://ptpb.pw/r/N6-z.md<br />
Some packages shouldn't try to checkout all submodules, because it is wasteful and unneeded. It might be nice to expand on that section by mentioning this. -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 14:19, 12 July 2017 (UTC)<br />
<br />
== Add notice to this page? ==<br />
The [[Arch User Repository]] page indicates:<br />
{{Note|[[VCS package guidelines|VCS packages]] are not considered out of date when the pkgver changes, so '''please''' do not flag them as the maintainer will merely unflag the package and ignore you. AUR maintainers should not commit mere pkgver bumps.}}<br />
Perhaps this should be included on this page as well, to inform new maintainers that they should not be making pkgver bumps for these packages.<br />
That being said, there should probably be a way to update the pkgver shown by the AUR web UI, or disable it entirely for VCS packages, in order to prevent others from believing a package is out of date and flagging it. [[User:JacobHenner|JacobHenner]] ([[User talk:JacobHenner|talk]]) 11:33, 17 November 2017 (UTC)<br />
<br />
== pacman 4.1 ==<br />
<br />
Shall we remove the references to 4.1?<br />
What was possible / the practice in the past may help to understand certain outdated packages but 5 years starts to be very long and we should turn the page at one stage I suppose.<br />
This is the impression of a newcomer who wants to get to the point and is confused by the reference to such old versions but don't hesitate to correct me if this is still important.<br />
[[User:Kewl|Kewl]] ([[User talk:Kewl|talk]]) 10:29, 14 January 2018 (UTC)<br />
<br />
:Agree. -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 15:00, 30 June 2020 (UTC)<br />
<br />
== Suggest to use https instead of git protocol when possible ==<br />
A lot of public structures/companies block the default git port (9418). This problem is explained here : https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols#_the_cons_4<br />
Using {{ic|git+https://}} urls for sources is supported by most (if not all) git servers, and {{ic|https}} will most likely not be blocked.<br />
<br />
{{unsigned|10:39, 22 October 2018|Salamandar}}<br />
<br />
:+1, I'd also mention that it's a security issue because {{ic|git://}} and {{ic|http://}} aren't encrypted and vulnerable to MITM attacks. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 19:10, 22 October 2018 (UTC)<br />
<br />
::+1, That's gold for me, as I'm normally behind a proxy that blocks {{ic|git://}}, but allows {{ic|git+https://}}... -- [[User:Josephgbr|Josephgbr]] ([[User talk:Josephgbr|talk]]) 02:19, 16 April 2019 (UTC)<br />
<br />
:::I see this is done in "An example Git source array". How about the other two places that illustrate using git sources? (left of {{ic|vcs+}} bullet point in [[VCS package guidelines#VCS sources|VCS sources]], on two lines in the [[VCS package guidelines#Git submodules|Git submodules]] tip) [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 15:18, 5 June 2019 (UTC)<br />
<br />
== Proposal: Break "Guidelines" header into subsections ==<br />
<br />
Too many bullet points are a navigation hazard. To help users get to the information they need faster, we should reorganize this into a few subsections. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 13:31, 4 March 2019 (UTC)<br />
<br />
: Seems to me as a good idea. Just two notes: "Security" should be lowercase in the section title "Authentication and Security", and AUR pkgbase deletion request was moved from [[Arch User Repository#Deletion]] to [[AUR submission guidelines#Requests]] since you proposed these changes. -- [[User:Josephgbr|Josephgbr]] ([[User talk:Josephgbr|talk]]) 12:02, 28 June 2019 (UTC)<br />
<br />
::Done; it is unfortunate the new ''AUR submission guidelines'' does not ([[Talk:AUR submission guidelines#Improvements from the AUR page that was reverted|yet]]) have a "#Deletion" subsection: [[User:Quequotion/AUR submission guidelines#Deletion]] [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 01:01, 29 June 2019 (UTC)<br />
<br />
:::As this is a protected page, I am not able to make the changes myself. If we have sufficient consensus here, an editor, administrator, or trusted user is needed to actually make them. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 13:40, 21 July 2019 (UTC)<br />
<br />
:::I have relocated these proposals to a [[User:Quequotion/VCS_package_guidelines#Guidelines|full page draft]] as per the [[Special:Diff/575147|new policy regarding proposals]]. If you'd like to see the whole piecemeal set of nine changes, start [[Special:Diff/641456|here]]. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 01:25, 14 November 2020 (UTC)<br />
<br />
== GitHub API usage ==<br />
<br />
Some git repos are really huge (ex. QGIS) and git-clone process takes a lot of time and space. So, here is an example how to use GH API to obtain pkgver:<br />
{{hc|<nowiki><br />
_orgname=foo<br />
_pkgname=bar<br />
_branch=master<br />
_gh_api_url="https://api.github.com/repos/${_orgname}/${_pkgname}"<br />
...<br />
makedepends=('jq')<br />
...<br />
source=("https://github.com/${_orgname}/${_pkgname}/archive/${_branch}.tar.gz")<br />
sha256sums=('SKIP')<br />
<br />
pkgver() {<br />
read -r tag_name tag_sha <<<$(curl -s "${_gh_api_url}/tags" | \<br />
jq -r '.[0]|[.name,.commit.sha]|@sh' | sed "s/'//g")<br />
head=$(curl -s "${_gh_api_url}/git/refs/heads/${_branch}" | \<br />
jq -r '.object.sha')<br />
count=$(curl -s "${_gh_api_url}/compare/${tag_sha}...${head}" | \<br />
jq -r '.total_commits')<br />
<br />
printf "%s.r%s.g%.8s" "${tag_name}" "${count}" "${head}"<br />
}</nowiki>|<br />
0.1.r7.g47de1a51<br />
}}<br />
<br />
{{unsigned|2019-06-28|Sikmir}}<br />
<br />
: ''makepkg'' still requires cloning the whole source code repository to build the package. In fact, the source code fetching happens before the [[PKGBUILD#pkgver|pkgver]] function. IMO, this option does not seem to have any use for packaging in Arch. By the way, if you use the binary ''jq'', make sure to add {{pkg|jq}} to [[PKGBUILD#makedepends|makedepends]] array. -- [[User:Josephgbr|Josephgbr]] ([[User talk:Josephgbr|talk]]) 11:37, 28 June 2019 (UTC)<br />
<br />
:: No! It doesn't require cloning, see ''source'' variable, there is only gzipped snapshot. [[User:Sikmir|Sikmir]] ([[User talk:Sikmir|talk]]) 16:18, 28 June 2019 (UTC)<br />
<br />
::: I didn't see the tarball in source before, but in my opinion a PKGBUILD with a branch/tag's tarball as source does not classify as a VCS package and, therefore, should not be included to this page. I understand GitHub's snapshot tarball represents the last commit of the software, but still you are not using a VCS. Personally, since Arch Linux has these well defined type of packages, normal/non-VCS package with defined version and VCS packages with dynamic version, I would make my dynamic versioning packages as VCS package due to the advantage of just updating the source code repository instead of re-downloading it all. -- [[User:Josephgbr|Josephgbr]] ([[User talk:Josephgbr|talk]]) 18:08, 28 June 2019 (UTC)<br />
<br />
== Add GPG Signature verification note ==<br />
<br />
It is possible to verify the git sources using gpg. This is documented in "man PKGBUILD", but most people do not know this. It would be easy to have this information in the tip section of this guideline.<br />
<br />
source=(<url>?signed)<br />
<br />
validpgpkeys=('<keyid>')<br />
<br />
[[User:NicoHood|NicoHood]] ([[User talk:NicoHood|talk]]) 07:54, 3 June 2020 (UTC)<br />
<br />
== Manually constructed 'git describe' output should be forward-compatible ==<br />
<br />
The recommendation for when no tags exist isn't forward-compatible wrt adding tags -- note the absence of a 'g' prefix in the SHA.<br />
<br />
[[User:Gesh|Gesh]] ([[User talk:Gesh|talk]]) 15:22, 20 December 2020 (UTC)</div>Geshhttps://wiki.archlinux.org/index.php?title=Talk:VCS_package_guidelines&diff=646086Talk:VCS package guidelines2020-12-20T15:22:31Z<p>Gesh: /* Manually constructed 'git describe' output should be forward-compatible */ new section</p>
<hr />
<div>== Numeric vs Date Standard in Git pkgver ==<br />
<br />
I'd like to see a standard emerge in AUR Git packages, but standards have to work down to the lowest common denominator. Only a small minority of GitHub projects properly tag their releases, so there can be only two LCD standards for Git packages: the Numeric standard, e.g. ("r1581.2b039da") and the Date standard, e.g. ("2014-01-01"). The date standard is much more readable, and actionable, and has the additional benefit of being backwards compatible with older Git packages.<br />
<br />
I don't know if any standard can emerge even if we wanted it to, but please allow me to at least add the Date standard to the VCS package guidelines wiki (as opposed to scrubbing it, :).<br />
<br />
:Using the commit date would be incorrect because it doesn't refer to a specific commit and the dates are not always sequential. It would be even more wrong if it was the build date, as that doesn't refer to anything to do with the version. -- [[User:thestinger|thestinger]] 21:33, 23 January 2015 (UTC)<br />
<br />
::''it doesn't refer to a specific commit''<br />
::<br />
::Neither does "r1581.2b039da" refer to a specific commit without the .git repo cmdline interaction, and it is considered best practice to prune $pkgdir of .git:<br />
::<br />
find "$pkgdir" -type d -name .git -exec rm -r '{}' +<br />
::<br />
::Can you explain what you mean by "the dates are not always sequential"? The Date standard looks like this:<br />
::<br />
git log -1 --format="%cd" --date=short | sed "s|-||g"<br />
::<br />
::It displays the latest commit date from the upstream Git repo.<br />
::<br />
::In the edge case of breaking changes occurring upstream in Git repos on the same day, then package maintainers should increment pkgrel. In practice, "2014-01-01" is much more readable and useful than "r1581.2b039da". The readability benefits of "2014-01-01" vs. "r1581.2b039da" should not be underestimated due to edge cases. --[[User:Atweiden|Atweiden]] ([[User talk:Atweiden|talk]]) 18:39, 24 January 2015 (UTC)<br />
:::A git commit id certainly refers to a specific commit. I don't know why you think this has anything to do with shipping the VCS repository in the package. The commit date of the most recent commit may be from 20 weeks ago while the earlier commits were from last week. Git does not have a linear history. It's not going to be changed to use a version format where it can go both backwards and forwards with no way of tracing it back to the commit. Readability is worthless if the information isn't meaningful... There are 2 hard requirements: newer revisions must have higher package versions without exceptions, and it must be possible to trace it back to a commit to properly identify and report bugs. -- [[User:thestinger|thestinger]] 18:53, 24 January 2015<br />
:::<br />
::::<br />
::::I am quite certain of what a commit ID looks like, e.g. 2d5749d0315a59f4a8bf73ebbe757b227c8c17a3, not r1581.2b039da.<br />
::::<br />
::::Can you show me where to find "r1581.2b039da" on a GitHub/BitBucket repo? It doesn't exist anywhere that I can see. You need to have the repo locally, then cd into the Git repo and run:<br />
::::<br />
git rev-list --count HEAD<br />
::::<br />
::::That is work-intensive, and it conflicts with the best practice of pruning AUR packages of .git repos.<br />
::::<br />
::::I previously used the Wiki-recommended Numeric standard, so it's not like I haven't used it. I switched to the Date standard, updating hundreds of packages to reflect it. Why do you suppose that is?<br />
::::<br />
:::: ''Readability is worthless if the information isn't meaningful''<br />
::::You'd be hard pressed to convince me that the date "2014-01-01" is somehow *less* semantically meaningful or actionable than "r1581". I say this after maintaining for years, hundreds of Git packages in the AUR. You can tell by grepping `pacman -Q` exactly which AUR git packages are out of date with a two-second visit to GitHub. The Date standard is incredibly actionable and pragmatic not to mention simple and immediately understandable by anyone.<br />
::::<br />
:::: ''newer revisions must have higher package versions without exceptions''<br />
::::<br />
::::Not a problem: "2014-01-01" < "2014-01-02"<br />
::::<br />
:::: ''it must be possible to trace it back to a commit to properly identify and report bugs''<br />
::::<br />
:::: Given how frequently "stable" Go packages and C packages pull in Git dependencies as part of their build process without specifying a certain commit, I disagree with this proposition. Why would recording the version of acmedaemon as 1.5, when it pulls in Git packages without specifying commit ID, be all that different in bug reports than "2014-01-01"? In both cases, you will not be able to track down the exact cause of the bug by commit. In both cases, you will in all likelihood end up consulting the build date. --[[User:Atweiden|Atweiden]] ([[User talk:Atweiden|talk]]) 03:32, 25 January 2015 (UTC)<br />
<br />
:::::''I am quite certain of what a commit ID looks like, e.g. 2d5749d0315a59f4a8bf73ebbe757b227c8c17a3, not r1581.2b039da.''<br />
:::::In your scenerio, 2b039da is the short version of the commit hash and does point to a specific commit. As for where you find it on Github, it's listed on the commit log, of course. Just look at the right hand side of the page.<br />
:::::''You'd be hard pressed to convince me that the date "2014-01-01" is somehow *less* semantically meaningful or actionable than "r1581".''<br />
:::::In this case, human readability really is meaningless. Machine readability is all that matters.<br />
:::::''Not a problem: "2014-01-01" < "2014-01-02"''<br />
:::::And what happens when the commit after that is dated 2013-12-31? As thestinger pointed out, Git is not linear.<br />
:::::[[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 03:40, 25 January 2015 (UTC)<br />
<br />
::::::''2b039da is the short version of the commit hash''<br />
::::::<br />
::::::Can this information be easily compared on GitHub to your local package version to check if it is out of date? The answer is no.<br />
::::::<br />
::::::It is not actionable, except by cloning the repo yourself, running the Git command, and then manually scanning the Git log for short versions. It's very work-intensive.<br />
::::::<br />
::::::''Git is not linear''<br />
::::::<br />
::::::Neither are stable packages on PyPi: https://pypi.python.org/pypi/tackpy/0.9.9a<br />
::::::<br />
::::::Pacman views the upgrade of 0.9.9 -> 0.9.9a as a downgrade. See https://aur.archlinux.org/packages/python2-tackpy for a real world example of this edge case. Edge cases should be no reason to prevent readers of the wiki to make informed choices about Git packaging standards. --[[User:Atweiden|Atweiden]] ([[User talk:Atweiden|talk]]) 04:08, 25 January 2015 (UTC)<br />
<br />
:::::::Yes, the short hash of each commit is listed in the commit log. Also note that the revision count (the "r" number listed first) is also listed at the top of each repo's page.<br />
:::::::As for PyPi's versioning scheme, their choice is different than what Arch's vercmp assumes. The packager needs to take this into account, just as all packagers must take upstream's idiosyncrasies into account. I don't see how it's relevant here.<br />
:::::::You also never answered my question, what happens when the last commit is dated before the commit previous to it? This question is critical, as it would cause your versioning scheme to go backwards by any and all measures. That makes it unacceptable.<br />
:::::::[[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 04:15, 25 January 2015 (UTC)<br />
<br />
::::::::Incorrect.<br />
::::::::<br />
printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)<br />
::::::::<br />
::::::::The output of the above command does not correspond to any piece of information on GitHub.<br />
::::::::<br />
::::::::If PyPi packagers should take edge cases into account for PyPi packages, then they should do the same for Git packages. Edge cases aren't reason enough to scrub a competing standard from the wiki. --[[User:Atweiden|Atweiden]] ([[User talk:Atweiden|talk]]) 04:23, 25 January 2015 (UTC)<br />
<br />
:::::::::I'm sorry if you can't find this information on GitHub. It's very, very plainly displayed in the places I already pointed you to. If you would take a minute to check instead of just jumping at me, you might find it.<br />
:::::::::[[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 04:31, 25 January 2015 (UTC)<br />
<br />
::::::::::''the short hash of each commit is listed in the commit log. Also note that the revision count (the "r" number listed first) is also listed at the top of each repo's page''.<br />
::::::::::<br />
::::::::::This is (partially) incorrect. The short hash of each commit is not listed. What is listed in the commit log is the truncated commit ID.<br />
::::::::::<br />
::::::::::The revision count point I will retract. It didn't appear to work for my own Git repos, but that was because I ran the command from a Git subrepo (edge case :). The date still has the advantage of being more human readable than r1582. If a package has version 2011-10-22, I will know this project is either unmaintained, or it's been a really long time since I last rebuilt it. All without leaving the terminal. --[[User:Atweiden|Atweiden]] ([[User talk:Atweiden|talk]]) 07:33, 25 January 2015 (UTC)<br />
<br />
::::::::::It's also very easy to look up or link to commits via the abbreviated commit hashes or proper identifiers produced by {{ic|git describe}}. -- [[User:thestinger|thestinger]] 04:33, 25 January 2015 (UTC)<br />
<br />
::::::That has nothing to do with non-linear history. It has to do with an incompatibility between Pacman's version comparison and the one chosen by the project. There are ways of dealing with that, but it has nothing to do with this discussion. -- [[User:thestinger|thestinger]] 04:24, 25 January 2015 (UTC)<br />
<br />
:::::The ideal version is the one produced by {{ic|git describe}}, because it's easily understood by humans (last tag, commits since last tag, abbreviated commit), is also understood by the various Git commands and GitHub and is monotonically increasing thanks to the inclusion of the last version and revision count since then. The versions it produces ({{ic|10-7-g8537989}}) can be directly used with commands like {{ic|git show}}. Unlike the build date, it identifies a unique revision of the project, including the state of any submodules.<br />
<br />
:::::The only case where another method should be used is when the project doesn't yet have any tagged release or does the releases in a way that's not very sane. The releases ''should'' be tagged on master with additional tags in stable branches for fixes backported to old releases. If this isn't the case, the {{ic|git describe}} output needs to be emulated. A date is a poor way of doing that, because it's not connected to a specific point in the revision history.<br />
<br />
:::::The only case where the commit date would work is if Git is being used as a crippled centralized version control system. If all commits get created against master (no merging branches or patches) in a centralized repository where the system clock is never moved backwards, it could work... but that's not the reality of non-linear, distributed version control.<br />
<br />
:::::A build date is even worse, because it only refers to the local state of time and the local state of the repository. Commits from before that timestamp will often be pushed to the repository.<br />
<br />
:::::-- [[User:thestinger|thestinger]] 04:24, 25 January 2015 (UTC)<br />
<br />
::::::A packaging standard must be compatible with the lowest common denominator. A minority of Git repos are properly tagged. The Date works as a standard, tags do not.<br />
::::::<br />
git log -1 --format="%cd" --date=short | sed "s|-||g"<br />
::::::<br />
::::::The output of the above command shows the date of the most recent commit. If the most recent commit date happens to come before the date of a previous commit, I do understand this is suboptimal, but I consider it an edge case. Even in big projects with contributors in different time zones you will typically see branches merged in with PRs. PRs reset the date to something recent. The linearity of Git is rarely problematic, but I do see where you're coming from (I'm also a happy user of archversion for keeping packages up to date, though archversion works with the Date standard too :) --[[User:Atweiden|Atweiden]] ([[User talk:Atweiden|talk]]) 04:59, 25 January 2015 (UTC)<br />
<br />
:::::::The {{ic|git describe}} versioning system is the standard defined and used by Git itself. The dashes need to be converted into dots for {{ic|pkgver}} and an {{ic|r}} ''may'' be inserted to make it clearer which part is the revision number. If version-based tags on master are available, this is the only sane way to do it.<br />
<br />
:::::::Git defaults to fast-forwarding / applying patches without merge commits, as long as there are no conflicts. GitHub will ''always'' generate a merge commit but that's not true for anything applied / merged by the developers and then pushed to master. -- [[User:thestinger|thestinger]] 05:24, 25 January 2015 (UTC)<br />
<br />
:::::::You've made the claim that most git repos aren't properly tagged, not only now but to me previously. Do you have anything to back that up? IME, the large majority of projects that are in a usable state are either tagged or get tagged as they become stable.<br />
:::::::[[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 05:27, 25 January 2015 (UTC)<br />
<br />
::::::::OK:<br />
::::::::<br />
git init<br />
::::::::<br />
::::::::You now have your very own untagged Git repo :).<br />
::::::::<br />
::::::::The majority of Git repos are untagged. If you want to have a standard compatible with the lowest common denominator, by definition you cannot depend on tags being there.<br />
::::::::<br />
::::::::I regularly package Git software in the alpha stages and software maintained by people who are unfamiliar with tagging or aren't bothered to tag. --[[User:Atweiden|Atweiden]] ([[User talk:Atweiden|talk]]) 07:15, 25 January 2015 (UTC)<br />
<br />
::::As suggested in [[VCS package guidelines#Fallback]], I think the only date that can be used is the build date: for example I've recently used it in [https://aur.archlinux.org/packages/te/textadept-common-git/PKGBUILD a PKGBUILD] for a repo without tags or branches, also appending the first 7 characters of the commit hash (the repo is not cloned, so I could only use ''git-ls-remote''). — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:30, 25 January 2015 (UTC)<br />
<br />
== Updating a CVS repo ==<br />
<br />
I don't use cvs. How can you describe the pkgver for cvs (for pacman 4.1)? <br><br />
-- [[User:Dracorp|Dracorp]] ([[User talk:Dracorp|talk]]) 09:31, 6 April 2013 (UTC)<br />
<br />
:CVS is not supported in pacman 4.1 like the other VCS tools. You will need to update pkgver manually until CVS support is added.<br />
:-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 22:44, 15 April 2013 (UTC)<br />
<br />
::Yeah, but how about mentioning that in the article (as well as giving a download example)? Even if it's not that common anymore.<br />
::--[[User:Det|Det]] ([[User talk:Det|talk]]) 22:39, 2 May 2013 (UTC)<br />
<br />
:::The download example can still be found in {{ic|/usr/share/pacman/}}. The next version of the ABS package should update it a bit so the download happens in the prepare function where it belongs. As for pkgver, I think the generic example using date covers that, as there's not a way to get a version number from a CVS repo. Maybe a note to that effect?<br />
::: -- [[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 07:17, 15 May 2013 (UTC)<br />
<br />
::::That makes the most sense, but it might also be a good idea to rename the [[VCS PKGBUILD Guidelines#Fallback|"Fallback"]] section to something like "Fallback / CVS" to make it more obvious even when you're just checking out the table of contents.<br />
<br />
::::But as for ABS, as far as I can tell the last commit was over [https://projects.archlinux.org/abs.git/log/ 8 months] ago.<br />
::::--[[User:Det|Det]] ([[User talk:Det|talk]]) 05:54, 19 May 2013 (UTC)<br />
<br />
:::::Hmm, there were a number of patches submitted last month for cleaning up the prototypes, looks like none have been committed yet. I do remember a discussion (IRC maybe?) questioning the proper place for the prototypes, so maybe that's why? Looking at the patches, I was mistaken anyway; they didn't update the darcs or cvs prototypes. Simple enough, I'll send in a patch myself.<br />
:::::--[[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 08:22, 19 May 2013 (UTC)<br />
<br />
: I use this dirty hack: {{ic|<nowiki>cvs history -c -a | cut -d' ' -f2 | sort -u | tail -n 1 | sed 's|-||g"</nowiki>}} ; could probably be improved.<br />
:--[[User:Buhman|Buhman]] ([[User talk:Buhman|talk]]) 18:00, 6 June 2013 (UTC)<br />
<br />
<br />
== pkgver function for hg based on tags ==<br />
<br />
I recent came across a way with hg to show the most recent tag, as well as the number of commits from this tag (similar to the output of {{ic|git describe}}.) <br />
<br />
{{hc|<nowiki>pkgver() {<br />
cd local_repo<br />
hg log -r . --template '{latesttag}.{latesttagdistance}.{node|short}\n'<br />
}</nowiki>|<br />
3.0.1.40.ee9a2543fcd6<br />
}}<br />
<br />
Please could this be included in the page.<br />
<br />
[[User:Garyvdm|Garyvdm]] ([[User talk:Garyvdm|talk]]) 09:03, 23 July 2013 (UTC)<br />
<br />
== shorten hg version ==<br />
<br />
To prevent long package file name,<br />
It is proper to use this format<br />
<br />
{{bc|<nowiki>pkgver() {<br />
cd $_repo<br />
_id=$(hg identify -i)<br />
echo $(hg identify -n).${_id:0:4}<br />
}</nowiki><br />
}}<br />
--[[User:Dlin|Dlin]] ([[User talk:Dlin|talk]]) 05:30, 26 August 2013 (UTC)<br />
<br />
== fossil ==<br />
<br />
{{bc|<nowiki>pkgver() {<br />
cd local_repo<br />
_id=$(cat manifest.uuid 2>/dev/null)<br />
echo ${_id:0:4}<br />
}</nowiki><br />
}}<br />
--[[User:Dlin|Dlin]] ([[User talk:Dlin|talk]]) 05:36, 26 August 2013 (UTC)<br />
<br />
== set -o pipefail ==<br />
<br />
[https://wiki.archlinux.org/index.php?title=VCS_package_guidelines&diff=prev&oldid=363918 This change] mentioned {{ic|set -o ...}} as one of the reasons for reverting, nevertheless one example using {{ic|set -o pipefail}} still remains: [[VCS_package_guidelines#Git]] (the last example in that section). -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:41, 6 March 2015 (UTC)<br />
<br />
== Guidelines on updating version numbers ==<br />
<br />
There are a few version control AUR packages out there which use the correct combined format of release and git commit. However, sometimes the maintainers refuse to update the default pkgver upon new releases of the software, stating that it's unnecessary since it's updated automatically during installation anyway. While this is true, I personally feel it should still be the maintainer's responsibility to update the default pkgver upon actual releases (not individual commits) as otherwise a user will never receive an automatic update and instead has to force-reinstall all(!) such packages regularly.<br />
<br />
Should we add this to the guidelines or how do others feel about this?<br />
<br />
{{unsigned|09:51, 10 September 2015|Airblader}}<br />
<br />
:There's no official update mechanism for AUR packages, so this argument only applies to those using unofficial [[AUR helpers]]. Otherwise there's soname bumps; if the package is a library, then pkgver should likely be updated. If it is a library the package depends ''on'', I don't know of a reliable way as pkg''rel'' is stuck to 1 on VCS packages. After all, a soname bump could happen between releases or even commits. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:00, 10 September 2015 (UTC)<br />
<br />
:If you're using a VCS package, you should be paying attention to what is happening upstream and choose when you rebuild the package. Managing them the same way as release packages makes no sense.<br />
:[[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 13:25, 10 September 2015 (UTC)<br />
<br />
::Can you explain why it doesn't make sense to manage them the same way? One example is the package i3-git. As of writing this, it's version in the AUR is 4.10.2-xxxxx. The current i3 release is 4.10.4. So why *shouldn't* the package maintainer feel responsible to update it to 4.10.4-xxxxx? It's part of the Arch "feel" to be close to current development of software and I feel that if you maintain a package, you are responsible to update its version even if the actual installation process doesn't change. Sure I can rebuild my git packages, but that's really time intensive. I also cannot monitor all of those packages upstream with reasonable effort. This is exactly what a package management system has version numbers for and keeping them up to date is exactly what package maintainers are for, IMHO. [[User:Airblader|Airblader]] ([[User talk:Airblader|talk]]) 11:39, 11 September 2015 (UTC)<br />
<br />
:::VCS packages will ''always'' build the latest revision, regardless of what pkgver on the AUR contains. If a package maintainer bumps pkgver of a VCS package, there is no assurance that the users will actually build the same (working) revision, hence the bumping makes no sense. If you need to track multiple git repos, use something like [https://github.com/kynikos/repocheck repocheck] to find out if you actually ''need'' to rebuild the package. I'm sure there are similar tools for other VCS, or just write your own. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:13, 11 September 2015 (UTC)<br />
<br />
::::I don't think that bumping makes no sense just because you build the latest version and not the one stated by pkgver. This is *always* the case, even if the version isn't bumped. The bump isn't meant to build exactly that version, it is meant to trigger an automatic update in the user's package management system that doesn't require checking out the repository and verifying it themselves. Again, IMHO this is what version numbers are for. If we don't care about such packages triggering an update or having any kind of comparable version number, what's the point in even giving them a (meaningful) number? We might as well just set pkgver=1 and be done with it, no? So why all the fancy pkgver() functions for VCS packages? I don't see how the repocheck you linked to is relevant for this. I don't have the repositories of my VCS packages laying around (only in /tmp right after I update them and only until I reboot). I'd like to approach this with a pragmatic argument: I hope we can agree that triggering the update for official releases of the package is some benefit. Given that, what's the *harm* in recommending to update pkgver? If there's an opinion that it makes no sense, that's one thing, but as long as it doesn't harm I think the small benefit sounds like reason enough to me. It's not like updating the pkgver of a package is difficult work. [[User:Airblader|Airblader]] ([[User talk:Airblader|talk]]) 13:20, 11 September 2015 (UTC)<br />
<br />
:::::"I hope we can agree that triggering the update for official releases of the package is some benefit." We can't. I really see no benefit there at all. "Given that, what's the *harm* in recommending to update pkgver?" The harm comes from annoying people using those AUR helpers you mentioned. They have correctly chosen when they want to rebuild that package, now their helper is complaining all of the time even though they don't want to rebuild right now. Trigger automatic rebuilds of VCS packages is rarely a good thing, as there are no upsides and real downsides.<br />
:::::Your argument that it is really time intensive to rebuild your VCS packages makes no sense here, as you have to rebuild them either way. If you're unable to monitor upstream, why are you using a VCS package anyway? If you have no idea what's going on, you have no idea what you're getting when you build/rebuild it.<br />
:::::[[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 13:38, 11 September 2015 (UTC)<br />
<br />
::::::I don't think that you choose VCS packages because you don't want your package management system to annoy you with updates. If that's something you don't want, then you don't use one at all (why would I choose to not receive updates for *that one* package, but for all 500 others?). IMHO, you choose VCS packages because you want to be close to current development, either "just because" or because you need(ed) it for something else. Also, sometimes there just is *only* the VCS version and no package for the release. Also, if you don't want to receive updates about a certain package, you can always ignore it in the config. I don't think it's good to deny *all* users the notification of updates just because *some* might not want them. <br />
::::::I also can't agree with "triggering automatic rebuilds of VCS packages is rarely a good thing". I never see upront what I actually build, so there's always that "risk". You don't install VCS packages if you want the release version. Furthermore, in practice, it seems rare that rebuilding a VCS package causes any issues since they usually point to the master branches which in most projects have some QA before merging.<br />
::::::Your point about having to rebuild them anyway and hence not saving time is not correct. You're arguing that I should just rebuild all VCS packages all the time just in case there was an update. I'm suggesting the information whether a package needs to be rebuilt is transported in the pkgver. This saves a *drastic* amount of time as I'm not speculating. Of course I can check the Github page of each package's upstream URL before rebuilding it, but this puts the work of versioning the package onto each and every user rather than the package maintainer. Again, if this is the desired behavior, we should recommend that VCS packages just set pkgver=1. I don't see why they need to provide any version info if it's completely unnecessary that it ever be updated. [[User:Airblader|Airblader]] ([[User talk:Airblader|talk]]) 13:48, 11 September 2015 (UTC)<br />
:::::::"I'm suggesting the information whether a package needs to be rebuilt is transported in the pkgver." This is really the heart of the matter. This is completely and totally wrong for VCS packages. Whether the package needs a rebuild is up to your judgement, not the pkgver.<br />
:::::::There's nothing wrong with setting pkgver=1 (unless the actual version is less than 1). Some AUR package already do this, using "LATEST". The important thing is that the correct pkgver appears on the build package.<br />
:::::::[[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 13:59, 11 September 2015 (UTC)<br />
::::::::I just don't agree that it's "completely and totally" wrong. Yeah, sure, I can always decide to rebuild it myself. No one is taking this option away from anybody. But setting the pkgver when the actual release changes means the user is notified of this without having to care about it themselves (all n of them). Anyway, I don't think this is going anywhere. To me, letting the pkgver rot destroys a major point to why I use a package manager in the first place and makes me wonder why that person wants to be a package maintainer if they don't maintain the package, but clearly there's very different views on this. Thanks for the discussion anyway, at least I know now that there's no common view on it so there's no point in pushing for a change of guideline. [[User:Airblader|Airblader]] ([[User talk:Airblader|talk]]) 22:58, 11 September 2015 (UTC)<br />
<br />
:::::::::Sorry for reopening, I didn't make it in time to reply earlier...<br />
:::::::::I'll start by saying that I agree that VCS package maintainers shouldn't bump pkgver manually. However, suggesting to use a less confusing pkgvar value would seem sensible to me, e.g. we could indeed give "LATEST" as an example.<br />
:::::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:04, 13 September 2015 (UTC)<br />
<br />
:::::::::I also wanted to try to give @Airblader another perspective. You have mentioned 2 different cases:<br />
:::::::::* A package has both a "stable" and a "vcs" version, e.g. {{Pkg|i3}} and {{AUR|i3-git}}: why are you using {{AUR|i3-git}} in this case if you want to follow the normal upstream releases?<br />
:::::::::* A package only has a "vcs" version, e.g. {{AUR|wmfs2-git}} (dead, I know, but take it as an example): in this case the AUR maintainer can't be blamed for not bumping pkgver manually, so the problem is actually that there's nobody maintaining a "stable" PKGBUILD, and you could be the one filling that gap!<br />
:::::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:04, 13 September 2015 (UTC)<br />
<br />
<br />
== Add information about sub-modules in GIT section ==<br />
<br />
Git has submodules that can be updated rather than having to download the entire git repo for an update. Someone shared this with me: http://sprunge.us/HKdJ?md and I think it could be useful to document this sort of thing in the wiki. I'd try to myself but I'm not super familiar with git submodules.[[User:Meskarune|Meskarune]] ([[User talk:Meskarune|talk]]) 23:35, 8 December 2016 (UTC)<br />
:That's what https://wiki.archlinux.org/index.php/VCS_package_guidelines#Git_Submodules already says, isn't it?<br />
:[[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 00:14, 9 December 2016 (UTC)<br />
:: I was thinking it should be in the git section and expanded with a better explanation or at the very least links to more information on git sub-modules. Also why someone would want to even mess with sub-modules. I just don't feel like I know enough to write something further up myself. [[User:Meskarune|Meskarune]] ([[User talk:Meskarune|talk]]) 01:54, 9 December 2016 (UTC)<br />
<br />
<br />
== Warn against trivial pkgver bumps ==<br />
<br />
As mentioned previously on this page, there is no need (but it is okay to) commit a bumped pkgver to the AUR on upstream releases. But I think it is important to go one step further and actually instruct people not to commit a bumped pkgver every time they locally rebuild the package with a handful of new upstream commits.<br />
<br />
This is depressingly more common than it should be, and I can't actually find anywhere on the Wiki where it actually talks about this right now.<br />
[[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 16:55, 9 June 2017 (UTC)<br />
<br />
:I second this. However, this page is about how the PKGBUILD should be written, not about how packages should be managed on the [[AUR]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:07, 9 June 2017 (UTC)<br />
<br />
::Hmm, this is... actually a good point. I have added a note here[[Arch User Repository#Foo in the AUR is outdated; what do I do?|[1]]] instead, what do you think? <br />
::That could use a "Consider whether the package is actually outdated to begin with" section... -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 18:39, 9 June 2017 (UTC)<br />
<br />
:::Looks good, maybe adding something like "Tracking of upstream updates for VCS packages is the responsibility of users, not maintainers." would make it more explicit. Regarding soname bumps, pushing them does not hurt but I tend to support the same strategy as with pkgver, because people might prefer {{ic|makepkg -ef}} to keep the same revision. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:13, 9 June 2017 (UTC)<br />
<br />
::::I reject this argument. :p {{ic|makepkg -ef}} is not meant to guarantee an identical package when the PKGBUILD has been modified between runs. Why would you even want that anyway?<br />
::::Also, by preference I do generally do a pkgver bump on upstream stable releases, on the grounds that per-commit notifications are ugly but stable releases should be updated to as soon as possible. But maybe now that we are writing actual guidelines, maybe we can decide whether that is something the AUR wishes to firmly rule against. -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 22:26, 9 June 2017 (UTC)<br />
<br />
:::::I have an AUR package where the maintainer bumps the package in every single new commit. He asked for a guideline where this is written down, as he doesnt believe my "good practice" argument. I think it would be best to write it down into the guideline section of this page, as its the first place I'd search for. The AUR page might be also a suitable place, but this is not where you start searching. Please add a note, thanks. --[[User:NicoHood|NicoHood]] ([[User talk:NicoHood|talk]]) 13:32, 16 June 2017 (UTC)<br />
<br />
::::::It's been already added to [[Arch User Repository#Foo in the AUR is outdated; what do I do?]], which is the page for AUR guidelines. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:52, 16 June 2017 (UTC)<br />
<br />
:::::::Yes, but it only says you should not flag it out of date. But it does not tell the maintainer to stop version bumping. This is not clear enough and people will always ignore it then, if you tell them to stop. --[[User:NicoHood|NicoHood]] ([[User talk:NicoHood|talk]]) 15:04, 16 June 2017 (UTC)<br />
<br />
::::::::Aaaaaaand, you have now confirmed that you '''haven't actually read''' the change I made there. (I cannot believe you think I would go modify the AUR page in reference to this conversation, and then ''completely'' fail to say the one thing this discussion was about in the first place.)<br />
::::::::So I will just ignore anything you say now, I guess. At least until I have some reason to think it is actually worth my time to even consider what you are saying. :(<br />
::::::::Addendum: You could always have just added it yourself, this is a Wiki after all... -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 21:40, 16 June 2017 (UTC)<br />
<br />
:::::Hi, I'm the maintainer [[User:NicoHood|NicoHood]] is talking about, [https://aur.archlinux.org/packages/dino-git/ here] the discussion. I failed to find a guideline about how a maintainer should behave in this circumstance and as it wasn't discouraged or forbidden I decided to act as I did. One of my points is that I find annoying, as a user with more than a bounce of packages from AUR, that I have to clone every time, every repo for every package just to check for updates (some of the projects are quite big and I find this a waste of time and bandwidth). In this particular case we are talking about a project which is rapidly implementing new features and as I check periodically for updates regarding new functionalities I think other users may benefit from being notified about them. I share the point of not bumping the pkgver for every commit but I think that if a maintainer has time to update the pkgver on new features and will to do so it's not making damages to anyone. Please correct me if I'm missing something. Re-reading my commits I noticed some of them were not needed and I'll avoid to push unnecessary updates. <br />
:::::What I'm missing as well is the role of pkgver for vcs packages, expecially for those projects that don't have a release yet. Clarifying this maybe would also close the discussion. [[User:Valo|Valo]] ([[User talk:Valo|talk]]) 08:04, 19 June 2017 (UTC)<br />
<br />
::::::You can use $SRCDEST to specify a cache directory where makepkg will store the repositories in between makepkg runs. For a package which someone wants to update frequently, it makes sense to use this. :) This goes double for a rapidly-developing software which gets frequent commits. And that still isn't an excuse to "have time to update the pkgver". Strictly speaking, it is '''never''' necessary, unless changes to the dependencies or the build()/package() functions are involved. People who are that interested in the software's development, are likely already following it elsewhere, and everyone else doesn't really need to know "oh, how exciting, a couple more commits for this VCS software. There is also the matter that for looking at the history of the PKGBUILD itself, to see what changed, it requires more effort to mentally filter through many pkgver-only changes and see what actually changed with regard to the metadata/build process/etc. Noise is, well, noisy.<br />
::::::I only justify upstream releases as it is, by telling myself that users of the non-development version are expected to update immediately, so users of the development version should as well -- and because even if a user doesn't bother to update for each commit, they should definitely aspire to be running the latest official stable release.<br />
::::::Regarding the purpose of the pkgver for VCS packages, it is to ensure that users can query their installed packages to see what version of the software they have installed, and to ensure a monotonically increasing pkgver for more recent snapshots of the source code it is built from. The fact that pkgver is also something an AUR helper can compare when emulating {{ic|pacman -Syu}} is not really relevant to a VCS package, except as an added redundancy which you should be judicious about using.<br />
::::::Anyway, we now have a guideline. -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 04:29, 26 June 2017 (UTC)<br />
<br />
:On a similar note, it is also annoying to {{ic|git checkout PKGBUILD}} before {{ic|git pull}} each time there ''is'' a substantial change pushed to the AUR, but my local {{ic|pkgver}} was newer than the previous version on AUR. It's not just about running one more command, I always have to {{ic|git diff}} before to check that I don't have some other unstaged changes. Perhaps if there was some better technical solution for this (perhaps the {{ic|pkgver}} variable could be completely removed when there is a {{ic|pkgver}} function?), then maybe people would not feel the unbearable urge to immediately commit and push all unstaged changes. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:18, 9 June 2017 (UTC)<br />
<br />
::Well, you probably aren't supposed to make local changes. :p What is wrong with the AUR maintainer that you need to fix, but don't feel like asking for a better maintainer? That being said, I do actually have cases (very personal patches) where I make a local change and commit that, then use {{ic|git fetch && git rebase}}. This works quite well, so I am not sure we need a better technical solution at all. -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 18:39, 9 June 2017 (UTC)<br />
<br />
:::Not that I care about these, but at least [https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=mpv-git#n6 here] people are actually supposed to make local changes. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:13, 9 June 2017 (UTC)<br />
<br />
::::Sure, it is sometimes "supposed to" happen, but it isn't really the norm. :) As I said, {{ic|git rebase}} is a powerful tool to use there. -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 22:26, 9 June 2017 (UTC)<br />
<br />
== Git submodules: sometimes not all submodules are needed ==<br />
<br />
As per this writeup by Earnestly (which I understand is the initial source of that section): https://ptpb.pw/r/N6-z.md<br />
Some packages shouldn't try to checkout all submodules, because it is wasteful and unneeded. It might be nice to expand on that section by mentioning this. -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 14:19, 12 July 2017 (UTC)<br />
<br />
== Add notice to this page? ==<br />
The [[Arch User Repository]] page indicates:<br />
{{Note|[[VCS package guidelines|VCS packages]] are not considered out of date when the pkgver changes, so '''please''' do not flag them as the maintainer will merely unflag the package and ignore you. AUR maintainers should not commit mere pkgver bumps.}}<br />
Perhaps this should be included on this page as well, to inform new maintainers that they should not be making pkgver bumps for these packages.<br />
That being said, there should probably be a way to update the pkgver shown by the AUR web UI, or disable it entirely for VCS packages, in order to prevent others from believing a package is out of date and flagging it. [[User:JacobHenner|JacobHenner]] ([[User talk:JacobHenner|talk]]) 11:33, 17 November 2017 (UTC)<br />
<br />
== pacman 4.1 ==<br />
<br />
Shall we remove the references to 4.1?<br />
What was possible / the practice in the past may help to understand certain outdated packages but 5 years starts to be very long and we should turn the page at one stage I suppose.<br />
This is the impression of a newcomer who wants to get to the point and is confused by the reference to such old versions but don't hesitate to correct me if this is still important.<br />
[[User:Kewl|Kewl]] ([[User talk:Kewl|talk]]) 10:29, 14 January 2018 (UTC)<br />
<br />
:Agree. -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 15:00, 30 June 2020 (UTC)<br />
<br />
== Suggest to use https instead of git protocol when possible ==<br />
A lot of public structures/companies block the default git port (9418). This problem is explained here : https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols#_the_cons_4<br />
Using {{ic|git+https://}} urls for sources is supported by most (if not all) git servers, and {{ic|https}} will most likely not be blocked.<br />
<br />
{{unsigned|10:39, 22 October 2018|Salamandar}}<br />
<br />
:+1, I'd also mention that it's a security issue because {{ic|git://}} and {{ic|http://}} aren't encrypted and vulnerable to MITM attacks. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 19:10, 22 October 2018 (UTC)<br />
<br />
::+1, That's gold for me, as I'm normally behind a proxy that blocks {{ic|git://}}, but allows {{ic|git+https://}}... -- [[User:Josephgbr|Josephgbr]] ([[User talk:Josephgbr|talk]]) 02:19, 16 April 2019 (UTC)<br />
<br />
:::I see this is done in "An example Git source array". How about the other two places that illustrate using git sources? (left of {{ic|vcs+}} bullet point in [[VCS package guidelines#VCS sources|VCS sources]], on two lines in the [[VCS package guidelines#Git submodules|Git submodules]] tip) [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 15:18, 5 June 2019 (UTC)<br />
<br />
== Proposal: Break "Guidelines" header into subsections ==<br />
<br />
Too many bullet points are a navigation hazard. To help users get to the information they need faster, we should reorganize this into a few subsections. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 13:31, 4 March 2019 (UTC)<br />
<br />
: Seems to me as a good idea. Just two notes: "Security" should be lowercase in the section title "Authentication and Security", and AUR pkgbase deletion request was moved from [[Arch User Repository#Deletion]] to [[AUR submission guidelines#Requests]] since you proposed these changes. -- [[User:Josephgbr|Josephgbr]] ([[User talk:Josephgbr|talk]]) 12:02, 28 June 2019 (UTC)<br />
<br />
::Done; it is unfortunate the new ''AUR submission guidelines'' does not ([[Talk:AUR submission guidelines#Improvements from the AUR page that was reverted|yet]]) have a "#Deletion" subsection: [[User:Quequotion/AUR submission guidelines#Deletion]] [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 01:01, 29 June 2019 (UTC)<br />
<br />
:::As this is a protected page, I am not able to make the changes myself. If we have sufficient consensus here, an editor, administrator, or trusted user is needed to actually make them. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 13:40, 21 July 2019 (UTC)<br />
<br />
:::I have relocated these proposals to a [[User:Quequotion/VCS_package_guidelines#Guidelines|full page draft]] as per the [[Special:Diff/575147|new policy regarding proposals]]. If you'd like to see the whole piecemeal set of nine changes, start [[Special:Diff/641456|here]]. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 01:25, 14 November 2020 (UTC)<br />
<br />
== GitHub API usage ==<br />
<br />
Some git repos are really huge (ex. QGIS) and git-clone process takes a lot of time and space. So, here is an example how to use GH API to obtain pkgver:<br />
{{hc|<nowiki><br />
_orgname=foo<br />
_pkgname=bar<br />
_branch=master<br />
_gh_api_url="https://api.github.com/repos/${_orgname}/${_pkgname}"<br />
...<br />
makedepends=('jq')<br />
...<br />
source=("https://github.com/${_orgname}/${_pkgname}/archive/${_branch}.tar.gz")<br />
sha256sums=('SKIP')<br />
<br />
pkgver() {<br />
read -r tag_name tag_sha <<<$(curl -s "${_gh_api_url}/tags" | \<br />
jq -r '.[0]|[.name,.commit.sha]|@sh' | sed "s/'//g")<br />
head=$(curl -s "${_gh_api_url}/git/refs/heads/${_branch}" | \<br />
jq -r '.object.sha')<br />
count=$(curl -s "${_gh_api_url}/compare/${tag_sha}...${head}" | \<br />
jq -r '.total_commits')<br />
<br />
printf "%s.r%s.g%.8s" "${tag_name}" "${count}" "${head}"<br />
}</nowiki>|<br />
0.1.r7.g47de1a51<br />
}}<br />
<br />
{{unsigned|2019-06-28|Sikmir}}<br />
<br />
: ''makepkg'' still requires cloning the whole source code repository to build the package. In fact, the source code fetching happens before the [[PKGBUILD#pkgver|pkgver]] function. IMO, this option does not seem to have any use for packaging in Arch. By the way, if you use the binary ''jq'', make sure to add {{pkg|jq}} to [[PKGBUILD#makedepends|makedepends]] array. -- [[User:Josephgbr|Josephgbr]] ([[User talk:Josephgbr|talk]]) 11:37, 28 June 2019 (UTC)<br />
<br />
:: No! It doesn't require cloning, see ''source'' variable, there is only gzipped snapshot. [[User:Sikmir|Sikmir]] ([[User talk:Sikmir|talk]]) 16:18, 28 June 2019 (UTC)<br />
<br />
::: I didn't see the tarball in source before, but in my opinion a PKGBUILD with a branch/tag's tarball as source does not classify as a VCS package and, therefore, should not be included to this page. I understand GitHub's snapshot tarball represents the last commit of the software, but still you are not using a VCS. Personally, since Arch Linux has these well defined type of packages, normal/non-VCS package with defined version and VCS packages with dynamic version, I would make my dynamic versioning packages as VCS package due to the advantage of just updating the source code repository instead of re-downloading it all. -- [[User:Josephgbr|Josephgbr]] ([[User talk:Josephgbr|talk]]) 18:08, 28 June 2019 (UTC)<br />
<br />
== Add GPG Signature verification note ==<br />
<br />
It is possible to verify the git sources using gpg. This is documented in "man PKGBUILD", but most people do not know this. It would be easy to have this information in the tip section of this guideline.<br />
<br />
source=(<url>?signed)<br />
<br />
validpgpkeys=('<keyid>')<br />
<br />
[[User:NicoHood|NicoHood]] ([[User talk:NicoHood|talk]]) 07:54, 3 June 2020 (UTC)<br />
<br />
== Manually constructed 'git describe' output should be forward-compatible ==<br />
<br />
The recommendation for when no tags exist isn't forward-compatible wrt adding tags -- note the absence of a 'g' prefix in the SHA.</div>Geshhttps://wiki.archlinux.org/index.php?title=Security&diff=597183Security2020-02-10T20:02:04Z<p>Gesh: Add reference to kernel docs on CPU vulnerabilities</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[Category:Networking]]<br />
[[fa:امنیت]]<br />
[[ja:セキュリティ]]<br />
[[pt:Security]]<br />
[[ru:Security]]<br />
[[zh-hans:Security]]<br />
{{Related articles start}}<br />
{{Related|Arch Security Team}}<br />
{{Related|General recommendations}}<br />
{{Related|PAM}}<br />
{{Related|Capabilities}}<br />
{{Related|List of Applications/Security}}<br />
{{Related|Security package guidelines}}<br />
{{Related articles end}}<br />
This article contains recommendations and best practices for [[Wikipedia:Hardening (computing)|hardening]] an Arch Linux system.<br />
<br />
== Concepts ==<br />
<br />
* It ''is'' possible to tighten the security so much as to make your system unusable. The trick is to secure it without overdoing it.<br />
* There are many other things that can be done to heighten the security, but the biggest threat is, and will always be, the user. When you think security, you have to think layers. When one layer is breached, another should stop the attack. But you can never make the system 100% secure unless you unplug the machine from all networks, lock it in a safe and never use it.<br />
* Be a little paranoid. It helps. And be suspicious. If anything sounds too good to be true, it probably is!<br />
* The [[Wikipedia:Principle of least privilege|principle of least privilege]]: each part of a system should only be able to access what is required to use it, and nothing more.<br />
<br />
== Passwords ==<br />
<br />
Passwords are key to a secure Linux system. They secure your [[Users and groups|user accounts]], [[Disk encryption|encrypted filesystems]], and [[SSH keys|SSH]]/[[GPG]] keys. They are the main way a computer chooses to trust the person using it, so a big part of security is just about picking secure passwords and protecting them.<br />
<br />
=== Choosing secure passwords ===<br />
<br />
Passwords must be complex enough to not be easily guessed from e.g. personal information, or [[Wikipedia:Password cracking|cracked]] using methods like social engineering or brute-force attacks. The tenets of strong passwords are based on ''length'' and ''randomness''. In cryptography the quality of a password is referred to as its [[Wikipedia:Entropic security|entropic security]]. <br />
<br />
Insecure passwords include those containing:<br />
<br />
* Personally identifiable information (e.g., your dog's name, date of birth, area code, favorite video game)<br />
* Simple character substitutions on words (e.g., {{ic|k1araj0hns0n}}), as modern dictionary attacks can easily work with these<br />
* Root "words" or common strings followed or preceded by added numbers, symbols, or characters (e.g., {{ic|DG091101%}})<br />
* Common phrases or short phrases of grammatically related words (e.g. {{ic|all of the lights}}), and even with character substitution.<br />
* Any of the [https://en.wikipedia.org/wiki/List_of_the_most_common_passwords most common passwords]<br />
<br />
The best choice for a password is something long (8-64 characters, longer is better) and generated from a random source.<br />
<br />
Tools like {{Pkg|pwgen}} or {{AUR|apg}} can generate random passwords. However, these passwords can be difficult to memorize. One memorization technique (for ones typed often) is to generate a long password and memorize a minimally secure number of characters, temporarily writing down the full generated string. Over time, increase the number of characters typed - until the password is ingrained in muscle memory and need not be remembered. This technique is more difficult, but can provide confidence that a password will not turn up in wordlists or "intelligent" brute force attacks that combine words and substitute characters.<br />
<br />
There are also techniques for building memorable secure passwords.<br />
<br />
One technique is to use a mnemonic phase, where each word in the phase reminds you of the next character in the password.<br />
Take for instance “the girl is walking down the rainy street” could be translated to {{ic|t6!WdtR5}} or, less simply, {{ic|t&6!RrlW@dtR,57}}.<br />
This approach could make it easier to remember a password, but note that the various letters have very different probabilities of being found at the start of words ([[Wikipedia:Letter frequency#Relative frequencies of the first letters of a word in the English language|Wikipedia:Letter frequency]]). <br />
<br />
Another technique is to use a memorable long series of unrelated words as a password. If a sufficiently long phrase is used, the gained entropy from the password's length can counter the lost entropy from the use of dictionary words. This [https://xkcd.com/936/ XKCD comic] demonstrates the entropy tradeoff of this method. The [http://world.std.com/~reinhold/diceware.html Diceware Passphrase] method uses a long passphrase in combination with a random number generator (game dice).<br />
<br />
Another effective technique can be to write randomly generated passwords down and store them in a ''safe'' place, such as in a wallet, purse or document safe. Most people do a generally good job of protecting their physical valuables from attack, and it is easier for most people to understand physical security best practices compared to digital security practices. [https://www.schneier.com/news/archives/2010/11/bruce_schneier_write.html Bruce Schneier has endorsed this technique].<br />
<br />
It is also very effective to combine the memorable and random technique by saving long randomly generated passwords with a [[password manager]], which will be in turn accessed with a memorable "master password" that must be used only for that purpose. The master password must be memorized and never saved. This requires the password manager to be installed on a system to easily access the password (which could be seen as an inconvenience or a security feature, depending on the situation). Some password managers also have smartphone apps which can be used to display passwords for manual entry on systems without that password manager installed. Note that a password manager introduces a single point of failure if you ever forget the master password.<br />
<br />
<br />
See Bruce Schneier's article [https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html Choosing Secure Passwords], [https://www.iusmentis.com/security/passphrasefaq/ The passphrase FAQ] or [[Wikipedia:Password strength]] for some additional background.<br />
<br />
=== Maintaining passwords ===<br />
<br />
Once you pick a strong password, be sure to keep it safe. Watch out for [[Wikipedia:Keylogger|keyloggers]] (software and hardware), screen loggers, [[Wikipedia:Social engineering (security)|social engineering]], [[Wikipedia:Shoulder surfing (computer security)|shoulder surfing]], and avoid reusing passwords so insecure servers cannot leak more information than necessary. [[List of applications/Security#Password managers|Password managers]] can help manage large numbers of complex passwords: if you are copy-pasting the stored passwords from the manager to the applications that need them, make sure to clear the copy buffer every time, and ensure they are not saved in any kind of log (e.g. do not paste them in plain terminal commands, which would store them in files like {{ic|.bash_history}}).<br />
<br />
As a rule, do not pick insecure passwords just because secure ones are harder to remember. Passwords are a balancing act. It is better to have an encrypted database of secure passwords, guarded behind a key and one strong master password, than it is to have many similar weak passwords. Writing passwords down is perhaps equally effective[https://www.schneier.com/blog/archives/2005/06/write_down_your.html], avoiding potential vulnerabilities in software solutions while requiring physical security.<br />
<br />
Another aspect of the strength of the passphrase is that it must not be easily recoverable from other places.<br />
If you use the same passphrase for disk encryption as you use for your login password (useful e.g. to auto-mount the encrypted partition or folder on login), make sure that {{ic|/etc/shadow}} either also ends up on an encrypted partition, or uses a strong hash algorithm (i.e. sha512/bcrypt, not md5) for the stored password hash (see [[SHA password hashes]] for more information).<br />
<br />
If you are backing up your password database, make sure that each copy is not stored behind any other passphrase which in turn is stored in it, e.g. an encrypted drive or an authenticated remote storage service, or you will not be able to access it in case of need; a useful trick is to protect the drives or accounts where the database is backed up using a simple cryptographic hash of the master password. Maintain a list of all the backup locations: if one day you fear that the master passphrase has been compromised you will have to change it immediately on all the database backups and the locations protected with keys derived from the master password. Version-controlling the database in a secure way can be very complicated: if you choose to do it, you must have a way to update the master password of all the database versions. It may not always be immediately clear when the master password is leaked: to reduce the risk of somebody else discovering your password before you realize that it leaked, you may choose to change it on a periodical basis. If you fear that you have lost control over a copy of the database, you will need to change all the passwords contained in it within the time that it may take to brute-force the master password, according to its entropy.<br />
<br />
=== Password hashes ===<br />
<br />
{{Expansion|Mention [[Wikipedia:Key derivation function|key derivation functions]], in particular PBKDF2, bcrypt and scrypt, how to use them, advantages and disadvantages, especially regarding custom-hardware-based brute-force attacks.|section=Removal of incorrect warning}}<br />
<br />
By default, Arch stores the hashed user passwords in the root-only-readable {{ic|/etc/shadow}} file, separated from the other user parameters stored in the world-readable {{ic|/etc/passwd}} file, see [[Users and groups#User database]]. See also [[#Restricting root]].<br />
<br />
Passwords are set with the '''passwd''' command, which [[Wikipedia:Key stretching|stretches]] them with the [[Wikipedia:Crypt (C)|crypt]] function and then saves them in {{ic|/etc/shadow}}. See also [[SHA password hashes]]. The passwords are also [[Wikipedia:Salt (cryptography)|salted]] in order to defend them against [[Wikipedia:Rainbow table|rainbow table]] attacks.<br />
<br />
See also [http://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils How are passwords stored in Linux (Understanding hashing with shadow utils)].<br />
<br />
=== Enforcing strong passwords using pam_cracklib ===<br />
<br />
''pam_cracklib'' provides protection against [[Wikipedia:Dictionary attack|Dictionary attacks]] and helps configure a password policy that can be enforced throughout the system.<br />
<br />
{{Warning|The ''root'' account is not affected by this policy.}}<br />
<br />
{{Note|You can use the ''root'' account to set a password for a user that bypasses the desired/configured policy. This is useful when setting temporary passwords.}}<br />
<br />
If for example you want to enforce this policy:<br />
<br />
* prompt 2 times for password in case of an error<br />
* 10 characters minimum length (minlen option)<br />
* at least 6 characters should be different from old password when entering a new one (difok option)<br />
* at least 1 digit (dcredit option)<br />
* at least 1 uppercase (ucredit option)<br />
* at least 1 other character (ocredit option)<br />
* at least 1 lowercase (lcredit option)<br />
<br />
Edit the {{ic|/etc/pam.d/passwd}} file to read as:<br />
<br />
{{bc|1=<br />
#%PAM-1.0<br />
password required pam_cracklib.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1<br />
password required pam_unix.so use_authtok sha512 shadow<br />
}}<br />
<br />
The {{ic|password required pam_unix.so use_authtok}} instructs the ''pam_unix'' module to not prompt for a password but rather to use the one provided by ''pam_cracklib''.<br />
<br />
You can refer to the {{man|8|pam_cracklib}} and {{man|8|pam_unix}} man pages for more information.<br />
<br />
== CPU ==<br />
<br />
=== Microcode ===<br />
<br />
See [[microcode]] for information on how to install important security updates for your CPU's microcode.<br />
<br />
=== Disable Hyper-Threading ===<br />
<br />
[https://www.youtube.com/watch?v=jI3YE3Jlgw8 Kernel Developer Greg Kroah-Hartman has endorsed disabling Hyper-Threading] as a security hardening option for systems running untrusted code. (Web browsers that enable Javascript are an example of untrusted code.) This may have a small performance impact.<br />
<br />
Hyper-Threading can be disabled in the kernel (see [[#Disable_hyper-threading_2]]), and often can also be disabled in your system's firmware. Consult your motherboard or system documentation for more information.<br />
<br />
=== CPU Vulnerabilities ===<br />
<br />
{{Expansion|Give a good set of defaults, plus discussion of the tradeoffs involved.}}<br />
<br />
In the wake of the Spectre/Meltdown vulnerabilities, certain configurable mitigations have been added to the kernel. Refer to [https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/ the kernel docs] for more details.<br />
<br />
== Memory ==<br />
<br />
=== Hardened malloc ===<br />
<br />
[https://github.com/GrapheneOS/hardened_malloc hardened_malloc] ({{AUR|hardened_malloc}}) is a hardened replacement for glibc's malloc(). The project was originally developed for integration into Android's Bionic and musl by Daniel Micay, of GrapheneOS, but he has also built in support for standard Linux distributions on the x86_64 architecture.<br />
<br />
While hardened_malloc is not yet integrated into glibc (assistance and pull requests welcome) it can be used easily with LD_PRELOAD. In testing so far, it only causes issues with a handful of applications if enabled globally in /etc/ld.so.preload. For example, man fails to work properly unless its seccomp environment flag is disabled due to not having {{ic|getrandom}} in the standard whitelist, although this can be easily fixed by rebuilding it with the system call added. Since hardened_malloc has a performance cost, you may want to decide which implementation to use on a case-by-case basis based on attack surface and performance needs.<br />
<br />
To try it out in a standalone manner, use the hardened-malloc-preload wrapper script, or manually start an application with the proper preload value:<br />
<br />
LD_PRELOAD="/usr/lib/libhardened_malloc.so" /usr/bin/firefox<br />
<br />
Proper usage with [[Firejail]] can be found on its wiki page, and some configurable build options for hardened_malloc can be found on the github repo.<br />
<br />
== Storage ==<br />
<br />
=== Disk encryption ===<br />
<br />
[[Disk encryption]], preferably full disk encryption with a [[#Passwords|strong passphrase]], is the only way to guard data against physical recovery. This provides complete security when the computer is turned off or the disks in question are unmounted.<br />
<br />
Once the computer is powered on and the drive is mounted, however, its data becomes just as vulnerable as an unencrypted drive. It is therefore best practice to unmount data partitions as soon as they are no longer needed.<br />
<br />
Certain programs, like [[dm-crypt]], allow the user to encrypt a loop file as a virtual volume. This is a reasonable alternative to full disk encryption when only certain parts of the system need be secure.<br />
<br />
=== File systems ===<br />
<br />
The kernel now prevents security issues related to hardlinks and symlinks if the {{ic|fs.protected_hardlinks}} and {{ic|fs.protected_symlinks}} sysctl switches are enabled, so there is no longer a major security benefit from separating out world-writable directories.<br />
<br />
File systems containing world-writable directories can still be kept separate as a coarse way of limiting the damage from disk space exhaustion. However, filling {{ic|/var}} or {{ic|/tmp}} is enough to take down services. More flexible mechanisms for dealing with this concern exist (like [[Disk quota|quotas]]), and some [[file systems]] include related features themselves (Btrfs has quotas on subvolumes).<br />
<br />
==== Mount options ====<br />
<br />
Following the principle of least privilege, file systems should be mounted with the most restrictive mount options possible (without losing functionality).<br />
<br />
Relevant mount options are:<br />
<br />
* {{ic|nodev}}: Do not interpret character or block special devices on the file system.<br />
* {{ic|nosuid}}: Do not allow set-user-identifier or set-group-identifier bits to take effect.<br />
* {{ic|noexec}}: Do not allow direct execution of any binaries on the mounted file system.<br />
** Setting {{ic|noexec}} on {{ic|/home}} disallows executable scripts and breaks [[Wine]]* and [[Steam]].<br />
** Some packages (building {{Pkg|nvidia-dkms}} for example) may require {{ic|exec}} on {{ic|/var}}.<br />
<br />
{{Note|Wine does not need the {{ic|exec}} flag for opening Windows executables. It is only needed when Wine itself is installed in {{ic|/home}}.}}<br />
<br />
File systems used for data should always be mounted with {{ic|nodev}}, {{ic|nosuid}} and {{ic|noexec}}.<br />
<br />
Potential file system mounts to consider:<br />
<br />
* {{ic|/var}}<br />
* {{ic|/home}}<br />
* {{ic|/dev/shm}}<br />
* {{ic|/tmp}}<br />
* {{ic|/boot}}<br />
<br />
=== File access permissions ===<br />
<br />
The default [[file permissions]] allow read access to almost everything and changing the permissions can hide valuable information from an attacker who gains access to a non-root account such as the {{ic|http}} or {{ic|nobody}} users.<br />
<br />
For example:<br />
<br />
# chmod 700 /boot /etc/{iptables,arptables}<br />
<br />
The default [[Umask]] {{ic|0022}} can be changed to improve security for newly created files. The [https://apps.nsa.gov/iaarchive/library/ia-guidance/security-configuration/operating-systems/guide-to-the-secure-configuration-of-red-hat-enterprise.cfm NSA RHEL5 Security Guide] suggests a umask of {{ic|0077}} for maximum security, which makes new files not readable by users other than the owner. To change this, see [[Umask#Set the mask value]].<br />
<br />
== User setup ==<br />
<br />
After installation make a normal user for daily use. Do not use the root user for daily use.<br />
<br />
=== Enforce a delay after a failed login attempt ===<br />
<br />
Add the following line to {{ic|/etc/pam.d/system-login}} to add a delay of at least 4 seconds between failed login attempts:<br />
<br />
{{hc|/etc/pam.d/system-login|2=<br />
auth optional pam_faildelay.so delay=4000000<br />
}}<br />
<br />
{{ic|4000000}} is the time in microseconds to delay.<br />
<br />
=== Lockout user after three failed login attempts ===<br />
<br />
To further heighten the security it is possible to lockout a user after a specified number of failed login attempts. The user account can either be locked until the root user unlocks it, or automatically be unlocked after a set time.<br />
<br />
To lockout a user for ten minutes {{ic|1=unlock_time=600}} after three failed login attempts {{ic|1=deny=3}}, add the parameters to the PAM configuration as follows:<br />
<br />
{{hc|/etc/pam.d/system-login|2=<br />
auth required pam_tally2.so deny=3 unlock_time=600 onerr=succeed file=/var/log/tallylog<br />
}}<br />
<br />
That is all there is to it. If you feel adventurous, make three failed login attempts. Then you can see for yourself what happens. To unlock a user manually do:<br />
<br />
# pam_tally2 --reset --user ''username''<br />
<br />
{{ic|unlock_time}} is specified in seconds. If you want to permanently lockout a user after 3 failed login attempts remove the {{ic|unlock_time}} part of the line. The user is then unable to login until root unlocks the account.<br />
<br />
=== Limit amount of processes ===<br />
<br />
On systems with many, or untrusted users, it is important to limit the number of processes each can run at once, therefore preventing [[Wikipedia:Fork bomb|fork bombs]] and other denial of service attacks. {{ic|/etc/security/limits.conf}} determines how many processes each user, or group can have open, and is empty (except for useful comments) by default. Adding the following lines to this file will limit all users to 100 active processes, unless they use the {{ic|prlimit}} command to explicitly raise their maximum to 200 for that session. These values can be changed according to the appropriate number of processes a user should have running, or the hardware of the box you are administrating. <br />
<br />
* soft nproc 100<br />
* hard nproc 200<br />
<br />
The current number of threads for each user can be found with {{ic|ps --no-headers -Leo user {{!}} sort {{!}} uniq --count}}. This may help with determining appropriate values for the limits.<br />
<br />
=== Run Xorg rootless ===<br />
<br />
[[Xorg]] is commonly [https://security.stackexchange.com/questions/4641/why-are-people-saying-that-the-x-window-system-is-not-secure/4646#4646 considered insecure] because of its architecture and dated design. Thus it is recommended to avoid running it as root.<br />
<br />
See [[Xorg#Rootless Xorg]] for more details how to run it without root privileges.<br />
<br />
== Restricting root ==<br />
<br />
The root user is, by definition, the most powerful user on a system. Because of this, there are a number of ways to keep the power of the root user while limiting its ability to cause harm, or at least to make root user actions more traceable.<br />
<br />
=== Use sudo instead of su ===<br />
<br />
{{Merge|sudo|There's a dedicated article.}}<br />
<br />
Using [[sudo]] for privileged access is preferable to [[su]] for [[Su#Sudo, an alternative|a number of reasons]].<br />
<br />
* It keeps a log of which normal privilege user has run each privileged command.<br />
* The root user password need not be given out to each user who requires root access.<br />
* {{ic|sudo}} prevents users from accidentally running commands as ''root'' that do not need root access, because a full root terminal is not created. This aligns with the [[Wikipedia:Principle of least privilege|principle of least privilege]].<br />
* Individual programs may be enabled per user, instead of offering complete root access just to run one command. For example, to give the user ''alice'' access to a particular program:<br />
<br />
# visudo<br />
<br />
{{hc|/etc/sudoers|2=<br />
alice ALL = NOPASSWD: /path/to/program<br />
}}<br />
<br />
Or, individual commands can be allowed for all users. To mount Samba shares from a server as a regular user:<br />
<br />
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs<br />
<br />
This allows all users who are members of the group users to run the commands {{ic|/sbin/mount.cifs}} and {{ic|/sbin/umount.cifs}} from any machine (ALL).<br />
<br />
{{Tip|<br />
To use restricted version of {{ic|nano}} instead of {{ic|vi}} with {{ic|visudo}},<br />
<br />
{{hc|/etc/sudoers|2=<br />
Defaults editor=/usr/bin/rnano<br />
}}<br />
<br />
Exporting {{ic|1=EDITOR=nano visudo}} is regarded as a severe security risk since everything can be used as an {{ic|EDITOR}}.<br />
}}<br />
<br />
==== Editing files using sudo ====<br />
<br />
Running a text editor as root can be a security vulnerability as many editors can run arbitrary shell commands or affect files other than the one you intend to edit. To avoid this, use {{ic|sudoedit filename}} (equivalently, {{ic|sudo --edit filename}}) to edit files. This edits a copy of the file using your normal user privileges and then overwrites the original using sudo only after the editor is closed. You can change the editor this uses by setting the {{ic|SUDO_EDITOR}} environment variable:<br />
<br />
$ export SUDO_EDITOR=vim<br />
<br />
Alternatively, use an editor like {{ic|rvim}} which has restricted capabilities in order to be safe to run as root.<br />
<br />
=== Restricting root login ===<br />
<br />
Once [[sudo]] is properly configured, full root access can be heavily restricted or denied without losing much usability. To disable root, but still allowing to use [[sudo]], you can use {{ic|passwd --lock root}}.<br />
<br />
==== Allow only certain users ====<br />
<br />
The [[PAM]] {{ic|pam_wheel.so}} lets you allow only users in the group {{ic|wheel}} to login using [[su]]. See [[su#su and wheel]].<br />
<br />
==== Denying SSH login ====<br />
<br />
Even if you do not wish to deny root login for local users, it is always good practice to [[OpenSSH#Deny|deny root login via SSH]]. The purpose of this is to add an additional layer of security before a user can completely compromise your system remotely.<br />
<br />
==== Specify acceptable login combinations with access.conf ====<br />
<br />
When someone attempts to log in with [[PAM]], {{ic|/etc/security/access.conf}} is checked for the first combination that matches their login properties. Their attempt then fails or succeeds based on the rule for that combination. <br />
<br />
+:root:LOCAL<br />
-:root:ALL<br />
<br />
Rules can be set for specific groups and users. In this example, the user archie is allowed to login locally, as are all users in the wheel and adm groups. All other logins are rejected:<br />
<br />
+:archie:LOCAL<br />
+:(wheel):LOCAL<br />
+:(adm):LOCAL<br />
-:ALL:ALL<br />
<br />
Read more at {{man|5|access.conf}}<br />
<br />
== Mandatory access control ==<br />
<br />
[[Wikipedia:Mandatory Access Control|Mandatory access control]] (MAC) is a type of security policy that differs significantly from the [[Wikipedia:Discretionary Access Control|discretionary access control]] (DAC) used by default in Arch and most Linux distributions. MAC essentially means that every action a program could perform that affects the system in any way is checked against a security ruleset. This ruleset, in contrast to DAC methods, cannot be modified by users. Using virtually any mandatory access control system will significantly improve the security of your computer, although there are differences in how it can be implemented.<br />
<br />
=== Pathname MAC ===<br />
<br />
Pathname-based access control is a simple form of access control that offers permissions based on the path of a given file. The downside to this style of access control is that permissions are not carried with files if they are moved about the system. On the positive side, pathname-based MAC can be implemented on a much wider range of filesystems, unlike labels-based alternatives.<br />
<br />
* [[AppArmor]] is a [[Wikipedia:Canonical_(company)|Canonical]]-maintained MAC implementation seen as an "easier" alternative to SELinux.<br />
* [[Tomoyo]] is another simple, easy-to-use system offering mandatory access control. It is designed to be both simple in usage and in implementation, requiring very few dependencies.<br />
<br />
=== Labels MAC ===<br />
<br />
Labels-based access control means the extended attributes of a file are used to govern its security permissions. While this system is arguably more flexible in its security offerings than pathname-based MAC, it only works on filesystems that support these extended attributes.<br />
<br />
* [[SELinux]], based on a [[Wikipedia:NSA|NSA]] project to improve Linux security, implements MAC completely separate from system users and roles. It offers an extremely robust multi-level MAC policy implementation that can easily maintain control of a system that grows and changes past its original configuration.<br />
<br />
=== Access Control Lists ===<br />
<br />
[[Access Control Lists]] (ACLs) are an alternative to attaching rules directly to the filesystem in some way. ACLs implement access control by checking program actions against a list of permitted behavior.<br />
<br />
== Kernel hardening ==<br />
<br />
=== Kernel self-protection / exploit mitigation ===<br />
<br />
The {{pkg|linux-hardened}} package uses a [https://github.com/anthraxx/linux-hardened basic kernel hardening patch set] and more security-focused compile-time configuration options than the {{pkg|linux}} package. A custom build can be made to choose a different compromise between security and performance than the security-leaning defaults.<br />
<br />
If you use an out-of-tree driver such as [[NVIDIA]], you may need to switch to its [[DKMS]] package.<br />
<br />
==== Userspace ASLR comparison ====<br />
<br />
The {{pkg|linux-hardened}} package provides an improved implementation of Address Space Layout Randomization for userspace processes. The {{pkg|paxtest}} command can be used to obtain an estimate of the provided entropy:<br />
<br />
===== 64-bit processes =====<br />
<br />
{{hc|linux-hardened|<br />
Anonymous mapping randomization test : 32 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 26 quality bits (guessed)<br />
Heap randomization test (PIE) : 40 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 32 quality bits (guessed)<br />
Shared library randomization test : 32 quality bits (guessed)<br />
VDSO randomization test : 32 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 40 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 40 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 44 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 44 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 32 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 34 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 32 bits (guessed)<br />
Randomization under memory exhaustion @0 : 32 bits (guessed)<br />
}}<br />
<br />
{{hc|linux|<br />
Anonymous mapping randomization test : 28 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 13 quality bits (guessed)<br />
Heap randomization test (PIE) : 28 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 28 quality bits (guessed)<br />
Shared library randomization test : 28 quality bits (guessed)<br />
VDSO randomization test : 20 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 28 bits (guessed)<br />
Randomization under memory exhaustion @0 : 28 bits (guessed)<br />
}}<br />
<br />
===== 32-bit processes (on an x86_64 kernel) =====<br />
<br />
{{hc|linux-hardened|<br />
Anonymous mapping randomization test : 16 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 22 quality bits (guessed)<br />
Heap randomization test (PIE) : 27 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 18 quality bits (guessed)<br />
Shared library randomization test : 16 quality bits (guessed)<br />
VDSO randomization test : 16 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 24 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 24 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 28 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 28 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 18 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 16 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 18 bits (guessed)<br />
Randomization under memory exhaustion @0 : 18 bits (guessed)<br />
}}<br />
<br />
{{hc|linux|<br />
Anonymous mapping randomization test : 8 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 13 quality bits (guessed)<br />
Heap randomization test (PIE) : 13 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 8 quality bits (guessed)<br />
Shared library randomization test : 8 quality bits (guessed)<br />
VDSO randomization test : 8 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 19 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 19 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 11 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 11 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 8 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 13 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: No randomization<br />
Randomization under memory exhaustion @0 : No randomization<br />
}}<br />
<br />
=== Restricting access to kernel logs ===<br />
<br />
{{Tip|This is enabled by default in {{pkg|linux-hardened}}.}}<br />
<br />
The kernel logs contain useful information for an attacker trying to exploit kernel vulnerabilities, such as sensitive memory addresses. The {{ic|kernel.dmesg_restrict}} flag was to forbid access to the logs without the {{ic|CAP_SYS_ADMIN}} capability (which only processes running as root have by default).<br />
<br />
{{hc|/etc/sysctl.d/51-dmesg-restrict.conf|2=<br />
kernel.dmesg_restrict = 1<br />
}}<br />
<br />
=== Restricting access to kernel pointers in the proc filesystem ===<br />
<br />
{{Note|{{pkg|linux-hardened}} sets {{ic|1=kptr_restrict=2}} by default rather than {{ic|0}}.}}<br />
<br />
Setting {{ic|kernel.kptr_restrict}} to 1 will hide kernel symbol addresses in {{ic|/proc/kallsyms}} from regular users without {{ic|CAP_SYSLOG}}, making it more difficult for kernel exploits to resolve addresses/symbols dynamically. This will not help that much on a pre-compiled Arch Linux kernel, since a determined attacker could just download the kernel package and get the symbols manually from there, but if you are compiling your own kernel, this can help mitigating local root exploits. This will break some {{Pkg|perf}} commands when used by non-root users (but many {{Pkg|perf}} features require root access anyway). See {{Bug|34323}} for more information.<br />
<br />
Setting {{ic|kernel.kptr_restrict}} to 2 will hide kernel symbol addresses in {{ic|/proc/kallsyms}} regardless of privileges.<br />
<br />
{{hc|/etc/sysctl.d/51-kptr-restrict.conf|2=<br />
kernel.kptr_restrict = 1<br />
}}<br />
<br />
=== BPF hardening ===<br />
<br />
BPF is a system used to load and execute bytecode within the kernel dynamically during runtime. It is used in a number of Linux kernel subsystems such as networking (e.g. XDP, tc), tracing (e.g. kprobes, uprobes, tracepoints) and security (e.g. seccomp). It is also useful for advanced network security, performance profiling and dynamic tracing.<br />
<br />
BPF was originally an acronym of "Berkeley Packet Filter" since the original classic BPF was used for packet capture tools for BSD. This eventually evolved into Extended BPF (eBPF), which was shortly afterwards renamed to just BPF (not an acronym). BPF should not be confused with packet filtering tools like iptables or netfilter, although BPF can be used to implement packet filtering tools.<br />
<br />
BPF code may be either interpreted or compiled using a Just-In-Time (JIT) compiler. The Arch kernel is built with {{ic|CONFIG_BPF_JIT_ALWAYS_ON}} which disables the BPF interpreter and forces all BPF to use JIT compilation. This makes it harder for an attacker to use BPF to escalate attacks that exploit SPECTRE-style vulnerabilities. See [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=290af86629b25ffd1ed6232c4e9107da031705cb the kernel patch which introduced CONFIG_BPF_JIT_ALWAYS_ON] for more details.<br />
<br />
The kernel includes a hardening feature for JIT-compiled BPF which can mitigate some types of JIT spraying attacks at the cost of performance and the ability to trace and debug many BPF programs. It may be enabled by setting {{ic|net.core.bpf_jit_harden}} to {{ic|1}} (to enable hardening of unprivileged code) or {{ic|2}} (to enable hardening of all code).<br />
<br />
See the {{ic|net.core.bpf_*}} settings in the [https://www.kernel.org/doc/Documentation/sysctl/net.txt kernel documentation] for more details.<br />
<br />
=== ptrace scope ===<br />
<br />
Arch enables the Yama LSM by default, providing a {{ic|kernel.yama.ptrace_scope}} flag. This flag is enabled by default and prevents processes from performing a {{ic|ptrace}} call on other processes outside of their scope without {{ic|CAP_SYS_PTRACE}}. While many debugging tools require this for some of their functionality, it is a significant improvement in security. Without this feature, there is essentially no separation between processes running as the same user without applying extra layers like namespaces. The ability to attach a debugger to an existing process is a demonstration of this weakness.<br />
<br />
==== Examples of broken functionality ====<br />
<br />
{{Note|You can still execute these commands as root (such as allowing them through [[sudo]] for certain users, with or without a password).}}<br />
<br />
* {{ic|gdb -p $PID}}<br />
* {{ic|strace -p $PID}}<br />
* {{ic|perf trace -p $PID}}<br />
* {{ic|reptyr $PID}}<br />
<br />
=== hidepid ===<br />
<br />
{{Warning|<br />
* This may cause issues for certain applications like an application running in a sandbox and [[Xorg]] (see workaround).<br />
* This causes issues with [[D-Bus]], [[PulseAudio]] and [[bluetooth]] when using {{Pkg|systemd}} > 237.64-1.<br />
}}<br />
<br />
The kernel has the ability to hide other users' processes, normally accessible via {{ic|/proc}}, from unprivileged users by mounting the {{ic|proc}} filesystem with the {{ic|1=hidepid=}} and {{ic|1=gid=}} options documented [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/proc.txt#n1919 here]. <br />
<br />
This greatly complicates an intruder's task of gathering information about running processes, whether some daemon runs with elevated privileges, whether other user runs some sensitive program, whether other users run any program at all, makes it impossible to learn whether any user runs a specific program (given the program does not reveal itself by its behaviour), and, as an additional bonus, poorly written programs passing sensitive information via program arguments are now protected against local eavesdroppers.<br />
<br />
The {{ic|proc}} [[Users_and_groups#System_groups|group]], provided by the {{Pkg|filesystem}} package, acts as a whitelist of users authorized to learn other users' process information. If users or services need access to {{ic|/proc/<pid>}} directories beyond their own, [[Users_and_groups#Group_management|add them to the group]].<br />
<br />
For example, to hide process information from other users except those in the {{ic|proc}} group:<br />
<br />
{{hc|/etc/fstab|2=<br />
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0<br />
}}<br />
<br />
For user sessions to work correctly, an exception needs to be added for ''systemd-logind'':<br />
<br />
{{hc|/etc/systemd/system/systemd-logind.service.d/hidepid.conf|2=<br />
[Service]<br />
SupplementaryGroups=proc<br />
}}<br />
<br />
=== Restricting module loading ===<br />
<br />
The default Arch kernel has {{ic|CONFIG_MODULE_SIG_ALL}} enabled which signs all kernel modules build as part of the {{Pkg|linux}} package. This allows the kernel to restrict modules to be only loaded when they are signed with a valid key, in practical terms this means that all out of tree modules compiled locally or provides by packages such as {{Pkg|wireguard-arch}} cannot be loaded. Restricting loading kernel modules can be done by adding {{ic|1=module.sig_enforce=1}} to the kernel command line, further documentation can be found at https://www.kernel.org/doc/html/latest/admin-guide/module-signing.html.<br />
<br />
=== Disable kexec ===<br />
<br />
{{Tip|kexec is disabled by default in {{pkg|linux-hardened}}.}}<br />
<br />
Kexec allows replacing the current running kernel.<br />
<br />
{{hc|/etc/sysctl.d/51-kexec-restrict.conf|2=<br />
kernel.kexec_loaded_disabled = 1<br />
}}<br />
<br />
=== Kernel lockdown mode ===<br />
<br />
Since Linux 5.4 the kernel has gained an optional [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aefcf2f4b58155d27340ba5f9ddbe9513da8286d lockdown feature], intended to strengthen the boundary between UID 0 (root) and the kernel. When enabled some applications may cease to work who rely on low-level access to either hardware or the kernel. Lockdown has two modes of operation:<br />
<br />
# When set to {{ic|integrity}}, kernel features that allow userland to modify the running kernel are disabled (kexec, bpf).<br />
# When set to {{ic|confidentiality}}, kernel features that allow userland to extract confidential information from the kernel are also disabled.<br />
<br />
To enable kernel lockdown at runtime, run:<br />
<br />
# echo ''mode'' > /sys/kernel/security/lockdown<br />
<br />
To enable kernel lockdown on boot, use the [[kernel parameter]] {{ic|1=lockdown=''mode''}}.<br />
<br />
{{Note|Kernel lockdown cannot be disabled at runtime.}}<br />
<br />
=== Disable hyper-threading ===<br />
<br />
If your computer contains an [[Intel]] CPU, disabling [[Wikipedia: Hyper-threading|hyper-threading]] is a security consideration due to [[Wikipedia:Microarchitectural Data Sampling|Microarchitectural Data Sampling]], see https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html.<br />
<br />
To check if you are affected, run the following:<br />
<br />
$ grep . -r /sys/devices/system/cpu/vulnerabilities/<br />
<br />
{{Expansion|Recommend disabling hyper-threading in firmware.}}<br />
<br />
If the output contains {{ic|SMT vulnerable}}, you should disable hyper-threading. Do note that there will be a performance impact. If this is an acceptable trade-off, add the following [[kernel parameters]]:<br />
<br />
l1tf=full,force mds=full,nosmt mitigations=auto,nosmt nosmt=force<br />
<br />
Reboot afterward and verify the output of grep. It should now say {{ic|SMT disabled}}.<br />
<br />
== Sandboxing applications ==<br />
<br />
See also [[Wikipedia:Sandbox (computer security)]].<br />
<br />
{{Note|The user namespace configuration item {{ic|CONFIG_USER_NS}} is currently enabled in {{Pkg|linux}} (4.14.5 or later), {{Pkg|linux-lts}} (4.14.15 or later) and {{Pkg|linux-hardened}}. Lack of it may prevent certain sandboxing features from being made available to applications.}}<br />
<br />
{{Warning|Unprivileged user namespace usage ({{ic|CONFIG_USER_NS_UNPRIVILEGED}}) is enabled by default in {{Pkg|linux}} (5.1.8 or later), {{Pkg|linux-lts}} (4.19.55-2 or later) and {{Pkg|linux-zen}} (5.1.14.zen1-2 or later) unless the {{ic|kernel.unprivileged_userns_clone}} [[sysctl]] is set to {{ic|0}}. Since this greatly increases the attack surface for local privilege escalation, it is advised to disable this manually, or use the {{Pkg|linux-hardened}} kernel. For more information see {{Bug|36969}}.}}<br />
<br />
=== Firejail ===<br />
<br />
[[Firejail]] is an easy to use and simple tool for sandboxing applications and servers alike. Firejail is suggested for browsers and internet facing applications, as well as any servers you may be running.<br />
<br />
=== bubblewrap ===<br />
<br />
[[bubblewrap]] is a sandbox application developed from [[Wikipedia:Flatpak|Flatpak]] with an even smaller resource footprint than Firejail. While it lacks certain features such as file path whitelisting, bubblewrap does offer bind mounts as well as the creation of user/IPC/PID/network/cgroup namespaces and can support both simple and [https://github.com/projectatomic/bubblewrap/blob/master/demos/bubblewrap-shell.sh complex sandboxes]. A list of sandbox profiles for some common applications can be found in [https://github.com/valoq/bwscripts].<br />
<br />
=== chroots ===<br />
<br />
Manual [[chroot]] jails can also be constructed.<br />
<br />
=== Linux containers ===<br />
<br />
[[Linux Containers]] are another good option when you need more separation than the other options (short of KVM and VirtualBox) provide. LXC's run on top of the existing kernel in a pseudo-chroot with their own virtual hardware.<br />
<br />
=== Other virtualization options ===<br />
<br />
Using full virtualization options such as [[VirtualBox]], [[KVM]], [[Xen]] or [https://www.qubes-os.org/ Qubes OS] (based on Xen) can also improve isolation and security in the event you plan on running risky applications or browsing dangerous websites.<br />
<br />
== Network and firewalls ==<br />
<br />
=== Firewalls ===<br />
<br />
While the stock Arch kernel is capable of using [[Wikipedia:Netfilter|Netfilter]]'s [[iptables]] and [[nftables]], they are not enabled by default. It is highly recommended to set up some form of firewall to protect the services running on the system. Many resources (including ArchWiki) do not state explicitly which services are worth protecting, so enabling a firewall is a good precaution.<br />
<br />
* See [[iptables]] and [[nftables]] for general information.<br />
* See [[Simple stateful firewall]] for a guide on setting up an iptables firewall.<br />
* See [[:Category:Firewalls]] for other ways of setting up netfilter.<br />
* See [[Ipset]] for blocking lists of ip addresses, such as those from Bluetack.<br />
<br />
=== Kernel parameters ===<br />
<br />
Kernel parameters which affect networking can be set using [[Sysctl]]. For how to do this, see [[Sysctl#TCP/IP stack hardening]].<br />
<br />
=== SSH ===<br />
<br />
To mitigate [[Wikipedia:Brute-force attack|brute-force attacks]] it is recommended to enforce key-based authentication. For OpenSSH, see [[OpenSSH#Force public key authentication]]. Alternatively [[Fail2ban]] or [[Sshguard]] offer lesser forms of protection by monitoring logs and writing [[Iptables|iptables rules]] but open up the potential for a denial of service, since an attacker can spoof packets as if they came from the administrator after identifying their address.<br />
<br />
You may want to harden authentication even more by using two-factor authentication. [[Google Authenticator]] provides a two-step authentication procedure using one-time passcodes (OTP).<br />
<br />
Denying root login is also a good practice, both for tracing intrusions and adding an additional layer of security before root access. For OpenSSH, see [[OpenSSH#Deny]].<br />
<br />
=== DNS ===<br />
<br />
{{Accuracy|Your browser might notice DNS spoofing with [[HSTS]].}}<br />
<br />
[[DNS]] queries are, by default on most systems, sent and received unencrypted and without checking for authentication of receipt from qualified servers. This could then allow [[Wikipedia:Man-in-the-middle_attack|man-in-the-middle attacks]], whereby an attacker intercepts your DNS queries and modifies the responses to deliver you an IP address leading to a [[Wikipedia:Phishing|phishing]] page to collect your valuable information. Neither you nor the browser/other software would be aware since the DNS protocol takes the legitimacy of query results for granted.<br />
<br />
[[DNSSEC]] is a set of standards in place that requires DNS servers to provide clients with origin authentication of DNS data, authenticated denial of existence, and data integrity. It, however, is not yet widely used. With DNSSEC enabled, an attacker can not make modifications to your DNS queries and the returning results, but would still be able to read them.<br />
<br />
[[DNSCrypt]], as well as later alternative protocol developments ''DNS over TLS'' and ''DNS over HTTPS'', use cryptography to secure communications with DNS servers. Usually only one protocol is employed on a system level. See [[Domain name resolution#DNS servers]] for supporting software.<br />
<br />
If you have a domain name, set a [[Sender Policy Framework]] policy to combat email spoofing.<br />
<br />
=== Proxies ===<br />
<br />
Proxies are commonly used as an extra layer between applications and the network, sanitizing data from untrusted sources. The attack surface of a small proxy running with lower privileges is significantly smaller than a complex application running with the end user privileges.<br />
<br />
For example the DNS resolver is implemented in {{Pkg|glibc}}, that is linked with the application (that may be running as root), so a bug in the DNS resolver might lead to a remote code execution. This can be prevented by installing a DNS caching server, such as [[dnsmasq]], which acts as a proxy. [https://googleonlinesecurity.blogspot.it/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html]<br />
<br />
=== Managing SSL certificates ===<br />
<br />
{{Merge|Transport Layer Security|There's a dedicated article.}}<br />
<br />
See [[OpenSSL]] and [[Network Security Services]] (NSS) for managing custom server-side SSL certificates. Notably, the related [[Let’s Encrypt]] project is also supported. <br />
<br />
The default internet SSL certificate trustchains are provided by the {{Pkg|ca-certificates}} package and its dependencies. Note that Arch relies on trust-sources (e.g. {{Pkg|ca-certificates-mozilla}}) providing the certificates to be trusted per default by the system. <br />
<br />
There may be occasions when you want to deviate from the default. For example, you may read some [https://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/ news] and want to distrust a certificate rather than wait until the trust-source providers do. The Arch infrastructure makes such easy:<br />
<br />
# Obtain the respective certificate in .crt format (Example: [https://crt.sh/?id=19538258 view], [https://crt.sh/?d=19538258 download]; in case of an existing trusted root certificate authority, you may also find it extracted in the system path), <br />
# Copy it to {{ic|/etc/ca-certificates/trust-source/blacklist/}} and <br />
# Run ''update-ca-trust'' as root. <br />
<br />
To check the blacklisting works as intended, you may re-open your preferred browser and do so via its GUI, which should show it as '''untrusted''' now.<br />
<br />
== Authenticating packages ==<br />
<br />
[https://www2.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview Attacks on package managers] are possible without proper use of package signing, and can affect even package managers with [https://www2.cs.arizona.edu/stork/packagemanagersecurity/faq.html proper signature systems]. Arch uses package signing by default and relies on a web of trust from 5 trusted master keys. See [[Pacman-key]] for details.<br />
<br />
== Upgrades ==<br />
<br />
{{Style|Duplicates [[System maintenance#Upgrading the system]].}}<br />
<br />
It is important to regularly [[System_maintenance#Upgrading_the_system | upgrade the system ]].<br />
<br />
{{Warning|Do not be tempted to perform [[partial upgrades]], as they are not supported by Arch Linux and may cause instability: the whole system should be upgraded when upgrading a component. Also note that infrequent system updates can complicate the update process.}}<br />
<br />
=== Restart or Reboot after Upgrades ===<br />
<br />
Upgrades are typically not applied to existing processes. You must restart processes to fully apply the upgrade.<br />
<br />
The kernel is particularly difficult to patch without a reboot. A reboot is always the most secure option, but if this is very inconvenient [[kernel live patching]] can be used to apply upgrades without a reboot.<br />
<br />
=== Follow vulnerability alerts ===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure (CVE) Security Alert updates, made available by National Vulnerability Database, and found on the [https://nvd.nist.gov/download.cfm NVD Download webpage]. The [https://security.archlinux.org/ Arch Linux Security Tracker] serves as a particularly useful resource in that it combines Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG) and CVE data sets in tabular format. See also [[Arch Security Team]].<br />
<br />
You should also consider subscribing to the release notifications for software you use, especially if you install software through means other than the main repositories or AUR. Some software have mailing lists you can subscribe to for security notifications. Source code hosting sites often offer RSS feeds for new releases.<br />
<br />
== Physical security ==<br />
<br />
Physical access to a computer is root access given enough time and resources. However, a high ''practical'' level of security can be obtained by putting up enough barriers.<br />
<br />
An attacker can gain full control of your computer on the next boot by simply attaching a malicious IEEE 1394 (FireWire), Thunderbolt or PCI Express device as they are given full memory access.[https://www.breaknenter.org/projects/inception/] There is little you can do from preventing this, or modification of the hardware itself - such as flashing malicious firmware onto a drive. However, the vast majority of attackers will not be this knowledgeable and determined.<br />
<br />
[[#Disk encryption]] will prevent access to your data if the computer is stolen, but malicious firmware can be installed to obtain this data upon your next log in by a resourceful attacker.<br />
<br />
=== Locking down BIOS ===<br />
<br />
Adding a password to the BIOS prevents someone from booting into removable media, which is basically the same as having root access to your computer. You should make sure your drive is first in the boot order and disable the other drives from being bootable if you can.<br />
<br />
=== Boot loaders ===<br />
<br />
It is highly important to protect your [[boot loader]]. An unprotected boot loader can bypass any login restrictions, e.g. by setting the {{ic|1=init=/bin/sh}} [[kernel parameter]] to boot directly to a shell.<br />
<br />
==== Syslinux ====<br />
<br />
Syslinux supports [[Syslinux#Security|password-protecting your bootloader]]. It allows you to set either a per-menu-item password or a global bootloader password.<br />
<br />
==== GRUB ====<br />
<br />
[[GRUB]] supports bootloader passwords as well. See [[GRUB/Tips and tricks#Password protection of GRUB menu]] for details. It also has support for [[GRUB#Encrypted /boot|encrypted /boot]], which only leaves some parts of the bootloader code unencrypted. GRUB's configuration, [[kernel]] and [[initramfs]] are encrypted.<br />
<br />
=== Boot partition on removable flash drive ===<br />
<br />
One popular idea is to place the boot partition on a flash drive in order to render the system unbootable without it. Proponents of this idea often use [[#Disk encryption|full disk encryption]] alongside, and some also use [[Dm-crypt/Specialties#Encrypted_system_using_a_detached_LUKS_header|detached encryption headers]] placed on the boot partition. <br />
<br />
=== Automatic logout ===<br />
<br />
If you are using [[Bash]] or [[Zsh]], you can set {{ic|TMOUT}} for an automatic logout from shells after a timeout.<br />
<br />
For example, the following will automatically log out from virtual consoles (but not terminal emulators in X11):<br />
<br />
{{hc|/etc/profile.d/shell-timeout.sh|<nowiki><br />
TMOUT="$(( 60*10 ))";<br />
[ -z "$DISPLAY" ] && export TMOUT;<br />
case $( /usr/bin/tty ) in<br />
/dev/tty[0-9]*) export TMOUT;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you really want EVERY Bash/Zsh prompt (even within X) to timeout, use:<br />
<br />
$ export TMOUT="$(( 60*10 ))";<br />
<br />
Note that this will not work if there is some command running in the shell (eg.: an SSH session or other shell without {{ic|TMOUT}} support). But if you are using VC mostly for restarting frozen GDM/Xorg as root, then this is very useful.<br />
<br />
=== Protect against rogue USB devices ===<br />
<br />
Install [[USBGuard]], which is a software framework that helps to protect your computer against rogue USB devices (a.k.a. [https://srlabs.de/badusb BadUSB], [https://github.com/samyk/poisontap PoisonTap] or [https://lanturtle.com/ LanTurtle]) by implementing basic whitelisting and blacklisting capabilities based on device attributes.<br />
<br />
== Rebuilding packages ==<br />
<br />
Packages can be rebuilt and stripped of undesired functions and features as a means to reduce attack surface. For example, {{Pkg|bzip2}} can be rebuilt without {{ic|bzip2recover}} in an attempt to circumvent [https://security.archlinux.org/CVE-2016-3189 CVE-2016-3189]. Custom hardening flags can also be applied either manually or via a wrapper.<br />
<br />
== See also ==<br />
<br />
* [https://security.archlinux.org/ Arch Linux Security Tracker]<br />
* [https://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the Linux desktop]<br />
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the Linux server]<br />
* [https://github.com/lfit/itpol/blob/master/linux-workstation-security.md Linux Foundation: Linux workstation security checklist]<br />
* [https://www.privacytools.io/ privacytools.io Privacy Resources]<br />
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/ Red Hat Enterprise Linux 7 Security Guide]<br />
* [https://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.pdf Securing Debian Manual (PDF)]<br />
* [https://web.archive.org/web/20140220055801/http://crunchbang.org:80/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]</div>Geshhttps://wiki.archlinux.org/index.php?title=Node.js_package_guidelines&diff=576778Node.js package guidelines2019-07-03T15:06:04Z<p>Gesh: Add -r flag to xargs in case package doesn't pull in others</p>
<hr />
<div>[[Category:Arch package guidelines]]<br />
[[ja:Node.js パッケージガイドライン]]<br />
[[pt:Node.js package guidelines]]<br />
{{Package guidelines}}<br />
<br />
This document covers standards and guidelines on writing [[PKGBUILD]]s for [[Node.js]] packages.<br />
<br />
== Package naming ==<br />
<br />
Package names should start with a {{ic|nodejs-}} prefix.<br />
<br />
== Using npm ==<br />
<br />
When installing with {{Pkg|npm}}, add it as a build dependency:<br />
<br />
makedepends=('npm')<br />
<br />
This is a minimal {{ic|package}} function:<br />
<br />
{{bc|<nowiki><br />
package() {<br />
npm install -g --user root --prefix "$pkgdir"/usr "$srcdir"/source-tarball.tar.gz<br />
<br />
# Non-deterministic race in npm gives 777 permissions to random directories.<br />
# See https://github.com/npm/npm/issues/9359 for details.<br />
find "${pkgdir}"/usr -type d -exec chmod 755 {} +<br />
}<br />
</nowiki>}}<br />
<br />
=== Setting temporary cache ===<br />
<br />
When npm processes {{ic|package.json}} in order to build a package it downloads dependencies to its default cache folder at {{ic|$HOME/.npm}}. To avoid littering user's home folder we can temporarily set a different cache folder with {{ic|--cache}} flag:<br />
<br />
Download dependencies to {{ic|${srcdir}/npm-cache}} and install them in package directory<br />
<br />
npm install --cache "${srcdir}/npm-cache" <br />
<br />
Continue with packaging as usual<br />
<br />
npm run packager<br />
<br />
=== Package contains reference to $srcdir/$pkgdir ===<br />
<br />
npm unfortunately creates references to the source dir and the pkg dir. This is [https://github.com/npm/npm/issues/12110 a known issue in NPM], and actually considered a feature. However, you may remove those references manually since they are not used in any way.<br />
<br />
All dependencies will contain a reference to {{ic|$pkgdir}}, in the {{ic|_where}} attribute. You can usually remove those attributes with some ''sed'' magic as follows:<br />
<br />
find "$pkgdir" -name package.json -print0 | xargs -r -0 sed -i '/_where/d'<br />
<br />
Your main package will have some other references too. The easiest way to remove those is to remove all underscored properties, but that is not as easy with ''sed''. Instead, you can use {{Pkg|jq}} for similar results as follows:<br />
<br />
{{bc|<nowiki><br />
local tmppackage="$(mktemp)"<br />
local pkgjson="$pkgdir/usr/lib/node_modules/$pkgname/package.json"<br />
jq '.|=with_entries(select(.key|test("_.+")|not))' "$pkgjson" > "$tmppackage"<br />
mv "$tmppackage" "$pkgjson"<br />
chmod 644 "$pkgjson"<br />
</nowiki>}}<br />
<br />
An example of both techniques can be seen in {{AUR|bower-away}}.</div>Geshhttps://wiki.archlinux.org/index.php?title=NVIDIA&diff=529251NVIDIA2018-07-10T17:30:31Z<p>Gesh: Avoid running the hook if the linux package is being installed -- it will run an equivalent hook anyway</p>
<hr />
<div>[[Category:Graphics]]<br />
[[Category:X server]]<br />
[[cs:NVIDIA]]<br />
[[de:Nvidia]]<br />
[[es:NVIDIA]]<br />
[[fa:اِنویدیا]]<br />
[[fr:Nvidia]]<br />
[[it:NVIDIA]]<br />
[[ja:NVIDIA]]<br />
[[nl:NVIDIA]]<br />
[[ru:NVIDIA]]<br />
[[zh-hans:NVIDIA]]<br />
{{Related articles start}}<br />
{{Related|NVIDIA/Tips and tricks}}<br />
{{Related|NVIDIA/Troubleshooting}}<br />
{{Related|Nouveau}}<br />
{{Related|Bumblebee}}<br />
{{Related|NVIDIA Optimus}}<br />
{{Related|Xorg}}<br />
{{Related|Vulkan}}<br />
{{Related articles end}}<br />
<br />
This article covers the proprietary [http://www.nvidia.com NVIDIA] graphics card driver. For the open-source driver, see [[Nouveau]]. If you have a laptop with hybrid Intel/NVIDIA graphics, see [[NVIDIA Optimus]] instead.<br />
<br />
== Installation ==<br />
<br />
{{Warning|Avoid installing the NVIDIA driver through the package provided from the NVIDIA website. Installation through [[pacman]] allows upgrading the driver together with the rest of the system.}}<br />
<br />
These instructions are for those using the stock {{Pkg|linux}} or {{Pkg|linux-lts}} packages. For custom kernel setup, skip to the [[#Custom kernel|next]] subsection.<br />
<br />
1. If you do not know what graphics card you have, find out by issuing:<br />
:{{bc|<nowiki>$ lspci -k | grep -A 2 -E "(VGA|3D)"</nowiki>}}<br />
<br />
2. Determine the necessary driver version for your card by:<br />
:* finding the code name (e.g. NV50, NVC0, etc.) on [https://nouveau.freedesktop.org/wiki/CodeNames/ Nouveau wiki's code names page]<br />
:* looking up the name in NVIDIA's [http://www.nvidia.com/object/IO_32667.html legacy card list]: if your card is not there you can use the latest driver<br />
:* visiting NVIDIA's [http://www.nvidia.com/Download/index.aspx driver download site]<br />
<br />
3. Install the appropriate driver for your card:<br />
:* For GeForce 600 series cards and newer [NVEx and newer], [[install]] the {{Pkg|nvidia}} or {{Pkg|nvidia-lts}} package.<br />
::* If these packages do not work, {{AUR|nvidia-beta}} may have a newer driver version that offers support.<br />
::* There is also {{AUR|nvidia-llb-dkms}}, which is built from Nvidia's [http://www.phoronix.com/scan.php?page=news_item&px=OTkxOA long lived branch].<br />
:* For GeForce 400/500 series cards [NVCx and NVDx] from around 2010-2011, [[install]] the {{Pkg|nvidia-390xx}} or {{Pkg|nvidia-390xx-lts}} package.<br />
:* For GeForce 8/9, ION and 100-300 series cards [NV5x, NV8x, NV9x and NVAx] from around 2006-2010, [[install]] the {{Pkg|nvidia-340xx}} or {{Pkg|nvidia-340xx-lts}} package.<br />
<br />
:* For even older cards (released in 2006 or earlier), have a look at [[#Unsupported drivers]].<br />
<br />
4. For 32-bit application support, also install the equivalent ''lib32'' package from the [[multilib]] repository (e.g. {{Pkg|lib32-nvidia-utils}}, {{Pkg|lib32-nvidia-390xx-utils}} or {{Pkg|lib32-nvidia-340xx-utils}}).<br />
<br />
5. Reboot. The {{Pkg|nvidia}} package contains a file which blacklists the ''nouveau'' module, so rebooting is necessary.<br />
<br />
Once the driver has been installed, continue to [[#Configuration]].<br />
<br />
=== Unsupported drivers ===<br />
<br />
If you have a GeForce 7 series card or older (released in 2006 or earlier), Nvidia no longer supports drivers for your card. This means that these drivers [http://nvidia.custhelp.com/app/answers/detail/a_id/3142/ do not support the current Xorg version]. It thus might be easier if you use the [[Nouveau]] driver, which supports the old cards with the current Xorg.<br />
<br />
However, Nvidia's legacy drivers are still available and might provide better 3D performance/stability if you are willing to downgrade [[Xorg]]:<br />
<br />
* For GeForce 6/7 series cards [NV4x and NV6x], [[install]] the {{AUR|nvidia-304xx-dkms}}{{Broken package link|{{aur-mirror|nvidia-304xx-dkms}}}} package. Last supported Xorg version is 1.19.<br />
* For GeForce 5 FX series cards [NV30-NV36], install the {{AUR|nvidia-173xx-dkms}} package. Last supported Xorg version is 1.15.<br />
* For GeForce 2/3/4 MX/Ti series cards [NV11, NV17-NV28], install the {{AUR|nvidia-96xx-dkms}} package. Last supported Xorg version is 1.12.<br />
<br />
=== Custom kernel ===<br />
<br />
If you are using a custom kernel, compilation of the Nvidia kernel modules can be automated with [[DKMS]].<br />
<br />
Install the {{Pkg|nvidia-dkms}} package (or a specific branch such as {{Pkg|nvidia-390xx-dkms}} or {{Pkg|nvidia-340xx-dkms}}). The Nvidia module will be rebuilt after every Nvidia or kernel update thanks to the DKMS [[pacman hook]].<br />
<br />
=== DRM kernel mode setting ===<br />
<br />
{{Pkg|nvidia}} 364.16 adds support for DRM (Direct Rendering Manager) [[kernel mode setting]]. To enable this feature, add the {{ic|1=nvidia-drm.modeset=1}} [[kernel parameter]], and add {{ic|nvidia}}, {{ic|nvidia_modeset}}, {{ic|nvidia_uvm}} and {{ic|nvidia_drm}} to [[initramfs#MODULES]].<br />
<br />
Do not forget to run [[mkinitcpio]] every time there is a {{Pkg|nvidia}} driver update. See [[#Pacman hook]] to automate these steps.<br />
<br />
{{Warning|Enabling [[KMS]] causes [[GDM]] and [[GNOME]] to default to [[Wayland]], which currently suffers from very poor performance: {{bug|53284}}. A workaround is to configure GDM to use Xorg (see [[GDM#Use Xorg backend]]) or to use the ''GNOME on Xorg'' session instead.}}<br />
<br />
{{Note|1=The NVIDIA driver does '''not''' provide an {{ic|fbdev}} driver for the high-resolution console for the kernel compiled-in {{ic|vesafb}} module. However, the kernel compiled-in {{ic|efifb}} module supports a high-resolution console on EFI systems. This method requires GRUB and is described in [[NVIDIA/Tips and tricks#Fixing terminal resolution]].[http://forums.fedoraforum.org/showthread.php?t=306271][https://www.reddit.com/r/archlinux/comments/4gwukx/nvidia_drivers_and_high_resolution_tty_possible/].}}<br />
<br />
==== Pacman hook ====<br />
<br />
To avoid the possibility of forgetting to update [[initramfs]] after an NVIDIA driver upgrade, you may want to use a [[pacman hook]]:<br />
<br />
{{hc|/etc/pacman.d/hooks/nvidia.hook|2=[Trigger]<br />
[Trigger]<br />
Operation=Install<br />
Operation=Upgrade<br />
Operation=Remove<br />
Type=Package<br />
Target=nvidia<br />
Target=linux<br />
# Change the linux part above and in the Exec line if a different kernel is used<br />
<br />
[Action]<br />
Description=Update Nvidia module in initcpio<br />
Depends=mkinitcpio<br />
When=PostTransaction<br />
NeedsTargets<br />
Exec=/bin/sh -c 'while read -r trg; do case $trg in linux) exit 0; esac; done; /usr/bin/mkinitcpio -P'}}<br />
<br />
Make sure the {{ic|Target}} package set in this hook is the one you've installed in steps above (e.g. {{ic|nvidia}}, {{ic|nvidia-dkms}}, {{ic|nvidia-lts}} or {{ic|nvidia-ck-something}}).<br />
<br />
{{Note|The complication in the {{ic|Exec}} line above is in order to avoid running {{ic|mkinitcpio}} multiple times if both {{ic|nvidia}} and {{ic|linux}} get updated. In case this doesn't bother you, the {{ic|1=Target=linux}} and {{ic|NeedsTargets}} lines may be dropped, and the {{ic|Exec}} line may be reduced to simply {{ic|1=Exec=/usr/bin/mkinitcpio -P}}.}}<br />
<br />
=== Hardware accelerated video decoding ===<br />
<br />
==== VDPAU ====<br />
<br />
At least a video card with second generation [[wikipedia:Nvidia PureVideo#Table of GPUs containing a PureVideo SIP block|PureVideo HD]] is required for [[hardware video acceleration]] using VDPAU.<br />
<br />
==== XvMC ====<br />
<br />
Accelerated decoding of MPEG-1 and MPEG-2 videos via [[XvMC]] are supported on GeForce4, GeForce 5 FX, GeForce 6 and GeForce 7 series cards. See [[XvMC]] for details.<br />
<br />
== Configuration ==<br />
<br />
The proprietary NVIDIA graphics card driver does not need any Xorg server configuration file. You can run [[Xorg#Running|a test]] to see if the Xorg server will function correctly without a configuration file. However, it may be required to create a configuration file (prefer {{ic|/etc/X11/xorg.conf.d/20-nvidia.conf}} over {{ic|/etc/X11/xorg.conf}}) in order to adjust various settings. This configuration can be generated by the NVIDIA Xorg configuration tool, or it can be created manually. If created manually, it can be a minimal configuration (in the sense that it will only pass the basic options to the [[Xorg]] server), or it can include a number of settings that can bypass Xorg's auto-discovered or pre-configured options.<br />
<br />
{{Tip|For more configuration options see [[NVIDIA/Tips and tricks#Manual configuration]] and [[NVIDIA/Troubleshooting]] section.}}<br />
<br />
=== Minimal configuration ===<br />
<br />
A basic configuration block in {{ic|20-nvidia.conf}} (or deprecated in {{ic|xorg.conf}}) would look like this:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-nvidia.conf|<br />
Section "Device"<br />
Identifier "Nvidia Card"<br />
Driver "nvidia"<br />
VendorName "NVIDIA Corporation"<br />
BoardName "GeForce GTX 1050 Ti"<br />
EndSection<br />
}}<br />
<br />
=== Automatic configuration ===<br />
<br />
The NVIDIA package includes an automatic configuration tool to create an Xorg server configuration file ({{ic|xorg.conf}}) and can be run by:<br />
# nvidia-xconfig<br />
<br />
This command will auto-detect and create (or edit, if already present) the {{ic|/etc/X11/xorg.conf}} configuration according to present hardware.<br />
<br />
If there are instances of DRI, ensure they are commented out:<br />
# Load "dri"<br />
Double check your {{ic|/etc/X11/xorg.conf}} to make sure your default depth, horizontal sync, vertical refresh, and resolutions are acceptable.<br />
<br />
=== NVIDIA Settings ===<br />
<br />
The {{Pkg|nvidia-settings}} tool lets you configure many options using either CLI or GUI. Running {{ic|nvidia-settings}} without any options launches the GUI, for CLI options see {{man|1|nvidia-settings}}.<br />
<br />
You can run the CLI/GUI as a non-root user and save the settings to {{ic|~/.nvidia-settings-rc}} or save it as [[Xorg#Using_xorg.conf|xorg.conf]] by using the option ''Save to X configuration File'' for a multi-user environment.<br />
<br />
To load the {{ic|~/.nvidia-settings-rc}} for the current user:<br />
<br />
$ nvidia-settings --load-config-only<br />
<br />
See [[Autostarting]] to start this command on every boot.<br />
<br />
{{Note|[[Xorg]] may not start or crash on startup after saving {{ic|nvidia-settings}} changes. Adjusting or deleting the generated {{ic|~/.nvidia-settings-rc}} and/or [[Xorg]] file(s) should recover normal startup.}}<br />
<br />
=== Multiple monitors ===<br />
<br />
See [[Multihead]] for more general information.<br />
<br />
==== Using NVIDIA Settings ====<br />
<br />
The [[#NVIDIA Settings|nvidia-settings]] tool can configure multiple monitors.<br />
<br />
For CLI configuration, first get the {{ic|CurrentMetaMode}} by running:<br />
<br />
{{hc|$ nvidia-settings -q CurrentMetaMode|2=<br />
Attribute 'CurrentMetaMode' (hostnmae:0.0): id=50, switchable=no, source=nv-control :: DPY-1: 2880x1620 @2880x1620 +0+0 {ViewPortIn=2880x1620, ViewPortOut=2880x1620+0+0}<br />
}}<br />
<br />
Save everything after the {{ic|::}} to the end of the attribute (in this case: {{ic|1=DPY-1: 2880x1620 @2880x1620 +0+0 {ViewPortIn=2880x1620, ViewPortOut=2880x1620+0+0&#125;}}) and use to reconfigure your displays with {{ic|1=nvidia-settings --assign "CurrentMetaMode=''your_meta_mode''"}}.<br />
<br />
{{Tip|You can create shell aliases for the different monitor and resolution configurations you use.}}<br />
<br />
==== ConnectedMonitor ====<br />
<br />
If the driver does not properly detect a second monitor, you can force it to do so with ConnectedMonitor. <br />
<br />
{{hc|/etc/X11/xorg.conf|<br />
<br />
Section "Monitor"<br />
Identifier "Monitor1"<br />
VendorName "Panasonic"<br />
ModelName "Panasonic MICRON 2100Ex"<br />
HorizSync 30.0 - 121.0 # this monitor has incorrect EDID, hence Option "UseEDIDFreqs" "false"<br />
VertRefresh 50.0 - 160.0<br />
Option "DPMS"<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "Monitor2"<br />
VendorName "Gateway"<br />
ModelName "GatewayVX1120"<br />
HorizSync 30.0 - 121.0<br />
VertRefresh 50.0 - 160.0<br />
Option "DPMS"<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "Device1"<br />
Driver "nvidia"<br />
Option "NoLogo"<br />
Option "UseEDIDFreqs" "false"<br />
Option "ConnectedMonitor" "CRT,CRT"<br />
VendorName "NVIDIA Corporation"<br />
BoardName "GeForce 6200 LE"<br />
BusID "PCI:3:0:0"<br />
Screen 0<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "Device2"<br />
Driver "nvidia"<br />
Option "NoLogo"<br />
Option "UseEDIDFreqs" "false"<br />
Option "ConnectedMonitor" "CRT,CRT"<br />
VendorName "NVIDIA Corporation"<br />
BoardName "GeForce 6200 LE"<br />
BusID "PCI:3:0:0"<br />
Screen 1<br />
EndSection<br />
<br />
}}<br />
<br />
The duplicated device with {{ic|Screen}} is how you get X to use two monitors on one card without {{ic|TwinView}}. Note that {{ic|nvidia-settings}} will strip out any {{ic|ConnectedMonitor}} options you have added.<br />
<br />
==== TwinView ====<br />
<br />
You want only one big screen instead of two. Set the {{ic|TwinView}} argument to {{ic|1}}. This option should be used if you desire compositing. TwinView only works on a per card basis, when all participating monitors are connected to the same card.<br />
Option "TwinView" "1"<br />
<br />
Example configuration:<br />
{{hc|/etc/X11/xorg.conf.d/10-monitor.conf|<br />
Section "ServerLayout"<br />
Identifier "TwinLayout"<br />
Screen 0 "metaScreen" 0 0<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "Monitor0"<br />
Option "Enable" "true"<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "Monitor1"<br />
Option "Enable" "true"<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "Card0"<br />
Driver "nvidia"<br />
VendorName "NVIDIA Corporation"<br />
<br />
#refer to the link below for more information on each of the following options.<br />
Option "HorizSync" "DFP-0: 28-33; DFP-1 28-33"<br />
Option "VertRefresh" "DFP-0: 43-73; DFP-1 43-73"<br />
Option "MetaModes" "1920x1080, 1920x1080"<br />
Option "ConnectedMonitor" "DFP-0, DFP-1"<br />
Option "MetaModeOrientation" "DFP-1 LeftOf DFP-0"<br />
EndSection<br />
<br />
Section "Screen"<br />
Identifier "metaScreen"<br />
Device "Card0"<br />
Monitor "Monitor0"<br />
DefaultDepth 24<br />
Option "TwinView" "True"<br />
SubSection "Display"<br />
Modes "1920x1080"<br />
EndSubSection<br />
EndSection<br />
}}<br />
<br />
[ftp://download.nvidia.com/XFree86/Linux-x86/355.11/README/configtwinview.html Device option information].<br />
<br />
If you have multiple cards that are SLI capable, it is possible to run more than one monitor attached to separate cards (for example: two cards in SLI with one monitor attached to each). The "MetaModes" option in conjunction with SLI Mosaic mode enables this. Below is a configuration which works for the aforementioned example and runs [[GNOME]] flawlessly.<br />
{{hc|/etc/X11/xorg.conf.d/10-monitor.conf|<br />
Section "Device"<br />
Identifier "Card A"<br />
Driver "nvidia"<br />
BusID "PCI:1:00:0"<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "Card B"<br />
Driver "nvidia"<br />
BusID "PCI:2:00:0"<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "Right Monitor"<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "Left Monitor"<br />
EndSection<br />
<br />
Section "Screen"<br />
Identifier "Right Screen"<br />
Device "Card A"<br />
Monitor "Right Monitor"<br />
DefaultDepth 24<br />
Option "SLI" "Mosaic"<br />
Option "Stereo" "0"<br />
Option "BaseMosaic" "True"<br />
Option "MetaModes" "GPU-0.DFP-0: 1920x1200+4480+0, GPU-1.DFP-0:1920x1200+0+0"<br />
SubSection "Display"<br />
Depth 24<br />
EndSubSection<br />
EndSection<br />
<br />
Section "Screen"<br />
Identifier "Left Screen"<br />
Device "Card B"<br />
Monitor "Left Monitor"<br />
DefaultDepth 24<br />
Option "SLI" "Mosaic"<br />
Option "Stereo" "0"<br />
Option "BaseMosaic" "True"<br />
Option "MetaModes" "GPU-0.DFP-0: 1920x1200+4480+0, GPU-1.DFP-0:1920x1200+0+0"<br />
SubSection "Display"<br />
Depth 24<br />
EndSubSection<br />
EndSection<br />
<br />
Section "ServerLayout"<br />
Identifier "Default"<br />
Screen 0 "Right Screen" 0 0<br />
Option "Xinerama" "0"<br />
EndSection}}<br />
<br />
===== Manual CLI configuration with xrandr =====<br />
{{Accuracy|Do these commands set up the monitors in ''TwinView'' mode?}}<br />
<br />
If the latest solutions do not work for you, you can use your window manager's ''autostart'' implementation with {{Pkg|xorg-xrandr}}.<br />
<br />
Some {{ic|xrandr}} examples could be:<br />
<br />
xrandr --output DVI-I-0 --auto --primary --left-of DVI-I-1<br />
<br />
or:<br />
<br />
xrandr --output DVI-I-1 --pos 1440x0 --mode 1440x900 --rate 75.0<br />
<br />
When:<br />
<br />
* {{ic|--output}} is used to indicate the "monitor" to which the options are set.<br />
* {{ic|DVI-I-1}} is the name of the second monitor.<br />
* {{ic|--pos}} is the position of the second monitor relative to the first.<br />
* {{ic|--mode}} is the resolution of the second monitor.<br />
* {{ic|--rate}} is the refresh rate (in Hz).<br />
<br />
===== Vertical sync using TwinView =====<br />
<br />
If you are using TwinView and vertical sync (the "Sync to VBlank" option in '''nvidia-settings'''), you will notice that only one screen is being properly synced, unless you have two identical monitors. Although '''nvidia-settings''' does offer an option to change which screen is being synced (the "Sync to this display device" option), this does not always work. A solution is to add the following environment variables at startup, for example append in {{ic|/etc/profile}}:<br />
<br />
export __GL_SYNC_TO_VBLANK=1<br />
export __GL_SYNC_DISPLAY_DEVICE=DFP-0<br />
export VDPAU_NVIDIA_SYNC_DISPLAY_DEVICE=DFP-0<br />
<br />
You can change {{ic|DFP-0}} with your preferred screen ({{ic|DFP-0}} is the DVI port and {{ic|CRT-0}} is the VGA port). You can find the identifier for your display from '''nvidia-settings''' in the "X Server XVideoSettings" section.<br />
<br />
===== Gaming using TwinView =====<br />
<br />
In case you want to play fullscreen games when using TwinView, you will notice that games recognize the two screens as being one big screen. While this is technically correct (the virtual X screen really is the size of your screens combined), you probably do not want to play on both screens at the same time. <br />
<br />
To correct this behavior for SDL, try:<br />
export SDL_VIDEO_FULLSCREEN_HEAD=1<br />
<br />
For OpenGL, add the appropriate Metamodes to your xorg.conf in section {{ic|Device}} and restart X:<br />
Option "Metamodes" "1680x1050,1680x1050; 1280x1024,1280x1024; 1680x1050,NULL; 1280x1024,NULL;"<br />
<br />
Another method that may either work alone or in conjunction with those mentioned above is [[Gaming#Starting_games_in_a_separate_X_server|starting games in a separate X server]].<br />
<br />
==== Mosaic mode ====<br />
<br />
Mosaic mode is the only way to use more than 2 monitors across multiple graphics cards with compositing. Your window manager may or may not recognize the distinction between each monitor.<br />
<br />
===== Base Mosaic =====<br />
<br />
Base Mosaic mode works on any set of Geforce 8000 series or higher GPUs. It cannot be enabled from within the nvidia-setting GUI. You must either use the {{ic|nvidia-xconfig}} command line program or edit {{ic|xorg.conf}} by hand. Metamodes must be specified. The following is an example for four DFPs in a 2x2 configuration, each running at 1920x1024, with two DFPs connected to two cards:<br />
$ nvidia-xconfig --base-mosaic --metamodes="GPU-0.DFP-0: 1920x1024+0+0, GPU-0.DFP-1: 1920x1024+1920+0, GPU-1.DFP-0: 1920x1024+0+1024, GPU-1.DFP-1: 1920x1024+1920+1024"<br />
<br />
{{Note|While the documentation lists a 2x2 configuration of monitors, [https://devtalk.nvidia.com/default/topic/579449/linux/basemosaic-v295-vs-v310-vs-v325-only-up-to-three-screens-/post/3954733/#3954733 GeForce cards are artificially limited to 3 monitors] in Base Mosaic mode. Quadro cards support more than 3 monitors. As of September 2014, the Windows driver has dropped this artificial restriction, but it remains in the Linux driver.}}<br />
<br />
===== SLI Mosaic =====<br />
<br />
If you have an SLI configuration and each GPU is a Quadro FX 5800, Quadro Fermi or newer then you can use SLI Mosaic mode. It can be enabled from within the nvidia-settings GUI or from the command line with:<br />
$ nvidia-xconfig --sli=Mosaic --metamodes="GPU-0.DFP-0: 1920x1024+0+0, GPU-0.DFP-1: 1920x1024+1920+0, GPU-1.DFP-0: 1920x1024+0+1024, GPU-1.DFP-1: 1920x1024+1920+1024"<br />
<br />
=== Driver persistence ===<br />
<br />
Nvidia has a daemon that is to be run at boot. See the [http://docs.nvidia.com/deploy/driver-persistence/index.html#persistence-daemon Driver Persistence] section of the Nvidia documentation for more details.<br />
<br />
To start the persistence daemon at boot, [[enable]] the {{ic|nvidia-persistenced.service}}. For manual usage see the [http://docs.nvidia.com/deploy/driver-persistence/index.html#usage upstream documentation].<br />
<br />
== See also ==<br />
<br />
* [https://forums.geforce.com/ NVIDIA User forums]<br />
* [http://download.nvidia.com/XFree86/Linux-x86/387.22/README/README.txt Official README for NVIDIA drivers, all on one text page. Version 387.22 (2017-10-25)]<br />
* [http://download.nvidia.com/XFree86/Linux-x86/387.22/README/xconfigoptions.html README Appendix B. X Config Options, 387.22 (direct link)]</div>Geshhttps://wiki.archlinux.org/index.php?title=Lighttpd&diff=296295Lighttpd2014-02-05T18:15:49Z<p>Gesh: Confirmed commented question re: server name in fastcgi</p>
<hr />
<div>[[cs:Lighttpd]]<br />
[[de:Lighttpd]]<br />
[[es:Lighttpd]]<br />
[[ru:Lighttpd]]<br />
[[zh-CN:Lighttpd]]<br />
[[zh-TW:Lighttpd]]<br />
[[Category:Web Server]]<br />
[http://www.lighttpd.net/ Lighttpd] is "a secure, fast, compliant, and very flexible [[Wikipedia:Web server|web-server]] that has been optimized for high-performance environments. It has a very low memory footprint compared to other webservers and takes care of cpu-load. Its advanced feature-set ([[Wikipedia:FastCGI|FastCGI]], [[Wikipedia:Common Gateway Interface|CGI]], Auth, Output-Compression, URL-Rewriting and many more) make lighttpd the perfect webserver-software for every server that suffers load problems."<br />
<br />
==Installation==<br />
Install the {{pkg|lighttpd}} package from the official repositories.<br />
<br />
==Configuration==<br />
===Basic Setup===<br />
The lighttpd configuration file is: {{ic|/etc/lighttpd/lighttpd.conf}}. By default it should produce a working test page. <br />
<br />
To check your {{ic|lighttpd.conf}} for bugs you can use this command - helps finding misconfigurations very fast:<br />
<br />
$ lighttpd -t -f /etc/lighttpd/lighttpd.conf<br />
<br />
The default configuration file specifies {{ic|/srv/http/}} as the document directory served.<br />
<br />
To test the install:<br />
# echo 'TestMe!' >> /srv/http/index.html<br />
# chmod 755 /srv/http/index.html<br />
<br />
To start the server:<br />
# systemctl start lighttpd<br />
<br />
Then point your browser to {{ic|localhost}}, and you should see the test page.<br />
<br />
To start the server on every boot:<br />
<br />
# systemctl enable lighttpd<br />
<br />
Example configuration files are available in {{ic|/usr/share/doc/lighttpd/}}.<br />
<br />
===CGI===<br />
<br />
CGI scripts work with Lighttpd out of box, you just need to enable the CGI module, include the configuration file and make sure your chosen programing language interpreter is installed. (ie for python you would install {{pkg|python}})<br />
<br />
Create the file {{ic|/etc/lighttpd/conf.d/cgi.conf}} Add the following to it:<br />
<br />
server.modules += ( "mod_cgi" )<br />
<br />
cgi.assign = ( ".pl" => "/usr/bin/perl",<br />
".cgi" => "/usr/bin/perl",<br />
".rb" => "/usr/bin/ruby",<br />
".erb" => "/usr/bin/eruby",<br />
".py" => "/usr/bin/python",<br />
".php" => "/usr/bin/php" )<br />
<br />
index-file.names += ( "index.pl", "default.pl",<br />
"index.rb", "default.rb",<br />
"index.erb", "default.erb",<br />
"index.py", "default.py",<br />
"index.php", "default.php" )<br />
<br />
For PHP scripts you will need to make sure the following is set in {{ic|/etc/php/php.ini}}<br />
cgi.fix_pathinfo = 1<br />
<br />
In your Lighttpd configuration file, {{ic|/etc/lighttpd/lighttpd.conf}} add:<br />
include "conf.d/cgi.conf"<br />
<br />
===FastCGI===<br />
<br />
Install {{pkg|fcgi}}.<br />
Now you have lighttpd with fcgi support. If it was that what you wanted you are all set. People that want Ruby on Rails, PHP or Python should continue.<br />
{{Note| New default user and group: Instead of group "nobody" lighttpd now runs as user/group "http" by default.}}<br />
<br />
First copy the example config file form {{ic|/usr/share/doc/lighttpd/config/conf.d/fastcgi.conf}} to {{ic|/etc/lighttpd/conf.d}}<br />
<br />
The following needs adding to the config file, {{ic|/etc/lighttpd/conf.d/fastcgi.conf}}<br />
server.modules += ( "mod_fastcgi" )<br />
<br />
#server.indexfiles += ( "dispatch.fcgi" ) #this is deprecated<br />
index-file.names += ( "dispatch.fcgi" ) #dispatch.fcgi if rails specified<br />
<br />
server.error-handler-404 = "/dispatch.fcgi" #too<br />
fastcgi.server = (<br />
".fcgi" => (<br />
"localhost" => ( <br />
"socket" => "/run/lighttpd/rails-fastcgi.sock",<br />
"bin-path" => "/path/to/rails/application/public/dispatch.fcgi"<br />
)<br />
)<br />
)<br />
<br />
Then in {{ic|/etc/lighttpd/lighttpd.conf}}:<br />
include "conf.d/fastcgi.conf"<br />
<br />
For PHP or Ruby on Rails see the next sections.<br />
<br />
====PHP====<br />
<br />
Install {{pkg|php}} and {{pkg|php-cgi}} (see also [[PHP]] and [[LAMP]]).<br />
<br />
Check that php-cgi is working {{Ic|php-cgi --version}}<br />
<br />
PHP 5.4.3 (cgi-fcgi) (built: May 8 2012 17:10:17)<br />
Copyright (c) 1997-2012 The PHP Group<br />
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies<br />
<br />
If you get a similar output then php is installed correctly.<br />
<br />
Create a new configuration file:<br />
<br />
{{hc|/etc/lighttpd/conf.d/fastcgi.conf|<nowiki><br />
# Make sure to install php and php-cgi. See: <br />
# https://wiki.archlinux.org/index.php/Fastcgi_and_lighttpd#PHP<br />
<br />
server.modules += ("mod_fastcgi")<br />
<br />
# FCGI server<br />
# ===========<br />
#<br />
# Configure a FastCGI server which handles PHP requests.<br />
#<br />
index-file.names += ("index.php")<br />
fastcgi.server = ( <br />
# Load-balance requests for this path...<br />
".php" => (<br />
# ... among the following FastCGI servers. The string naming each<br />
# server is just a label used in the logs to identify the server.<br />
"localhost" => ( <br />
"bin-path" => "/usr/bin/php-cgi",<br />
"socket" => "/tmp/php-fastcgi.sock",<br />
# breaks SCRIPT_FILENAME in a way that PHP can extract PATH_INFO<br />
# from it <br />
"broken-scriptfilename" => "enable",<br />
# Launch (max-procs + (max-procs * PHP_FCGI_CHILDREN)) procs, where<br />
# max-procs are "watchers" and the rest are "workers". See:<br />
# https://redmine.lighttpd.net/projects/1/wiki/frequentlyaskedquestions#How-many-php-CGI-processes-will-lighttpd-spawn <br />
"max-procs" => 4, # default value<br />
"bin-environment" => (<br />
"PHP_FCGI_CHILDREN" => "1" # default value<br />
)<br />
)<br />
) <br />
)<br />
</nowiki>}}<br />
<br />
Make lighttpd use the new configuration file:<br />
<br />
{{hc|/etc/lighttpd/lighttpd.conf|<br />
include "conf.d/fastcgi.conf"<br />
}}<br />
<br />
Reload lighttpd:<br />
<br />
# systemctl reload lighttpd<br />
<br />
{{Note|If you receive errors like ''No input file found'' when attempting to access php files, there are several possible explanations. See [http://redmine.lighttpd.net/projects/1/wiki/frequentlyaskedquestions#I-get-the-error-No-input-file-specified-when-trying-to-use-PHP this FAQ] for more information.}}<br />
<br />
===== Using php-fpm =====<br />
<br />
There is no adaptive spawning anymore in recent lighttpd releases. For dynamic management of PHP processes, you can use {{Pkg|php-fpm}}.<br />
# pacman -S php-fpm<br />
# systemctl enable php-fpm<br />
# systemctl start php-fpm<br />
{{Note|You can configure the number of servers in the pool and tweak other configuration options by editing the file {{ic|/etc/php/php-fpm.conf}}. More details on ''php-fpm'' can be found on the [http://php-fpm.org/ php-fpm website]. You should also note that when you make changes to /etc/php/php.ini you will need to restart php-fpm}}<br />
<br />
In {{ic|/etc/lighttpd/conf.d/fastcgi.conf}} add:<br />
server.modules += ( "mod_fastcgi" )<br />
<br />
index-file.names += ( "index.php" ) <br />
<br />
fastcgi.server = (<br />
".php" => (<br />
"localhost" => ( <br />
"socket" => "/run/php-fpm/php-fpm.sock",<br />
"broken-scriptfilename" => "enable"<br />
))<br />
)<br />
<br />
===== eAccelerator =====<br />
<br />
Install {{AUR|eaccelerator}} from the [[Arch User Repository|AUR]].<br />
<br />
Add own config file for eaccelerator:<br />
<br />
{{hc|/etc/php/conf.d/eaccelerator-own.ini|2=<br />
zlib.output_compression = On<br />
cgi.fix_pathinfo=1<br />
eaccelerator.cache_dir="/home/phpuser/eaccelerator/cache"<br />
}}<br />
<br />
{{Tip|I additionally set {{ic|safe_mod}} to {{ic|On}} in my setup, but this is not required.}}<br />
<br />
===== Try a php page =====<br />
Create the following php page, name it index.php, and place a copy in both /srv/http/ and /srv/http-ssl/html/<br />
<?php<br />
phpinfo();<br />
?><br />
Try navigating with a web browser to both the http and https address of your server. You should see the phpinfo page.<br />
<br />
Check eaccelerator caching:<br />
# ls -l /home/phpuser/eaccelerator/cache<br />
<br />
If the above command outputs the following:<br />
-rw------- 1 phpuser phpuser 456 2005-05-05 14:53 eaccelerator-277.58081<br />
-rw------- 1 phpuser phpuser 452 2005-05-05 14:53 eaccelerator-277.88081<br />
Then eaccelerator is happily caching your php scripts to help speed things up.<br />
<br />
====Ruby on Rails====<br />
Install and configure FastCGI (see [[#FastCGI]] above).<br />
<br />
Install [[ruby]] from [extra] and {{AUR|ruby-fcgi}} from [[AUR]].<br />
<br />
Follow instructions on [[RubyOnRails]].<br />
<br />
==== Python FastCGI ====<br />
Install and configure FastCGI (see [[#FastCGI]] above).<br />
<br />
Install flup:<br />
# pacman -S python2-flup<br />
Configure:<br />
fastcgi.server = (<br />
".py" =><br />
(<br />
"python-fcgi" =><br />
(<br />
"socket" => "/run/lighttpd/fastcgi.python.socket",<br />
"bin-path" => "test.py",<br />
"check-local" => "disable",<br />
"max-procs" => 1,<br />
)<br />
)<br />
)<br />
Put the test.py in the root of your server (don't forget to chmod +x it)<br />
<br />
{{bc|1=<br />
#!/usr/bin/env python2<br />
<br />
def myapp(environ, start_response):<br />
print 'got request: %s' % environ<br />
start_response('200 OK', [('Content-Type', 'text/plain')])<br />
return ['Hello World!']<br />
<br />
if __name__ == '__main__':<br />
from flup.server.fcgi import WSGIServer<br />
WSGIServer(myapp).run()<br />
}}<br />
<br />
[https://bbs.archlinux.org/viewtopic.php?pid=734173#p734173 Thanks to firecat53 for his explanation]<br />
<br />
=== SSL ===<br />
Generate an SSL Cert, e.g. like that: <br />
# mkdir /etc/lighttpd/certs<br />
# openssl req -x509 -nodes -days 7300 -newkey rsa:2048 -keyout /etc/lighttpd/certs/www.example.com.pem -out /etc/lighttpd/certs/www.example.com.pem<br />
# chmod 600 /etc/lighttpd/certs/www.example.com.pem<br />
<br />
Edit {{ic|/etc/lighttpd/lighttpd.conf}}.<br />
To make lighttpd SSL-only (you probably need to set the server port to 443 as well)<br />
ssl.engine = "enable" <br />
ssl.pemfile = "/etc/lighttpd/certs/www.example.com.pem"<br />
To enable SSL in addition to normal HTTP<br />
$SERVER["socket"] == ":443" {<br />
ssl.engine = "enable" <br />
ssl.pemfile = "/etc/lighttpd/certs/www.example.com.pem" <br />
}<br />
If you want to serve different sites, you can change the document root inside the socket conditional:<br />
$SERVER["socket"] == ":443" {<br />
server.document-root = "/srv/ssl" # use your ssl directory here<br />
ssl.engine = "enable"<br />
ssl.pemfile = "/etc/lighttpd/certs/www.example.com.pem" # use the path where you created your pem file<br />
}<br />
or as alternative you can use the scheme conditional to distinguish between secure and normal requests. <br />
$HTTP["scheme"] == "https" {<br />
server.document-root = "/srv/ssl" # use your ssl directory here<br />
ssl.engine = "enable"<br />
ssl.pemfile = "/etc/lighttpd/certs/www.example.com.pem" # use the path where you created your pem file<br />
}<br />
Note that you cannot use the scheme conditional around ssl.engine above, since lighttpd needs to know on what port to enable SSL.<br />
<br />
===== Server Name Indication =====<br />
<br />
To use [http://en.wikipedia.org/wiki/Server_Name_Indication SNI] with lighttpd, simply put additional ssl.pemfile configuration directives inside host conditionals. A default ssl.pemfile is [https://redmine.lighttpd.net/projects/1/wiki/Docs_SSL#Server-Name-Indication-SNI still required].<br />
<br />
$HTTP["host"] == "www.example.org" {<br />
ssl.pemfile = "/etc/lighttpd/certs/www.example.org.pem" <br />
}<br />
<br />
$HTTP["host"] == "mail.example.org" {<br />
ssl.pemfile = "/etc/lighttpd/certs/mail.example.org.pem" <br />
}<br />
<br />
==== Redirect HTTP requests to HTTPS ====<br />
You should add "mod_redirect" in server.modules array in {{ic|/etc/lighttpd/lighttpd.conf}}:<br />
server.modules += ( "mod_redirect" )<br />
<br />
$SERVER["socket"] == ":80" {<br />
$HTTP["host"] =~ "example.org" {<br />
url.redirect = ( "^/(.*)" => "https://example.org/$1" )<br />
server.name = "example.org" <br />
}<br />
}<br />
<br />
$SERVER["socket"] == ":443" {<br />
ssl.engine = "enable" <br />
ssl.pemfile = "/etc/lighttpd/ssl/server.pem" <br />
server.document-root = "..." <br />
}<br />
<br />
To redirect all hosts to their secure equivalents use the following in place of the socket 80 configuration above:<br />
$SERVER["socket"] == ":80" {<br />
$HTTP["host"] =~ "(.*)" {<br />
url.redirect = ( "^/(.*)" => "https://%1/$1" )<br />
}<br />
}<br />
<br />
To redirect all hosts for part of the site (e.g. secure or phpmyadmin):<br />
$SERVER["socket"] == ":80" {<br />
$HTTP["url"] =~ "^/secure" {<br />
url.redirect = ( "^/(.*)" => "https://example.com/$1" )<br />
}<br />
}<br />
<br />
=== Output Compression ===<br />
<br />
In {{ic|/etc/lighttpd/lighttpd.conf}} add<br />
var.cache_dir = "/var/cache/lighttpd"<br />
Then create directory for a compressed files:<br />
# mkdir /var/cache/lighttpd/compress<br />
# chown http:http /var/cache/lighttpd/compress<br />
Copy example configuration file:<br />
# mkdir /etc/lighttpd/conf.d<br />
# cp /usr/share/doc/lighttpd/config/conf.d/compress.conf /etc/lighttpd/conf.d/<br />
Add following in {{ic|/etc/lighttpd/lighttpd.conf}}:<br />
include "conf.d/compress.conf"<br />
{{Note| You can not do this (copy compress.conf) and add a needed content in {{ic|/etc/lighttpd/lighttpd.conf}} instead.}}<br />
<br />
==Troubleshooting==<br />
=== Lighttpd downloads .php files ===<br />
If lighttpd downloads {{ic|.php}} files instead of "initializing" them you probably missed to add these lines to your {{ic|/etc/lighttpd/lighttpd.conf}}.<br />
<br />
{{bc|1=<br />
server.modules = (<br />
"mod_fastcgi",<br />
)<br />
<br />
fastcgi.server = ( ".php" => ((<br />
"bin-path" => "/usr/bin/php-cgi", #depends where your php-cgi has been installed. Default here.<br />
"socket" => "/tmp/php.socket",<br />
"max-procs" => 2,<br />
"bin-environment" => (<br />
"PHP_FCGI_CHILDREN" => "16",<br />
"PHP_FCGI_MAX_REQUESTS" => "10000"<br />
),<br />
"bin-copy-environment" => (<br />
"PATH", "SHELL", "USER"<br />
),<br />
"broken-scriptfilename" => "enable"<br />
)))<br />
<br />
}}<br />
<br />
=== Styles (CSS) not working properly ===<br />
The default lighttpd config does not include a mimetype definition for CSS so when standards compliant browsers get text/html instead of text/css they get confused and nothing displays properly. To fix this add an entry for CSS.<br />
<br />
{{bc|1=<br />
mimetype.assign = (<br />
".html" => "text/html",<br />
".txt" => "text/plain",<br />
".jpg" => "image/jpeg",<br />
".png" => "image/png",<br />
".css" => "text/css",<br />
"" => "application/octet-stream"<br />
)<br />
}}<br />
New lines are not needed and are only used here for readability.<br />
<br />
Note: The "application/octet-stream" declaration must be at the end. It is a catch-all, and any declarations after it will be ignored.<br />
<br />
== See also ==<br />
* [http://redmine.lighttpd.net/projects/lighttpd/wiki Lighttpd wiki]</div>Geshhttps://wiki.archlinux.org/index.php?title=Systemd&diff=268785Systemd2013-07-30T10:57:11Z<p>Gesh: Clarified kernel line change</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Daemons and system services]]<br />
[[Category:Boot process]]<br />
[[ar:Systemd]]<br />
[[es:Systemd]]<br />
[[fr:Systemd]]<br />
[[it:Systemd]]<br />
[[ja:Systemd]]<br />
[[ru:Systemd]]<br />
[[zh-CN:Systemd]]<br />
[[zh-TW:Systemd]]<br />
{{Article summary start}}<br />
{{Article summary text|Covers how to install and configure systemd.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|systemd/User}}<br />
{{Article summary wiki|systemd/Services}}<br />
{{Article summary wiki|systemd FAQ}}<br />
{{Article summary wiki|init Rosetta}}<br />
{{Article summary wiki|Daemons List}}<br />
{{Article summary wiki|udev}}<br />
{{Article summary wiki|Improve Boot Performance}}<br />
{{Article summary end}}<br />
From the [http://freedesktop.org/wiki/Software/systemd project web page]:<br />
<br />
:''systemd'' is a system and service manager for Linux, compatible with SysV and LSB init scripts. ''systemd'' provides aggressive parallelization capabilities, uses socket and [[D-Bus]] activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux [[cgroups|control groups]], supports snapshotting and restoring of the system state, maintains mount and automount points and implements an elaborate transactional dependency-based service control logic.<br />
<br />
{{Note|1=For a detailed explanation as to why Arch has moved to ''systemd'', see [https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 this forum post].}}<br />
<br />
== Migration from SysVinit/initscripts ==<br />
<br />
{{Note|<br />
* {{Pkg|systemd}} and {{Pkg|systemd-sysvcompat}} are both installed by default on installation media newer than [https://www.archlinux.org/news/systemd-is-now-the-default-on-new-installations/ 2012-10-13]. This section is aimed at Arch Linux installations that still rely on ''sysvinit'' and ''initscripts''.<br />
* If you are running Arch Linux inside a VPS, please see [[Virtual Private Server#Moving your VPS from initscripts to systemd]].<br />
}}<br />
<br />
=== Considerations before switching ===<br />
<br />
* Do [http://freedesktop.org/wiki/Software/systemd/ some reading] about ''systemd''.<br />
* Note the fact that systemd has a ''journal'' system that replaces ''syslog'', although the two can co-exist. See [[#Journal]].<br />
* While ''systemd'' can replace some of the functionality of ''cron'', ''acpid'', or ''xinetd'', there is no need to switch away from using the traditional daemons unless you want to.<br />
* Interactive ''initscripts'' are not working with ''systemd''. In particular, ''netcfg-menu'' cannot be used at system start-up ({{Bug|31377}}).<br />
<br />
=== Installation procedure ===<br />
<br />
# [[pacman|Install]] {{Pkg|systemd}} from the [[official repositories]].<br />
# Append the following to your [[kernel parameters]]: {{ic|1=init=/usr/lib/systemd/systemd}}.<br />
# Once completed you may enable any desired services via the use of {{ic|systemctl enable ''service_name''}} (this roughly equates to what you included in the {{ic|DAEMONS}} array. New names can be found in [[Daemons List]]).<br />
# Reboot your system and verify that ''systemd'' is currently active by issuing the following command: {{ic|cat /proc/1/comm}}. This should return the string {{ic|systemd}}.<br />
# Make sure your hostname is set correctly under ''systemd'': {{ic|hostnamectl set-hostname ''myhostname''}}.<br />
# Proceed to remove ''initscripts'' and ''sysvinit'' from your system and install {{Pkg|systemd-sysvcompat}}.<br />
# Optionally, remove the {{ic|1=init=/usr/lib/systemd/systemd}} parameter. It is no longer needed since {{Pkg|systemd-sysvcompat}} provides a symlink to ''systemd'''s init where ''sysvinit'' used to be.<br />
<br />
=== Supplementary information ===<br />
<br />
* If you have {{ic|quiet}} in your kernel parameters, you might want to remove it for your first couple of systemd boots, to assist with identifying any issues during boot.<br />
<br />
* It is not necessary to add your user to [[Users and Groups|groups]] ({{ic|sys}}, {{ic|disk}}, {{ic|lp}}, {{ic|network}}, {{ic|video}}, {{ic|audio}}, {{ic|optical}}, {{ic|storage}}, {{ic|scanner}}, {{ic|power}}, etc.) for most use cases with systemd. The groups can even cause some functionality to break. For example, the {{ic|audio}} group will break fast user switching and allows applications to block software mixing. Every PAM login provides a logind session, which for a local session will give you permissions via [[Wikipedia:Access control list|POSIX ACLs]] on audio/video devices, and allow certain operations like mounting removable storage via [[udisks]].<br />
<br />
* See the [[Network Configuration]] article for how to set up networking targets.<br />
<br />
== Basic systemctl usage ==<br />
<br />
The main command used to introspect and control ''systemd'' is '''systemctl'''. Some of its uses are examining the system state and managing the system and services. See {{ic|man 1 systemctl}} for more details.<br />
<br />
{{Tip|You can use all of the following ''systemctl'' commands with the {{ic|-H ''user''@''host''}} switch to control a ''systemd'' instance on a remote machine. This will use [[SSH]] to connect to the remote ''systemd'' instance.}}<br />
<br />
{{Note|''systemadm'' is the official graphical frontend for ''systemctl''. It is provided by the {{AUR|systemd-ui-git}} package from the [[AUR]].}}<br />
<br />
=== Analyzing the system state ===<br />
<br />
List running units:<br />
<br />
$ systemctl<br />
<br />
or:<br />
<br />
$ systemctl list-units<br />
<br />
List failed units:<br />
<br />
$ systemctl --failed<br />
<br />
The available unit files can be seen in {{ic|/usr/lib/systemd/system/}} and {{ic|/etc/systemd/system/}} (the latter takes precedence). You can see a list of the installed unit files with:<br />
<br />
$ systemctl list-unit-files<br />
<br />
=== Using units ===<br />
<br />
Units can be, for example, services (''.service''), mount points (''.mount''), devices (''.device'') or sockets (''.socket'').<br />
<br />
When using ''systemctl'', you generally have to specify the complete name of the unit file, including its suffix, for example ''sshd.socket''. There are however a few short forms when specifying the unit in the following ''systemctl'' commands:<br />
<br />
* If you do not specify the suffix, systemctl will assume ''.service''. For example, {{ic|netcfg}} and {{ic|netcfg.service}} are equivalent.<br />
* Mount points will automatically be translated into the appropriate ''.mount'' unit. For example, specifying {{ic|/home}} is equivalent to {{ic|home.mount}}.<br />
* Similar to mount points, devices are automatically translated into the appropriate ''.device'' unit, therefore specifying {{ic|/dev/sda2}} is equivalent to {{ic|dev-sda2.device}}.<br />
<br />
See {{ic|man systemd.unit}} for details.<br />
<br />
Activate a unit immediately:<br />
<br />
# systemctl start ''unit''<br />
<br />
Deactivate a unit immediately:<br />
<br />
# systemctl stop ''unit''<br />
<br />
Restart a unit:<br />
<br />
# systemctl restart ''unit''<br />
<br />
Ask a unit to reload its configuration:<br />
<br />
# systemctl reload ''unit''<br />
<br />
Show the status of a unit, including whether it is running or not:<br />
<br />
$ systemctl status ''unit''<br />
<br />
Check whether a unit is already enabled or not:<br />
<br />
$ systemctl is-enabled ''unit''<br />
<br />
Enable a unit to be started on bootup:<br />
<br />
# systemctl enable ''unit''<br />
<br />
{{Note|Services without an {{ic|[Install]}} section are usually called automatically by other services. If you need to install them manually, use the following command, replacing ''foo'' with the name of the service.<br />
# ln -s /usr/lib/systemd/system/''foo''.service /etc/systemd/system/graphical.target.wants/<br />
}}<br />
<br />
Disable a unit to not start during bootup:<br />
<br />
# systemctl disable ''unit''<br />
<br />
Show the manual page associated with a unit (this has to be supported by the unit file):<br />
<br />
$ systemctl help ''unit''<br />
<br />
Reload ''systemd'', scanning for new or changed units:<br />
<br />
# systemctl daemon-reload<br />
<br />
=== Power management ===<br />
<br />
[[polkit]] is necessary for power management. If you are in a local ''systemd-logind'' user session and no other session is active, the following commands will work without root privileges. If not (for example, because another user is logged into a tty), ''systemd'' will automatically ask you for the root password.<br />
<br />
Shut down and reboot the system:<br />
<br />
$ systemctl reboot<br />
<br />
Shut down and power-off the system:<br />
<br />
$ systemctl poweroff<br />
<br />
Suspend the system:<br />
<br />
$ systemctl suspend<br />
<br />
Put the system into hibernation:<br />
<br />
$ systemctl hibernate<br />
<br />
Put the system into hybrid-sleep state (or suspend-to-both):<br />
<br />
$ systemctl hybrid-sleep<br />
<br />
== Running DMs under systemd ==<br />
<br />
{{Merge|Display Manager|We have separate article, this section should be moved there to keep things in one place.}}<br />
<br />
To enable graphical login, run your preferred [[Display Manager]] daemon (e.g. [[KDM]]). At the moment, service files exist for [[GDM]], [[KDM]], [[SLiM]], [[XDM]], [[LXDM]], [[LightDM]], and {{AUR|SDDM}}.<br />
<br />
# systemctl enable kdm<br />
<br />
This should work out of the box. If not, you might have a ''default.target'' set manually or from an older install:<br />
<br />
{{hc|# ls -l /etc/systemd/system/default.target|<br />
/etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target}}<br />
<br />
Simply delete the symlink and ''systemd'' will use its stock ''default.target'' (i.e. ''graphical.target'').<br />
<br />
# rm /etc/systemd/system/default.target<br />
<br />
=== Using systemd-logind ===<br />
<br />
In order to check the status of your user session, you can use {{ic|loginctl}}. All [[PolicyKit]] actions like suspending the system or mounting external drives will work out of the box.<br />
<br />
$ loginctl show-session $XDG_SESSION_ID<br />
<br />
== Native configuration ==<br />
<br />
{{Note|You may need to create these files. All files should have {{ic|644}} permissions and {{ic|root:root}} ownership.}}<br />
<br />
=== Virtual console ===<br />
{{Deletion|Not strictly related, trying to remove the [[#Native configuration]] section entirely.|section=Duplication of content in Native configuration section}}<br />
<br />
The virtual console (keyboard mapping, console font and console map) is configured in {{ic|/etc/vconsole.conf}} or by using the ''localectl'' tool.<br />
<br />
For more information, see [[Fonts#Console fonts|console fonts]] and [[KEYMAP|keymaps]].<br />
<br />
=== Hardware clock ===<br />
{{Merge|Time|This section was added here before systemd became the default init system. Delete it after merging.|section=Duplication of content in Native configuration section}}<br />
<br />
''systemd'' will use UTC for the hardware clock by default.<br />
<br />
{{Tip|It is advised to have the [[Network Time Protocol daemon]] running to keep the system time synchronized with Internet time and the hardware clock.}}<br />
<br />
==== Hardware clock in localtime ====<br />
<br />
If you want to change the hardware clock to use local time ('''strongly discouraged''') do:<br />
<br />
# timedatectl set-local-rtc true<br />
<br />
If you want to revert to the hardware clock being in UTC, do:<br />
<br />
# timedatectl set-local-rtc false<br />
<br />
Be warned that, if the hardware clock is set to localtime, dealing with daylight saving time is messy. If the DST changes when your computer is off, your clock will be wrong on next boot ([http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html there is a lot more to it]). Recent kernels set the system time from the RTC directly on boot, assuming that the RTC is in UTC. This means that if the RTC is in local time, then the system time will first be set up wrongly and then corrected shortly afterwards on every boot. This is the root of certain weird bugs (time going backwards is rarely a good thing).<br />
<br />
One reason for allowing the RTC to be in local time is to allow dual boot with Windows ([http://blogs.msdn.com/b/oldnewthing/archive/2004/09/02/224672.aspx which uses localtime]). However, Windows is able to deal with the RTC being in UTC with a simple [[Time#UTC in Windows|registry fix]]. It is recommended to configure Windows to use UTC, rather than Linux to use localtime. If you make Windows use UTC, also remember to disable the "Internet Time Update" Windows feature, so that Windows does not mess with the hardware clock, trying to sync it with internet time. You should instead leave touching the RTC and syncing it to internet time to Linux, by enabling an [[NTP]] daemon, as suggested previously.<br />
<br />
For more information, see [[Time]].<br />
<br />
=== Kernel modules ===<br />
{{Deletion|Not strictly related, trying to remove the [[#Native configuration]] section entirely.|section=Duplication of content in Native configuration section}}<br />
<br />
See [[Kernel modules#Configuration]].<br />
<br />
=== Filesystem mounts ===<br />
{{Merge|File Systems|This section was added here before systemd became the default init system. Delete it after merging.|section=Duplication of content in Native configuration section}}<br />
<br />
The default setup will automatically fsck and mount filesystems before starting services that need them to be mounted. For example, systemd automatically makes sure that remote filesystem mounts like [[NFS]] or [[Samba]] are only started after the network has been set up. Therefore, local and remote filesystem mounts specified in {{ic|/etc/fstab}} should work out of the box.<br />
<br />
See {{ic|man 5 systemd.mount}} for details.<br />
<br />
==== Automount ====<br />
{{Merge|fstab|This section was added here before systemd became the default init system. Delete it after merging.|section=Duplication of content in Native configuration section}}<br />
<br />
If you have a large {{ic|/home}} partition, it might be better to allow services that do not depend on {{ic|/home}} to start while {{ic|/home}} is checked by ''fsck''. This can be achieved by adding the following options to the {{ic|/etc/fstab}} entry of your {{ic|/home}} partition:<br />
<br />
noauto,x-systemd.automount<br />
<br />
This will fsck and mount {{ic|/home}} when it is first accessed, and the kernel will buffer all file access to {{ic|/home}} until it is ready.<br />
<br />
{{Note|This will make your {{ic|/home}} filesystem type {{ic|autofs}}, which is ignored by [[mlocate]] by default. The speedup of automounting {{ic|/home}} may not be more than a second or two, depending on your system, so this trick may not be worth it.}}<br />
<br />
The same applies to remote filesystem mounts. If you want them to be mounted only upon access, you will need to use the {{ic|noauto,x-systemd.automount}} parameters. In addition, you can use the {{ic|1=x-systemd.device-timeout=#}} option to specify a timeout in case the network resource is not available.<br />
<br />
If you have encrypted filesystems with keyfiles, you can also add the {{ic|noauto}} parameter to the corresponding entries in {{ic|/etc/crypttab}}. ''systemd'' will then not open the encrypted device on boot, but instead wait until it is actually accessed and then automatically open it with the specified keyfile before mounting it. This might save a few seconds on boot if you are using an encrypted RAID device for example, because systemd does not have to wait for the device to become available. For example:<br />
<br />
{{hc|/etc/crypttab|<br />
data /dev/md0 /root/key noauto}}<br />
<br />
==== LVM ====<br />
{{Merge|LVM|This section was added here before systemd became the default init system. Delete it after merging.|section=Duplication of content in Native configuration section}}<br />
<br />
If you have [[LVM]] volumes not activated via the [[Mkinitcpio|initramfs]], [[Systemd#Using_units|enable]] the '''lvm-monitoring''' service, which is provided by the {{pkg|lvm2}} package.<br />
<br />
=== ACPI power management ===<br />
{{Deletion|Not strictly related, trying to remove the [[#Native configuration]] section entirely.|section=Duplication of content in Native configuration section}}<br />
<br />
See [[Power Management]].<br />
<br />
=== Temporary files ===<br />
{{Moveto|Systemd#|Trying to remove the [[#Native configuration]] section entirely, this section can easily become a top-level one like [[#Journal]].|section=Duplication of content in Native configuration section}}<br />
<br />
'''systemd-tmpfiles''' uses configuration files in {{ic|/usr/lib/tmpfiles.d/}} and {{ic|/etc/tmpfiles.d/}} to describe the creation, cleaning and removal of volatile and temporary files and directories which usually reside in directories such as {{ic|/run}} or {{ic|/tmp}}. Each configuration file is named in the style of {{ic|/etc/tmpfiles.d/''program''.conf}}. This will also override any files in {{ic|/usr/lib/tmpfiles.d/}} with the same name.<br />
<br />
tmpfiles are usually provided together with service files to create directories which are expected to exist by certain daemons. For example the [[Samba]] daemon expects the directory {{ic|/run/samba}} to exist and to have the correct permissions. Therefore, the {{Pkg|samba}} package ships with this configuration:<br />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /run/samba 0755 root root}}<br />
<br />
tmpfiles may also be used to write values into certain files on boot. For example, if you used {{ic|/etc/rc.local}} to disable wakeup from USB devices with {{ic|echo USBE > /proc/acpi/wakeup}}, you may use the following tmpfile instead:<br />
<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE}}<br />
<br />
See {{ic|man 5 tmpfiles.d}} for details.<br />
<br />
{{Note|This method may not work to set options in {{ic|/sys}} since the ''systemd-tmpfiles-setup'' service may run before the appropriate device modules is loaded. In this case you could check whether the module has a parameter for the option you want to set with {{ic|modinfo ''module''}} and set this option with a [[Modprobe.d#Configuration|config file in /etc/modprobe.d]]. Otherwise you will have to write a [[Udev#About_udev_rules|udev rule]] to set the appropriate attribute as soon as the device appears.}}<br />
<br />
== Writing custom .service files ==<br />
<br />
The syntax of systemd's [[#Using units|unit files]] is inspired by XDG Desktop Entry Specification .desktop files, which are in turn inspired by Microsoft Windows .ini files.<br />
<br />
See [[systemd/Services]] for more examples.<br />
<br />
=== Handling dependencies ===<br />
<br />
With ''systemd'', dependencies can be resolved by designing the unit files correctly. The most typical case is that the unit ''A'' requires the unit ''B'' to be running before ''A'' is started. In that case add {{ic|1=Requires=''B''}} and {{ic|1=After=''B''}} to the {{ic|[Unit]}} section of ''A''. If the dependency is optional, add {{ic|1=Wants=''B''}} and {{ic|1=After=''B''}} instead. Note that {{ic|1=Wants=}} and {{ic|1=Requires=}} do not imply {{ic|1=After=}}, meaning that if {{ic|1=After=}} is not specified, the two units will be started in parallel.<br />
<br />
Dependencies are typically placed on services and not on targets. For example, ''network.target'' is pulled in by whatever service configures your network interfaces, therefore ordering your custom unit after it is sufficient since ''network.target'' is started anyway.<br />
<br />
=== Type ===<br />
<br />
There are several different start-up types to consider when writing a custom service file. This is set with the {{ic|1=Type=}} parameter in the {{ic|[Service]}} section. See {{ic|man systemd.service}} for a more detailed explanation.<br />
<br />
* {{ic|1=Type=simple}} (default): ''systemd'' considers the service to be started up immediately. The process must not fork. Do not use this type if other services need to be ordered on this service, unless it is socket activated.<br />
* {{ic|1=Type=forking}}: ''systemd'' considers the service started up once the process forks and the parent has exited. For classic daemons use this type unless you know that it is not necessary. You should specify {{ic|1=PIDFile=}} as well so ''systemd'' can keep track of the main process.<br />
* {{ic|1=Type=oneshot}}: this is useful for scripts that do a single job and then exit. You may want to set {{ic|1=RemainAfterExit=yes}} as well so that ''systemd'' still considers the service as active after the process has exited.<br />
* {{ic|1=Type=notify}}: identical to {{ic|1=Type=simple}}, but with the stipulation that the daemon will send a signal to ''systemd'' when it is ready. The reference implementation for this notification is provided by ''libsystemd-daemon.so''.<br />
* {{ic|1=Type=dbus}}: the service is considered ready when the specified {{ic|BusName}} appears on DBus's system bus.<br />
<br />
=== Editing provided unit files ===<br />
<br />
To edit a unit file provided by a package, you can create a directory called {{ic|/etc/systemd/system/''unit''.d/}} for example {{ic|/etc/systemd/system/httpd.service.d/}} and place ''*.conf'' files in there to override or add new options. ''systemd'' will parse these ''*.conf'' files and apply them on top of the original unit. For example, if you simply want to add an additional dependency to a unit, you may create the following file:<br />
<br />
{{hc|/etc/systemd/system/''unit''.d/customdependency.conf|2=<br />
[Unit]<br />
Requires=''new dependency''<br />
After=''new dependency''}}<br />
<br />
Then run the following for your changes to take effect:<br />
<br />
# systemctl daemon-reload<br />
# systemctl restart ''unit''<br />
<br />
Alternatively you can copy the old unit file from {{ic|/usr/lib/systemd/system/}} to {{ic|/etc/systemd/system/}} and make your changes there. A unit file in {{ic|/etc/systemd/system/}} always overrides the same unit in {{ic|/usr/lib/systemd/system/}}. Note that when the original unit in {{ic|/usr/lib/}} is changed due to a package upgrade, these changes will not automatically apply to your custom unit file in {{ic|/etc/}}. Additionally you will have to manually reenable the unit with {{ic|systemctl reenable ''unit''}}. It is therefore recommended to use the ''*.conf'' method described before instead.<br />
<br />
{{Tip|You can use '''systemd-delta''' to see which unit files have been overridden and what exactly has been changed.}}<br />
<br />
As the provided unit files will be updated from time to time, use ''systemd-delta'' for system maintenance.<br />
<br />
=== Syntax highlighting for units within Vim ===<br />
<br />
Syntax highlighting for ''systemd'' unit files within [[Vim]] can be enabled by installing {{Pkg|vim-systemd}} from the [[Official Repositories|official repositories]].<br />
<br />
== Targets ==<br />
<br />
''systemd'' uses ''targets'' which serve a similar purpose as runlevels but act a little different. Each ''target'' is named instead of numbered and is intended to serve a specific purpose with the possibility of having multiple ones active at the same time. Some ''target''s are implemented by inheriting all of the services of another ''target'' and adding additional services to it. There are ''systemd'' ''target''s that mimic the common SystemVinit runlevels so you can still switch ''target''s using the familiar {{ic|telinit RUNLEVEL}} command.<br />
<br />
=== Get current targets ===<br />
<br />
The following should be used under ''systemd'' instead of running {{ic|runlevel}}:<br />
<br />
$ systemctl list-units --type=target<br />
<br />
=== Create custom target ===<br />
<br />
The runlevels that are assigned a specific purpose on vanilla Fedora installs; 0, 1, 3, 5, and 6; have a 1:1 mapping with a specific ''systemd'' ''target''. Unfortunately, there is no good way to do the same for the user-defined runlevels like 2 and 4. If you make use of those it is suggested that you make a new named ''systemd'' ''target'' as {{ic|/etc/systemd/system/''your target''}} that takes one of the existing runlevels as a base (you can look at {{ic|/usr/lib/systemd/system/graphical.target}} as an example), make a directory {{ic|/etc/systemd/system/''your target''.wants}}, and then symlink the additional services from {{ic|/usr/lib/systemd/system/}} that you wish to enable.<br />
<br />
=== Targets table ===<br />
<br />
{| border="1"<br />
! SysV Runlevel !! systemd Target !! Notes<br />
|-<br />
| 0 || runlevel0.target, poweroff.target || Halt the system.<br />
|-<br />
| 1, s, single || runlevel1.target, rescue.target || Single user mode.<br />
|-<br />
| 2, 4 || runlevel2.target, runlevel4.target, multi-user.target || User-defined/Site-specific runlevels. By default, identical to 3.<br />
|-<br />
| 3 || runlevel3.target, multi-user.target || Multi-user, non-graphical. Users can usually login via multiple consoles or via the network.<br />
|-<br />
| 5 || runlevel5.target, graphical.target || Multi-user, graphical. Usually has all the services of runlevel 3 plus a graphical login.<br />
|-<br />
| 6 || runlevel6.target, reboot.target || Reboot<br />
|-<br />
| emergency || emergency.target || Emergency shell<br />
|-<br />
|}<br />
<br />
=== Change current target ===<br />
<br />
In ''systemd'' targets are exposed via ''target units''. You can change them like this:<br />
<br />
# systemctl isolate graphical.target<br />
<br />
This will only change the current target, and has no effect on the next boot. This is equivalent to commands such as {{ic|telinit 3}} or {{ic|telinit 5}} in Sysvinit.<br />
<br />
=== Change default target to boot into ===<br />
<br />
The standard target is ''default.target'', which is aliased by default to ''graphical.target'' (which roughly corresponds to the old runlevel 5). To change the default target at boot-time, append one of the following [[kernel parameters]] to your bootloader:<br />
<br />
{{Tip|The ''.target'' extension can be left out.}}<br />
<br />
* {{ic|1=systemd.unit=multi-user.target}} (which roughly corresponds to the old runlevel 3),<br />
* {{ic|1=systemd.unit=rescue.target}} (which roughly corresponds to the old runlevel 1).<br />
<br />
Alternatively, you may leave the bootloader alone and change ''default.target''. This can be done using ''systemctl'':<br />
<br />
# systemctl enable multi-user.target<br />
<br />
The effect of this command is output by ''systemctl''; a symlink to the new default target is made at {{ic|/etc/systemd/system/default.target}}. This works if, and only if:<br />
<br />
[Install]<br />
Alias=default.target<br />
<br />
is in the target's configuration file. Currently, ''multi-user.target'' and ''graphical.target'' both have it.<br />
<br />
== Journal ==<br />
<br />
''systemd'' has its own logging system called the journal; therefore, running a syslog daemon is no longer required. To read the log, use:<br />
<br />
# journalctl<br />
<br />
By default (when {{ic|1=Storage=}} is set to {{ic|auto}} in {{ic|/etc/systemd/journald.conf}}), the journal writes to {{ic|/var/log/journal/}}. The directory {{ic|/var/log/journal/}} is a part of the ''systemd'' package. If you or some program delete that directory, systemd will '''not''' recreate it automatically; however, it will be recreated during the next update of the systemd package. Until then, logs will be written to {{ic|/run/systemd/journal}}, and logs will be lost on reboot.<br />
<br />
{{Tip|If {{ic|/var/log/journal/}} resides in a [[btrfs]] filesystem you should consider disabling [[Btrfs#Copy-On-Write_.28CoW.29|Copy-on-Write]] for the directory:<br />
# chattr +C /var/log/journal<br />
}}<br />
<br />
=== Filtering output ===<br />
<br />
''journalctl'' allows you to filter the output by specific fields.<br />
<br />
Examples:<br />
<br />
Show all messages from this boot:<br />
<br />
# journalctl -b<br />
<br />
However, often one is interested in messages not from the current, but from the previous boot (e.g. if an unrecoverable system crash happened). Currently, this feature is not implemented, though there was a discussion at [http://comments.gmane.org/gmane.comp.sysutils.systemd.devel/6608 systemd-devel@lists.freedesktop.org] (September/October 2012).<br />
<br />
As a workaround you can use at the moment:<br />
<br />
# journalctl --since=today | tac | sed -n '/-- Reboot --/{n;:r;/-- Reboot --/q;p;n;b r}' | tac<br />
<br />
provided, that the previous boot happened today. Be aware that, if there are many messages for the current day, the output of this command can be delayed for quite some time.<br />
{{note|This needs to be corrected once 206 lands. {{ic|journalctl -b}} now takes arguments such as {{ic|-1}} for the last boot or a boot id. E.g. {{ic|journalctl -b -3}} will show all messages from the third to last boot.}}<br />
<br />
Follow new messages:<br />
<br />
# journalctl -f<br />
<br />
Show all messages by a specific executable:<br />
<br />
# journalctl /usr/lib/systemd/systemd<br />
<br />
Show all messages by a specific process:<br />
<br />
# journalctl _PID=1<br />
<br />
Show all messages by a specific unit:<br />
<br />
# journalctl -u netcfg<br />
<br />
See {{ic|man 1 journalctl}}, {{ic|man 7 systemd.journal-fields}}, or Lennert's [http://0pointer.de/blog/projects/journalctl.html blog post] for details.<br />
<br />
=== Journal size limit ===<br />
<br />
If the journal is persistent (non-volatile), its size limit is set to a default value of 10% of the size of the respective file system. For example, with {{ic|/var/log/journal}} located on a 50 GiB root partition this would lead to 5 GiB of journal data. The maximum size of the persistent journal can be controlled by {{ic|SystemMaxUse}} in {{ic|/etc/systemd/journald.conf}}, so to limit it for example to 50 MiB uncomment and edit the corresponding line to:<br />
<br />
SystemMaxUse=50M<br />
<br />
Refer to {{ic|man journald.conf}} for more info.<br />
<br />
=== Journald in conjunction with syslog ===<br />
<br />
Compatibility with classic syslog implementations is provided via a socket {{ic|/run/systemd/journal/syslog}}, to which all messages are forwarded. To make the syslog daemon work with the journal, it has to bind to this socket instead of {{ic|/dev/log}} ([http://lwn.net/Articles/474968/ official announcement]). The {{Pkg|syslog-ng}} package in the repositories automatically provides the necessary configuration.<br />
<br />
# systemctl enable syslog-ng<br />
<br />
A good ''journalctl'' tutorial is [http://0pointer.de/blog/projects/journalctl.html here].<br />
<br />
== Troubleshooting ==<br />
<br />
=== Shutdown/reboot takes terribly long ===<br />
<br />
If the shutdown process takes a very long time (or seems to freeze) most likely a service not exiting is to blame. ''systemd'' waits some time for each service to exit before trying to kill it. To find out if you are affected, see [http://freedesktop.org/wiki/Software/systemd/Debugging#Shutdown_Completes_Eventually this article].<br />
<br />
=== Short lived processes do not seem to log any output ===<br />
<br />
If {{ic|journalctl -u foounit}} does not show any output for a short lived service, look at the PID instead. For example, if {{ic|systemd-modules-load.service}} fails, and {{ic|systemctl status systemd-modules-load}} shows that it ran as PID 123, then you might be able to see output in the journal for that PID, i.e. {{ic|journalctl -b _PID&#61;123}}. Metadata fields for the journal such as _SYSTEMD_UNIT and _COMM are collected asynchronously and rely on the {{ic|/proc}} directory for the process existing. Fixing this requires fixing the kernel to provide this data via a socket connection, similar to SCM_CREDENTIALS.<br />
<br />
=== Diagnosing boot problems ===<br />
<br />
Boot with these parameters on the kernel command line:<br />
{{ic|<nowiki>systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M</nowiki>}}<br />
<br />
[http://freedesktop.org/wiki/Software/systemd/Debugging More Debugging Information]<br />
<br />
=== Disabling application crash dumps journaling ===<br />
<br />
To get back normal core dump files, edit the following file in order to overwrite the settings from {{ic|/lib/sysctl.d/}}:<br />
<br />
{{hc|/etc/sysctl.d/49-coredump.conf|2=<nowiki><br />
kernel.core_pattern = core<br />
kernel.core_uses_pid = 0</nowiki>}}<br />
<br />
Then run:<br />
# /usr/lib/systemd/systemd-sysctl<br />
<br />
As before, you also need to "unlimit" the core files size in the shell:<br />
$ ulimit -c unlimited<br />
<br />
See [http://www.freedesktop.org/software/systemd/man/sysctl.d.html sysctl.d] and [https://www.kernel.org/doc/Documentation/sysctl/kernel.txt the documentation for /proc/sys/kernel] for more information.<br />
<br />
== See also ==<br />
<br />
*[http://www.freedesktop.org/wiki/Software/systemd Official web site]<br />
*[[Wikipedia:systemd|Wikipedia article]]<br />
*[http://0pointer.de/public/systemd-man/ Manual pages]<br />
*[http://freedesktop.org/wiki/Software/systemd/Optimizations systemd optimizations]<br />
*[http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions FAQ]<br />
*[http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks Tips and tricks]<br />
*[http://0pointer.de/public/systemd-ebook-psankar.pdf systemd for Administrators (PDF)]<br />
*[http://fedoraproject.org/wiki/Systemd About systemd on Fedora Project]<br />
*[http://fedoraproject.org/wiki/How_to_debug_Systemd_problems How to debug systemd problems]<br />
*[http://www.h-online.com/open/features/Control-Centre-The-systemd-Linux-init-system-1565543.html Two] [http://www.h-online.com/open/features/Booting-up-Tools-and-tips-for-systemd-1570630.html part] introductory article in ''The H Open'' magazine.<br />
*[http://0pointer.de/blog/projects/systemd.html Lennart's blog story]<br />
*[http://0pointer.de/blog/projects/systemd-update.html Status update]<br />
*[http://0pointer.de/blog/projects/systemd-update-2.html Status update2]<br />
*[http://0pointer.de/blog/projects/systemd-update-3.html Status update3]<br />
*[http://0pointer.de/blog/projects/why.html Most recent summary]<br />
*[http://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet Fedora's SysVinit to systemd cheatsheet]</div>Geshhttps://wiki.archlinux.org/index.php?title=Partitioning&diff=268769Partitioning2013-07-30T08:46:34Z<p>Gesh: Fixed where/were spelling error</p>
<hr />
<div>[[Category:File systems]]<br />
[[ar:Partitioning]]<br />
[[es:Partitioning]]<br />
[[it:Partitioning]]<br />
[[ja:Partitioning]]<br />
[[ru:Partitioning]]<br />
[[zh-cn:Partitioning]]<br />
{{Article summary start}}<br />
{{Article summary text|An overview of disk partitioning tools, best practices, and additional considerations.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|fstab}}<br />
{{Article summary wiki|LVM}}<br />
{{Article summary wiki|Swap}}<br />
{{Article summary wiki|Format a device}}<br />
{{Article summary wiki|File Systems}}<br />
{{Article summary end}}<br />
''Partitioning'' a hard drive allows one to logically divide the available space into sections that can be accessed independently of one another.<br />
<br />
An entire hard drive may be allocated to a single partition, or one may divide the available storage space across multiple partitions. A number of scenarios require creation multiple partitions: dual- or multi-booting, for example, or maintaining a [[swap]] partition. In other cases, partitioning is used as a means of logically separating data, such as creating separate partitions for audio and video files. Common partitioning schemes are discussed in detail below. <br />
<br />
Each partition should be formatted to a [[File Systems|file system type]] before being used.<br />
<br />
== Partition table ==<br />
<br />
Partition information is stored in the partition table, for which there are 2 formats of in use today. The classic [[Master Boot Record]], and the modern [[GUID Partition Table]] which is an improved version that does away with several limitations.<br />
<br />
=== Master Boot Record ===<br />
{{Wikipedia|Master boot record}}<br />
<br />
MBR originally only supported up to 4 partitions. Later on, extended and logical partitions were introduced to get around this limitation.<br />
<br />
There are 3 types of partitions:<br />
<br />
* Primary<br />
* Extended<br />
** Logical<br />
<br />
'''Primary''' partitions can be bootable and are limited to four partitions per disk or RAID volume. If a partitioning scheme requires more than four partitions, an '''extended''' partition containing '''logical''' partitions is used. Extended partitions can be thought of as containers for logical partitions. A hard disk can contain no more than one extended partition. The extended partition is also counted as a primary partition so if the disk has an extended partition, only three additional primary partitions are possible (i.e. three primary partitions and one extended partition). The number of logical partitions residing in an extended partition is unlimited. A system that dual boots with Windows will require that Windows reside in a primary partition.<br />
<br />
The customary numbering scheme is to create primary partitions ''sda1'' through ''sda3'' followed by an extended partition ''sda4''. The logical partitions on ''sda4'' are numbered ''sda5'', ''sda6'', etc.<br />
<br />
=== GUID Partition Table ===<br />
{{Wikipedia|GUID Partition Table}}<br />
<br />
There is only one type of partition, '''primary'''. The amount of partitions per disk or RAID volume is unlimited.<br />
<br />
=== Choosing between GPT and MBR ===<br />
<br />
[[GUID Partition Table]] (GPT) is an alternative, contemporary partitioning style. It is intended to replace the old [[Master Boot Record]] (MBR) system. GPT has several advantages over MBR, which has quirks dating back to MS-DOS times. With recent developments to the formatting tools ''fdisk'' (MBR) and ''gdisk'' (GPT), it is equally easy to use GPT or MBR and get maximum performance. <br />
<br />
The choice basically boils down to this:<br />
* If using GRUB legacy as the bootloader, one must use MBR.<br />
* To dual-boot with Windows, one must use MBR.<br />
** A special exception to this rule: dual-booting Windows 64-bit using [[UEFI]] instead of BIOS, one must use GPT.<br />
* If none of the above apply, choose freely between GPT and MBR. Since GPT is more modern, it is recommended in this case.<br />
* It is recommended to use always GPT for [[Unified Extensible Firmware Interface|UEFI]] boot as some UEFI firmwares do not allow UEFI-MBR boot.<br />
<br />
== Partition scheme ==<br />
<br />
There are no strict rules for partitioning a hard drive, although one may follow the general guidance given below. A disk partitioning scheme is determined by various issues such as desired flexibility, speed, security, as well as the limitations imposed by available disk space. It is essentially personal preference. If you would like to dual boot Arch Linux and a Windows operating system please see [[Windows and Arch Dual Boot]].<br />
<br />
=== Single root partition ===<br />
<br />
This scheme is the simplest and should be enough for most use cases. A [[swapfile]] can be created and easily resized as needed. It usually makes sense to start by considering a single {{ic|/}} partition and then separate out others based on specific use cases like RAID, encryption, a shared media partition, etc.<br />
<br />
=== Discrete partitions ===<br />
<br />
Separating out a path as a partition allows for the choice of a different filesystem and mount options. In some cases like a media partition, they can also be shared between operating systems.<br />
<br />
=== Mount points ===<br />
<br />
The following mount points are possible choices for separate partitions, you can make your decision based on actual needs.<br />
<br />
==== Root partition ====<br />
<br />
The root directory is the top of the hierarchy, the point where the primary filesystem is mounted and from which all other filesystems stem. All files and directories appear under the root directory {{ic|/}}, even if they are stored on different physical devices. The contents of the root filesystem must be adequate to boot, restore, recover, and/or repair the system. Therefore, certain directories under {{ic|/}} are not candidates for separate partitions.<br />
<br />
The {{ic|/}} partition or root partition is necessary and it is the most important. The other partitions can be replaced by it.<br />
<br />
{{Warning|Directories essential for booting (except for {{ic|/boot}}) '''must''' be on the same partition as {{ic|/}} or mounted in early userspace by the [[initramfs]]. These essential directories are: {{ic|/etc}} and {{ic|/usr}} [http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken].}}<br />
<br />
==== /boot ====<br />
<br />
The {{ic|/boot}} directory contains the kernel and ramdisk images as well as the bootloader configuration file and bootloader stages. It also stores data that is used before the kernel begins executing user-space programs. {{ic|/boot}} is not required for normal system operation, but only during boot and kernel upgrades (when regenerating the initial ramdisk).<br />
<br />
A separate {{ic|/boot}} partition is needed if installing a software RAID0 (stripe) system.<br />
<br />
==== /home ====<br />
<br />
The {{ic|/home}} directory contains user-specific configuration files, caches, application data and media files.<br />
<br />
Separating out {{ic|/home}} allows {{ic|/}} to be re-partitioned separately, but note that you can still reinstall Arch with {{ic|/home}} untouched even if it isn't separate - the other top-level directories just need to be removed, and then pacstrap can be run.<br />
<br />
You should not share home directories between users on different distributions, because they use incompatible software versions and patches. Instead, consider sharing a media partition or at least using different home directories on the same {{ic|/home}} partition.<br />
<br />
==== /var ====<br />
<br />
The {{ic|/var}} directory stores variable data such as spool directories and files, administrative and logging data, [[pacman]]'s cache, the [[ABS]] tree, etc. It is used, for example, for caching and logging, and hence frequently read or written. Keeping it in a separate partition avoids running out of disk space due to flunky logs, etc.<br />
<br />
It exists to make it possible to mount {{ic|/usr}} as read-only. Everything that historically went into {{ic|/usr}} that is written to during system operation (as opposed to installation and software maintenance) must reside under {{ic|/var}}.<br />
<br />
{{Note|{{ic|/var}} contains many small files. The choice of file system type should consider this fact if a separate partition is used.}}<br />
<br />
==== /tmp ====<br />
<br />
This is already a separate partition by default, by virtue of being mounted as ''tmpfs'' by systemd.<br />
<br />
==== Swap ====<br />
<br />
A [[swap]] partition provides memory that can be used as virtual RAM. A [[Swap#Swap file|swap file]] should be considered too, as they have almost no performance overhead compared to a partition but are much easier to resize as needed. A swap partition can ''potentially'' be shared between operating systems, but not if hibernation is used.<br />
<br />
==== How big should my partitions be? ====<br />
<br />
{{Note|The below are simply recommendations; there is no hard rule dictating partition size.}}<br />
The size of the partitions depends on personal preference, but the following information may be helpful:<br />
<br />
; /boot - 200 MB : It requires only about 100 MB, but if multiple kernels/boot images are likely to be in use, 200 or 300 MB is a better choice.<br />
; / - 15-20 GB : It traditionally contains the {{ic|/usr}} directory, which can grow significantly depending upon how much software is installed. 15-20 GB should be sufficient for most users with modern hard disks.<br />
; /var - 8-12 GB : It will contain, among other data, the [[ABS]] tree and the [[pacman]] cache. Keeping cached packages is useful and versatile as it provides the ability to downgrade. As a result, {{ic|/var}} tends to grow in size. The pacman cache in particular will grow as the system is expanded and updated. It can, however, be safely cleared if space becomes an issue. 8-12 GB on a desktop system should be sufficient for {{ic|/var}}, depending on how much software will be installed.<br />
; /home - [varies] : It is typically where user data, downloads, and multimedia reside. On a desktop system, {{ic|/home}} is typically the largest filesystem on the drive by a large margin.<br />
; swap - [varies] : Historically, the general rule for swap partition size was to allocate twice the amount of physical RAM. As computers have gained ever larger memory capacities, this rule has become deprecated. On machines with up to 512MB RAM, the 2x rule is usually adequate. If a sufficient amount of RAM (more than 1024MB) is available, it may be possible to have a smaller swap partition or even eliminate it. With more than 2 GB of physical RAM, one can generally expect good performance without a swap partition.<br />
: {{Note|If you plan to hibernate into a swap partition/file, you should see [[Suspend and Hibernate#About swap partition/file size]].}}<br />
; /data - [varies] : One can consider mounting a "data" partition to cover various files to be shared by all users. Using the {{ic|/home}} partition for this purpose is fine as well.<br />
<br />
{{Note|If available, an extra 25% of space added to each filesystem will provide a cushion for future expansion and help protect against fragmentation.}}<br />
<br />
== Partitioning tools ==<br />
<br />
*{{App|fdisk|Terminal partitioning tools included in Linux.|https://www.kernel.org/|{{Pkg|util-linux}}}}<br />
*{{App|cfdisk|Terminal partitioning tool written with ncurses libraries.|https://www.kernel.org/|{{Pkg|util-linux}}}}<br />
{{Warning|The first partition created by ''cfdisk'' starts at sector 63, instead of the usual 2048. This can lead to reduced performance on SSD and advanced format (4k sector) drives. It will cause problems with [[GRUB2#msdos-style error message|GRUB2]]. GRUB legacy and Syslinux should work fine.}}<br />
*{{App|gdisk|[[GPT]] version of fdisk.|http://www.rodsbooks.com/gdisk/|{{Pkg|gptfdisk}}}}<br />
*{{App|cgdisk|GPT version of cfdisk.|http://www.rodsbooks.com/gdisk/|{{Pkg|gptfdisk}}}}<br />
*{{App|GNU Parted|Terminal partitioning tool.|http://www.gnu.org/software/parted/parted.html|{{pkg|parted}}}}<br />
*{{App|[[GParted]]|Graphical tool written in GTK.|http://gparted.sourceforge.net/|{{Pkg|gparted}}}}<br />
*{{App|Partitionmanager|Graphical tool written in QT.|http://sourceforge.net/projects/partitionman/|{{AUR|partitionmanager}}}}<br />
*{{App|QtParted|Similar to Partitionmanager, available in [[AUR]].|http://qtparted.sourceforge.net/|{{AUR|qtparted}}}}<br />
<br />
== Partition alignment ==<br />
<br />
'''Proper partition alignment is essential for optimal performance and longevity.''' The key to alignment is partitioning to (at least) the EBS (erase block size) of the SSD.<br />
<br />
{{Note|<br />
* The EBS is largely vendor specific; a Google search on the model of interest would be a good idea. The Intel X25-M for example is thought to have an EBS of 512 KiB, but Intel has yet to publish anything officially to this end.<br />
* If one does not know the EBS of one's SSD, use a size of 512 KiB. Those numbers are greater or equal than almost all of the current EBS. Aligning partitions for such an EBS will result in partitions also aligned for all lesser sizes. This is how Windows 7 and Ubuntu "optimize" partitions to work with SSD.<br />
}}<br />
<br />
If the partitions are not aligned to begin at multiples of the EBS (512 KiB for example), aligning the file system is a pointless exercise because everything is skewed by the start offset of the partition. Traditionally, hard drives were addressed by indicating the ''cylinder'', the ''head'', and the ''sector'' at which data was to be read or written. These represented the radial position, the drive head (= platter and side) and the axial position of the data respectively. With LBA (logical block addressing), this is no longer the case. Instead, the entire hard drive is addressed as one continuous stream of data.<br />
<br />
== Using GPT - modern method ==<br />
<br />
=== Gdisk usage summary===<br />
<br />
Using GPT, the utility for editing the partition table is called ''gdisk''. It can perform partition alignment automatically on a 2048 sector (or 1024KiB) block size base which should be compatible with the vast majority of SSDs if not all. GNU parted also supports GPT, but is [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 less user-friendly] for aligning partitions. The environment provided by the Arch install ISO includes the ''gdisk'' command. If you need it later on in the installed system, ''gdisk'' is available in the {{Pkg|gptfdisk}} package.<br />
<br />
A summary of the typical usage of ''gdisk'':<br />
<br />
* Start ''gdisk'' against your drive as root (''disk-device'' may be e.g. {{ic|/dev/sda}}):<br />
# gdisk ''disk-device''<br />
* If the drive is brand new or if you are wanting to start over, create a new empty GUID partition table with the {{ic|o}} command.<br />
* Create a new partition with the {{ic|n}} command (primary type/1st partition).<br />
* Assuming the partition is new, ''gdisk'' will pick the highest possible alignment. Otherwise, it will pick the largest power of two that divides all partition offsets.<br />
* If choosing to start on a sector before the 2048th ''gdisk'' will automatically shift the partition start to the 2048th disk sector. This is to ensure a 2048-sectors alignment (as a sector is 512B, this is a 1024KiB alignment which should fit any SSD NAND erase block).<br />
* Use the {{ic|+''x''&#123;M,G&#125;}} format to extend the partition ''x'' mebibytes or gibibytes, if choosing a size that is not a multiple of the alignment size (1024kiB), ''gdisk'' will shrink the partition to the nearest inferior multiple. For example, if you want to create a 15GiB partition, you would enter {{ic|+15G}}<br />
* Select the partition's type id, the default, {{ic|Linux/Windows data}} (code {{ic|0700}}), should be fine for most use. Press {{ic|L}} to show the codes list. If planning to use LVM select {{ic|Linux LVM}} ({{ic|8e00}}).<br />
* Assign other partitions in a like fashion.<br />
* Write the table to disk and exit via the {{ic|w}} command.<br />
* Format the new partitions with a [[File Systems|file system]].<br />
<br />
{{Note|<br />
* To boot from a GPT partitioned disk on a BIOS based system you have to create, preferably at the disk's beginning, a [[GRUB2#GUID Partition Table (GPT) specific instructions|BIOS boot partition]] with no filesystem and with the partition type as {{ic|BIOS boot}} or {{ic|bios_grub}} partition (''gdisk'' type code {{ic|EF02}}) for booting from the disk using [[GRUB]]. For [[Syslinux]], you do not need to create this {{ic|bios_grub}} partition, but you need to have separate {{ic|/boot}} partition and enable {{ic|Legacy BIOS Bootable partition}} attribute for that partition (using ''gdisk'').<br />
* [[GRUB Legacy]] does not support GPT, users must use [[BURG]], GRUB or Syslinux.<br />
}}<br />
{{Warning|If planning to dual boot with Windows in BIOS mode (this is the only available option for 32-bit Windows versions and 64-bit Windows XP), do '''not''' use GPT since Windows does '''not''' support booting from a GPT disk in BIOS systems. You will need to use MBR partitioning and boot in BIOS mode, as described below. This limitation does not apply if booting a modern 64-bit Windows version in UEFI mode.}}<br />
<br />
== Using MBR - legacy method ==<br />
<br />
Using MBR, the utility for editing the partition table is called ''fdisk''. Recent versions of ''fdisk'' have abandoned the deprecated system of using cylinders as the default display unit, as well as MS-DOS compatibility by default. The latest ''fdisk'' automatically aligns all partitions to 2048 sectors, or 1024 KiB, which should work for all EBS sizes that are known to be used by SSD manufacturers. This means that the default settings will give you proper alignment.<br />
<br />
Note that in the olden days, ''fdisk'' used cylinders as the default display unit, and retained an MS-DOS compatibility quirk that messed with SSD alignment. Therefore one will find many guides around the internet from around 2008-2009 making a big deal out of getting everything correct. With the latest ''fdisk'', things are much simpler, as reflected in this guide.<br />
<br />
=== Fdisk usage summary ===<br />
<br />
* Start ''fdisk'' against your drive as root (''disk-device'' may be e.g. {{ic|/dev/sda}}):<br />
# fdisk ''disk-device''<br />
* If the drive is brand new or if you are wanting to start over, create a new empty DOS partition table with the {{ic|o}} command.<br />
* Create a new partition with the {{ic|n}} command (primary type/1st partition).<br />
* Use the {{ic|+''x''G}} format to extend the partition ''x'' gibibytes. For example, if you want to create a 15GiB partition, you would enter {{ic|+15G}}<br />
* Change the partition's system id from the default type of Linux ({{ic|type 83}}) to the desired type via the {{ic|t}} command. This is an optional step should the user wish to create another type of partition for example, swap, NTFS, LVM, etc. Note that a complete listing of all valid partition types is available via the {{ic|l}} command.<br />
* Assign other partitions in a like fashion.<br />
* Write the table to disk and exit via the {{ic|w}} command.<br />
* Format the new partitions with a [[File Systems|file system]].<br />
<br />
== See also ==<br />
<br />
*[[Ext4#Creating ext4 partitions from scratch|Creating ext4 partitions from scratch]]<br />
*[[Wikipedia:Disk partitioning]]<br />
*[http://www.novell.com/coolsolutions/feature/19350.html Manually Partitioning Your Hard Drive with fdisk]</div>Geshhttps://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=248123Beginners' guide2013-02-21T22:59:43Z<p>Gesh: Noted temporary fix for bug #33923</p>
<hr />
<div><noinclude><br />
[[Category:Getting and installing Arch]]<br />
[[Category:About Arch]]<br />
[[da:Beginners' Guide/Installation]]<br />
[[es:Beginners' Guide/Installation]]<br />
[[hr:Beginners' Guide/Installation]]<br />
[[hu:Beginners' Guide/Installation]]<br />
[[it:Beginners' Guide/Installation]]<br />
[[ja:Beginners' Guide/Installation]]<br />
[[ko:Beginners' Guide/Installation]]<br />
[[nl:Beginners' Guide/Installatie]]<br />
[[pl:Beginners' Guide/Installation]]<br />
[[pt:Beginners' Guide/Installation]]<br />
[[ro:Ghidul începătorilor/Instalare]]<br />
[[ru:Beginners' Guide/Installation]]<br />
[[sr:Beginners' Guide/Installation]]<br />
[[zh-CN:Beginners' Guide/Installation]]<br />
{{Tip|This is part of a multi-page article for The Beginners' Guide. '''[[Beginners' Guide|Click here]]''' if you would rather read the guide in its entirety.}}<br />
</noinclude><br />
== Installation ==<br />
<br />
You are now presented with a shell prompt, automatically logged in as root.<br />
<br />
=== Change the language ===<br />
<br />
{{Tip|These are optional for the majority of users. Useful only if you plan on writing in your own language in any of the configuration files, if you use diacritical marks in the Wi-Fi password, or if you would like to receive system messages (e.g. possible errors) in your own language.}}<br />
<br />
By default, the keyboard layout is set to {{ic|us}}. If you have a non-[[Wikipedia:File:KB United States-NoAltGr.svg|US]] keyboard layout, run:<br />
<br />
# loadkeys ''layout''<br />
<br />
...where ''layout'' can be {{ic|fr}}, {{ic|uk}}, {{ic|be-latin1}}, etc. See [[KEYMAP#Keyboard layouts|here]] for a comprehensive list.<br />
<br />
The font should also be changed, because most languages use more glyphs than the 26 letter [[Wikipedia:English alphabet|English alphabet]]. Otherwise some foreign characters may show up as white squares or as other symbols. Note that the name is case-sensitive, so please type it ''exactly'' as you see it:<br />
<br />
# setfont Lat2-Terminus16<br />
<br />
By default, the language is set to English (US). If you would like to change the language for the install process ''(German, in this example)'', remove the {{ic|#}} in front of the [http://www.greendesktiny.com/support/knowledgebase_detail.php?ref=EUH-483 locale] you want from {{ic|/etc/locale.gen}}, along with English (US). Please choose the {{ic|UTF-8}} entry.<br />
<br />
Use {{Keypress|Ctrl+X}} to exit, and when prompted to save changes, press {{Keypress|Y}} and {{Keypress|Enter}} to use the same filename.<br />
<br />
{{hc|# nano /etc/locale.gen|<br />
en_US.UTF-8 UTF-8<br />
de_DE.UTF-8 UTF-8}}<br />
<br />
# locale-gen<br />
# export LANG=de_DE.UTF-8<br />
<br />
Remember, {{Keypress|LAlt+LShift}} activates and deactivates the keymap.<br />
<br />
=== Establish an internet connection ===<br />
<br />
{{Warning|udev no longer assigns network interface names according to the wlanX and ethX naming scheme. If you're coming from a different distribution or are reinstalling Arch and not aware of the new interface naming style, please do not assume that your wireless interface is named wlan0, or that your wired interface is named eth0. You can use the "ip" utility to discover the names of your interfaces.}}<br />
<br />
From systemd-197's release and onward, udev now assigns predictable, stable network interface names that deviate from the legacy incremental naming scheme (wlan0, wlan1, etc.). These interface names are guaranteed to be persistent across reboots, which solves the problem of the lack of predictability of network interface name assignment. For more information about why this was necessary, read http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames .<br />
<br />
The {{ic|dhcpcd}} network daemon is started automatically at boot and it will attempt to start a wired connection, if available. Try pinging a website to see if it was successful. And since Google is always on...<br />
<br />
{{hc|# ping -c 3 www.google.com|2=<br />
PING www.l.google.com (74.125.132.105) 56(84) bytes of data.<br />
64 bytes from wb-in-f105.1e100.net (74.125.132.105): icmp_req=1 ttl=50 time=17.0 ms<br />
64 bytes from wb-in-f105.1e100.net (74.125.132.105): icmp_req=2 ttl=50 time=18.2 ms<br />
64 bytes from wb-in-f105.1e100.net (74.125.132.105): icmp_req=3 ttl=50 time=16.6 ms<br />
<br />
--- www.l.google.com ping statistics ---<br />
3 packets transmitted, 3 received, 0% packet loss, time 2003ms<br />
rtt min/avg/max/mdev = 16.660/17.320/18.254/0.678 ms}}<br />
<br />
If you get a {{ic|ping: unknown host}} error, you will need to set up the network manually, as explained below.<br />
<br />
Otherwise, move on to [[#Prepare the storage drive|Prepare the storage drive]].<br />
<br />
==== Wired ====<br />
<br />
Follow this procedure if you need to set up a wired connection via a static IP address.<br />
<br />
First, identify the name of your ethernet interface. <br />
<br />
{{hc|# ip link|<br />
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT <br />
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00<br />
2: enp2s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000<br />
link/ether 00:11:25:31:69:20 brd ff:ff:ff:ff:ff:ff<br />
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT qlen 1000<br />
link/ether 01:02:03:04:05:06 brd ff:ff:ff:ff:ff:ff}}<br />
<br />
In this case, the ethernet interface is enp2s0f0. If you're unsure, your ethernet interface is likely to start with the letter "e", and unlikely to be "lo" or start with the letter "w". You can also use iwconfig and see which interfaces are not wireless:<br />
<br />
{{hc|# iwconfig|2=<br />
enp2s0f0 no wireless extensions.<br />
wlp3s0 IEEE 802.11bgn ESSID:"NETGEAR97" <br />
Mode:Managed Frequency:2.427 GHz Access Point: 2C:B0:5D:9C:72:BF <br />
Bit Rate=65 Mb/s Tx-Power=16 dBm <br />
Retry long limit:7 RTS thr:off Fragment thr:off<br />
Power Management:on<br />
Link Quality=61/70 Signal level=-49 dBm <br />
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0<br />
Tx excessive retries:0 Invalid misc:430 Missed beacon:0<br />
lo no wireless extensions.}}<br />
<br />
In this example, neither enp2s0f0 nor the loopback device have wireless extensions, meaning enp2s0f0 is our ethernet interface.<br />
<br />
You also need to know these settings:<br />
<br />
* Static IP address.<br />
* Subnet mask.<br />
* Gateway's IP address.<br />
* Name servers' (DNS) IP addresses.<br />
* Domain name (unless you're on a local LAN, in which case you can make it up).<br />
<br />
Activate the connected Ethernet interface (e.g. {{ic|enp2s0f0}}):<br />
<br />
# ip link set enp2s0f0 up<br />
<br />
Add the address:<br />
<br />
# ip addr add <ip address>/<subnetmask> dev <interface><br />
<br />
For example:<br />
<br />
# ip addr add 192.168.1.2/24 dev enp2s0f0<br />
<br />
For more options, run {{ic|man ip}}.<br />
<br />
Add your gateway like this, substituting your own gateway's IP address:<br />
<br />
# ip route add default via <ip address><br />
<br />
For example:<br />
<br />
# ip route add default via 192.168.1.1<br />
<br />
Edit {{ic|resolv.conf}}, substituting your name servers' IP addresses and your local domain name:<br />
<br />
{{hc|# nano /etc/resolv.conf|<br />
nameserver 61.23.173.5<br />
nameserver 61.95.849.8<br />
search example.com}}<br />
<br />
{{Note|Currently, you may include a maximum of 3 {{ic|nameserver}} lines.}}<br />
<br />
You should now have a working network connection. If you do not, check the detailed [[Network Configuration]] page.<br />
<br />
==== Wireless ====<br />
<br />
Follow this procedure if you need wireless connectivity (Wi-Fi) during the installation process.<br />
<br />
If you're coming from another distribution, or if this is your first time installing Arch Linux since the deprecation of the old interface naming scheme, you might be surprised to learn that the first wireless interface is not named "wlan0". In fact, none of the interfaces are automatically prefixed with "wlan" any longer. Don't panic; simply execute {{ic|iwconfig}} to discover the name of your wireless interface.<br />
<br />
The wireless drivers and utilities are now available to you in the live environment of the installation media. A good knowledge of your wireless hardware will be of key importance to successful configuration. Note that the following quick-start procedure ''executed at this point in the installation'' will initialize your wireless hardware for use ''in the live environment of the installation media''. These steps (or some other form of wireless management) '''must be repeated from the actual installed system after booting into it'''.<br />
<br />
Also note that these steps are optional if wireless connectivity is unnecessary at this point in the installation; wireless functionality may always be established later.<br />
<br />
{{Note|The following examples use {{ic|wlp3s0}} for the interface and {{ic|linksys}} for the ESSID. Remember to change these values according to your setup.}}<br />
<br />
The basic procedure will be:<br />
<br />
* Identify the wireless interface:<br />
<br />
# lspci | grep -i net<br />
<br />
Or, if using a USB adapter:<br />
<br />
# lsusb<br />
<br />
* Ensure udev has loaded the driver, and that the driver has created a usable wireless kernel interface with {{ic|iwconfig}}:<br />
<br />
{{Note|If you do not see output similar to this, then your wireless driver has not been loaded. If this is the case, you must load the driver yourself. Please see [[Wireless Setup]] for more detailed information.}}<br />
<br />
{{hc|# iwconfig|2=<br />
enp2s0f0 no wireless extensions.<br />
wlp3s0 IEEE 802.11bgn ESSID:"NETGEAR97" <br />
Mode:Managed Frequency:2.427 GHz Access Point: 2C:B0:5D:9C:72:BF <br />
Bit Rate=65 Mb/s Tx-Power=16 dBm <br />
Retry long limit:7 RTS thr:off Fragment thr:off<br />
Power Management:on<br />
Link Quality=61/70 Signal level=-49 dBm <br />
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0<br />
Tx excessive retries:0 Invalid misc:430 Missed beacon:0<br />
lo no wireless extensions.}}<br />
<br />
In this example, {{ic|wlp3s0}} is the available wireless interface.<br />
<br />
* Bring the interface up with:<br />
<br />
# ip link set wlp3s0 up<br />
<br />
A small percentage of wireless chipsets also require firmware, in addition to a corresponding driver. If the wireless chipset requires firmware, you are likely to receive this error when bringing the interface up:<br />
<br />
{{hc|# ip link set wlp3s0 up|<br />
SIOCSIFFLAGS: No such file or directory}}<br />
<br />
If unsure, invoke {{ic|dmesg}} to query the kernel log for a firmware request from the wireless chipset.<br />
<br />
Example output from an Intel chipset which requires and has requested firmware from the kernel at boot:<br />
<br />
{{hc|# dmesg <nowiki>|</nowiki> grep firmware|<br />
firmware: requesting iwlwifi-5000-1.ucode}}<br />
<br />
If there is no output, it may be concluded that the system's wireless chipset does not require firmware.<br />
<br />
{{Warning|Wireless chipset firmware packages (for cards which require them) are pre-installed under {{ic|/usr/lib/firmware}} in the live environment (on CD/USB stick) '''but must be explicitly installed to your actual system to provide wireless functionality after you reboot into it!''' Package installation is covered later in this guide. Ensure installation of both your wireless module and firmware before rebooting! See [[Wireless Setup]] if you are unsure about the requirement of corresponding firmware installation for your particular chipset.}}<br />
<br />
Next, use {{Pkg|netcfg}}'s {{ic|wifi-menu}} to connect to a network:<br />
<br />
# wifi-menu wlp3s0<br />
<br />
{{Warning|At the moment, netcfg's wifi-menu, when executed without arguments, will look for "wlan0". Execute wifi-menu with your interface as the argument in order to use it.}}<br />
<br />
You should now have a working network connection. If you do not, check the detailed [[Wireless Setup]] page.<br />
<br />
==== xDSL (PPPoE), analog modem or ISDN ====<br />
<br />
If you have a router in bridge mode, run:<br />
<br />
# pppoe-setup<br />
<br />
* Type in the username that the ISP provided you with.<br />
* Press {{Keypress|Enter}} for "eth0".<br />
* Press {{Keypress|Enter}} for "no", so that it stays up continuously.<br />
* Type {{ic|server}} (since this is usually the case).<br />
* Press {{Keypress|1}} for a firewall.<br />
* Type in the password that the ISP provided you with.<br />
* Press {{Keypress|Y}} at the end.<br />
<br />
To use these settings and connect to your ISP, run:<br />
<br />
# pppoe-start<br />
<br />
You may also need to adjust your {{ic|resolv.conf}}:<br />
<br />
# echo nameserver 8.8.8.8 > /etc/resolv.conf<br />
<br />
If you have a dial-up or ISDN connection, see [[Direct Modem Connection]].<br />
<br />
==== Behind a proxy server ====<br />
<br />
If you are behind a proxy server, you will need to export the {{ic|http_proxy}} and {{ic|ftp_proxy}} environment variables. See [[Proxy settings]] for more information.<br />
<br />
=== Prepare the storage drive ===<br />
<br />
{{Warning|Partitioning can destroy data. You are '''strongly''' cautioned and advised to backup any critical data before proceeding.}}<br />
<br />
Absolute beginners are encouraged to use a graphical partitioning tool. [http://gparted.sourceforge.net/download.php GParted] is a good example, and is [http://gparted.sourceforge.net/livecd.php provided as a "live" CD]. It is also included on live CDs of most Linux distributions such as [[Wikipedia:Ubuntu (operating system)|Ubuntu]] and [[Wikipedia:Linux Mint|Linux Mint]]. A drive should first be [[partitioning|partitioned]] and the partitions should be formatted with a [[File Systems|file system]] before rebooting.<br />
<br />
It's possible to set up a swap file at any point after installation, so there is no need to decide on swap size now. See [[Swap]] for details if you wish to set up a swap partition now (but note that it's much easier to resize a file than a partition).<br />
<br />
If you have already done so, proceed to [[#Mount the partitions|Mount the partitions]].<br />
<br />
Otherwise, see the following example.<br />
<br />
==== Example ====<br />
<br />
The Arch Linux install media includes the following partitioning tools: {{ic|fdisk}}, {{ic|gdisk}}, {{ic|cfdisk}}, {{ic|cgdisk}}, {{ic|parted}}.<br />
<br />
{{Box BLUE|Notes regarding [[UEFI]] boot:|<br />
* If you have a UEFI motherboard, you will need to create an extra [[Unified Extensible Firmware Interface#Create an UEFI System Partition_in_Linux|UEFI System partition]].<br />
* It is recommended to always use GPT for UEFI boot, as some UEFI firmwares do not allow UEFI-MBR boot.}}<br />
<br />
{{Box BLUE|Notes regarding [[GPT]] partitioning:|<br />
* If you are not dual booting with Windows, then it is advisable to use GPT instead of MBR. Read [[GPT]] for a list of advantages.<br />
* If you have a BIOS motherboard (or plan on booting in BIOS compatibility mode) and you want to setup GRUB on a GPT-partitioned drive, you will need to create a 1007 KiB "[[GRUB#GPT specific instructions|BIOS Boot Partition]]". Syslinux doesn't need one.<br />
* Some BIOS systems may have issues with GPT. See http://mjg59.dreamwidth.org/8035.html and http://rodsbooks.com/gdisk/bios.html for more info and possible workarounds.}}<br />
<br />
{{Note|If you are installing to a USB flash key, see [[Installing Arch Linux on a USB key]].}}<br />
<br />
The example system will contain a 15 GB root partition, and a [[Partitioning#/home|home]] partition for the remaining space. Choose either [[MBR]] or [[GPT]]. Do not choose both!<br />
<br />
It should be emphasized that partitioning is a personal choice and that this example is only for illustrative purposes. See [[Partitioning]].<br />
<br />
{| class="wikitable"<br />
|-<br />
| rowspan="2" | '''MBR'''<br />
| rowspan="2"| {{ic|cfdisk&nbsp;/dev/sda}}<br />
| '''Root:'''<br />
<br />
* Choose New (or press {{Keypress|N}}) – {{Keypress|Enter}} for Primary – type in "15360" – {{Keypress|Enter}} for Beginning – {{Keypress|Enter}} for Bootable.<br />
|-<br />
|<br />
'''Home:'''<br />
<br />
* Press the down arrow to move to the free space area.<br />
* Choose New (or press {{Keypress|N}}) – {{Keypress|Enter}} for Primary – {{Keypress|Enter}} to use the rest of the drive (or you could type in the desired size).<br />
|-<br />
| rowspan="2" | '''GPT'''<br />
| rowspan="2"| {{ic|cgdisk&nbsp;/dev/sda}}<br />
| '''Root:'''<br />
<br />
* Choose New (or press {{Keypress|N}}) – {{Keypress|Enter}} for the first sector (2048) – type in "15360M" – {{Keypress|Enter}} for the default hex code (8300) – {{Keypress|Enter}} for a blank partition name.<br />
|-<br />
| '''Home:'''<br />
<br />
* Press the down arrow a couple of times to move to the larger free space area.<br />
* Choose New (or press {{Keypress|N}}) – {{Keypress|Enter}} for the first sector – {{Keypress|Enter}} to use the rest of the drive (or you could type in the desired size; for example "30G") – {{Keypress|Enter}} for the default hex code (8300) – {{Keypress|Enter}} for a blank partition name.<br />
|}<br />
<br />
If you chose MBR, here's how it should look like:<br />
<br />
Name Flags Part Type FS Type [Label] Size (MB)<br />
-----------------------------------------------------------------------<br />
sda1 Boot Primary Linux 15360<br />
sda2 Primary Linux 133000*<br />
<br />
If you chose GPT, here's how it should look like: <br />
<br />
Part. # Size Partition Type Partition Name<br />
----------------------------------------------------------------<br />
1007.0 KiB free space<br />
1 15.0 GiB Linux filesystem<br />
2 123.45 GiB Linux filesystem<br />
<br />
Double check and make sure that you are happy with the partition sizes as well as the partition table layout before continuing.<br />
<br />
If you would like to start over, you can simply select Quit (or press {{Keypress|Q}}) to exit without saving changes and then restart cfdisk (or cgdisk).<br />
<br />
If you are satisfied, choose Write (or press {{Keypress|Shift+W}}) to finalize and to write the partition table to the drive. Type "yes" and choose Quit (or press {{Keypress|Q}}) to exit without making any more changes.<br />
<br />
Simply partitioning is not enough; the partitions also need a [[File Systems|filesystem]]. To format the partitions with an ext4 filesystem:<br />
<br />
{{Warning|Double check and triple check that it's actually {{ic|/dev/sda1}} and {{ic|/dev/sda2}} that you want to format.}}<br />
<br />
# mkfs.ext4 /dev/sda1<br />
# mkfs.ext4 /dev/sda2<br />
<br />
If you have made a partition dedicated to swap (code 82), don't forget to format and activate it with:<br />
<br />
# mkswap /dev/sda''X''<br />
# swapon /dev/sda''X''<br />
<br />
=== Mount the partitions ===<br />
<br />
Each partition is identified with a number suffix. For example, {{ic|sda1}} specifies the first partition of the first drive, while {{ic|sda}} designates the entire drive.<br />
<br />
To display the current partition layout:<br />
<br />
# lsblk /dev/sda<br />
<br />
{{Note|Do not mount more than one partition to the same directory. And pay attention, because the mounting order is important.}}<br />
<br />
First, mount the root partition on {{ic|/mnt}}. Following the example when using {{ic|cfdisk}} above (yours may be different), it would be:<br />
<br />
# mount /dev/sda1 /mnt<br />
<br />
Then mount the home partition and any other separate partition ({{ic|/boot}}, {{ic|/var}}, etc), if you have any:<br />
<br />
# mkdir /mnt/home<br />
# mount /dev/sda2 /mnt/home<br />
<br />
In case you have a UEFI motherboard, mount the UEFI partition:<br />
<br />
# mkdir -p /mnt/boot/efi<br />
# mount /dev/sda''X'' /mnt/boot/efi<br />
<br />
=== Select a mirror ===<br />
<br />
Before installing, you may want to edit the {{ic|mirrorlist}} file and place your preferred mirror first. A copy of this file will be installed on your new system by {{ic|pacstrap}} as well, so it's worth getting it right.<br />
<br />
{{hc|# nano /etc/pacman.d/mirrorlist|<br />
##<br />
## Arch Linux repository mirrorlist<br />
## Sorted by mirror score from mirror status page<br />
## Generated on 2012-MM-DD<br />
##<br />
<br />
<nowiki>Server = http://mirror.example.xyz/archlinux/$repo/os/$arch</nowiki><br />
...}}<br />
<br />
* {{Keypress|Alt+6}} to copy a {{ic|Server}} line.<br />
* {{Keypress|PageUp}} key to scroll up.<br />
* {{Keypress|Ctrl+U}} to paste it at the top of the list.<br />
* {{Keypress|Ctrl+X}} to exit, and when prompted to save changes, press {{Keypress|Y}} and {{Keypress|Enter}} to use the same filename.<br />
<br />
If you want, you can make it the ''only'' mirror available by getting rid of everything else (using {{Keypress|Ctrl+K}}), but it's usually a good idea to have a few more, in case the first one goes offline.<br />
<br />
{{Tip|<br />
* Use the [https://www.archlinux.org/mirrorlist/ Mirrorlist Generator] to get an updated list for your country. HTTP mirrors are faster than FTP, because of something called [[Wikipedia:Keepalive|keepalive]]. With FTP, pacman has to send out a signal each time it downloads a package, resulting in a brief pause. For other ways to generate a mirror list, see [[Mirrors#Sorting mirrors|Sorting mirrors]] and [[Reflector]].<br />
* [https://archlinux.org/mirrors/status/ Arch Linux MirrorStatus] reports various aspects about the mirrors such as network problems with mirrors, data collection problems, the last time mirrors have been synced, etc.}}<br />
<br />
{{Note|<br />
* Whenever in the future you change your list of mirrors, always remember to force pacman to refresh all package lists with {{ic|pacman -Syy}}. This is considered to be good practice and will avoid possible headaches. See [[Mirrors]] for more information.<br />
* If you're using an older installation medium, your mirrorlist might be outdated, which might lead to problems when updating Arch Linux (see {{Bug|22510}}). Therefore it is advised to obtain the latest mirror information as described above.<br />
* Some issues have been reported in the [https://bbs.archlinux.org/ Arch Linux forums] regarding network problems that prevent pacman from updating/synchronizing repositories (see [https://bbs.archlinux.org/viewtopic.php?id&#61;68944] and [https://bbs.archlinux.org/viewtopic.php?id&#61;65728]). When installing Arch Linux natively, these issues have been resolved by replacing the default pacman file downloader with an alternative (see [[Improve Pacman Performance]] for more details). When installing Arch Linux as a guest OS in [[VirtualBox]], this issue has also been addressed by using "Host interface" instead of "NAT" in the machine properties.}}<br />
<br />
=== Install the base system ===<br />
<br />
The base system is installed using the [https://github.com/falconindy/arch-install-scripts/blob/master/pacstrap.in pacstrap] script.<br />
<br />
The {{ic|-i}} switch can be omitted if you wish to install every package from the ''base'' and ''base-devel'' groups without prompting.<br />
<br />
# pacstrap -i /mnt base base-devel<br />
<br />
{{Note|If pacman fails to verify your packages, check the system time with {{ic|cal}}. If the system date is invalid (e.g. it shows year 2010), signing keys will be considered expired (or invalid), signature checks on packages will fail and installation will be interrupted. Make sure to correct the system time, either by doing so manually or with the {{Pkg|ntp}} client, and retry running the pacstrap command. Refer to [[Time]] page for more information on correcting system time.}}<br />
<br />
{{Note| If pacman complains about invalid signatures during the pacstrap phase (''error: failed to commit transaction (invalid or corrupted package)'') run the following command below.}}<br />
# pacman-key --init && pacman-key --populate archlinux <br />
<br />
* {{Grp|base}}: Software packages from the [core] repo to provide the minimal base environment.<br />
<br />
* {{Grp|base-devel}}: Extra tools from [core] such as {{ic|make}}, and {{ic|automake}}. Most beginners should choose to install it, as it will likely be needed to expand the system. The ''base-devel'' group will be required to install software from the [[Arch User Repository]].<br />
<br />
This will give you a basic Arch system. Other packages can be installed later using [[pacman]].<br />
<br />
=== Generate an fstab ===<br />
<br />
Generate an [[fstab]] file with the following command. UUIDs will be used because they have certain advantages (see [[fstab#Identifying filesystems]]). If you would prefer to use labels instead, replace the {{ic|-U}} option with {{ic|-L}}.<br />
<br />
{{Note|If you encounter errors running genfstab or later in the install process, do '''not''' run genfstab again; just edit the fstab file.}}<br />
<br />
# genfstab -U -p /mnt >> /mnt/etc/fstab<br />
# nano /mnt/etc/fstab<br />
<br />
{{Warning|The fstab file should always be checked after generating it. If you made an EFI system partition earlier, then {{ic|genfstab}} has incorrectly added options to your EFI system partition. This will in fact ''prevent'' your computer from booting from that drive, so you need to remove all options for the EFI partition except for {{ic|noatime}}. For the other partitions that use it, be sure to replace {{ic|1="codepage=cp437"}} with {{ic|1="codepage=437"}} or else when you next reboot, any mounts with this option will fail and systemd will halt and drop into recovery mode. This should be fixed by linux 3.8}}<br />
<br />
A few considerations:<br />
<br />
* Only the root ({{ic|/}}) partition needs {{ic|1}} for the last field. Everything else should have either {{ic|2}} or {{ic|0}} (see [[fstab#Field definitions]]).<br />
<br />
=== Chroot and configure the base system ===<br />
<br />
Next, we [[chroot]] into our newly installed system:<br />
<br />
# arch-chroot /mnt<br />
<br />
{{Note|Use {{ic|arch-chroot /mnt /bin/bash}} to chroot into a bash shell.}}<br />
At this stage of the installation, you will configure the primary configuration files of your Arch Linux base system. These can either be created if they do not exist, or edited if you wish to change the defaults.<br />
<br />
Closely following and understanding these steps is of key importance to ensure a properly configured system.<br />
<br />
==== Locale ====<br />
<br />
Locales are used by '''glibc''' and other locale-aware programs or libraries for rendering text, correctly displaying regional monetary values, time and date formats, alphabetic idiosyncrasies, and other locale-specific standards.<br />
<br />
There are two files that need editing: {{ic|locale.gen}} and {{ic|locale.conf}}.<br />
<br />
* The {{ic|locale.gen}} file is empty by default (everything is commented out) and you need to remove the {{ic|#}} in front of the line(s) you want. You may uncomment more lines than just English (US), as long as you choose their {{ic|UTF-8}} encoding:<br />
<br />
{{hc|# nano /etc/locale.gen|<br />
en_US.UTF-8 UTF-8<br />
de_DE.UTF-8 UTF-8}}<br />
<br />
# locale-gen<br />
<br />
This will run on every '''glibc''' upgrade, generating all the locales specified in {{ic|/etc/locale.gen}}.<br />
<br />
* The {{ic|locale.conf}} file doesn't exist by default. Setting only {{ic|LANG}} should be enough. It will act as the default value for all other variables.<br />
<br />
# echo LANG=en_US.UTF-8 > /etc/locale.conf<br />
# export LANG=en_US.UTF-8<br />
<br />
{{Note|If you set some other language than English at the beginning of the install, the above commands would be something like:<br />
# echo LANG<nowiki>=</nowiki>de_DE.UTF-8 > /etc/locale.conf<br />
# export LANG<nowiki>=</nowiki>de_DE.UTF-8<br />
}}<br />
<br />
To use other {{ic|LC_*}} variables, first run {{ic|locale}} to see the available options. An advanced example can be found [[Locale#Setting_system-wide_locale|here]].<br />
<br />
{{Warning|Using the {{ic|LC_ALL}} variable is strongly discouraged because it overrides everything.}}<br />
<br />
==== Console font and keymap ====<br />
<br />
If you set a keymap at [[#Change_the_language|the beginning]] of the install process, load it now, as well, because the environment has changed. For example:<br />
<br />
# loadkeys ''de-latin1''<br />
# setfont Lat2-Terminus16<br />
<br />
To make them available after reboot, edit {{ic|vconsole.conf}}:<br />
<br />
{{hc|# nano /etc/vconsole.conf|2=<br />
KEYMAP=de-latin1<br />
FONT=Lat2-Terminus16<br />
}}<br />
<br />
* {{ic|KEYMAP}} – Please note that this setting is only valid for your TTYs, not any graphical window managers or Xorg.<br />
<br />
* {{ic|FONT}} – Available alternate console fonts reside in {{ic|/usr/share/kbd/consolefonts/}}. The default (blank) is safe, but some foreign characters may show up as white squares or as other symbols. It's recommended that you change it to {{ic|Lat2-Terminus16}}, because according to {{ic|/usr/share/kbd/consolefonts/README.Lat2-Terminus16}}, it claims to support "about 110 language sets".<br />
<br />
* Possible option {{ic|FONT_MAP}} – Defines the console map to load at boot. Read {{ic|man setfont}}. Removing it or leaving it blank is safe.<br />
<br />
See [[Fonts#Console_fonts|Console fonts]] and {{ic|man vconsole.conf}} for more information.<br />
<br />
==== Time zone ====<br />
<br />
Available time zones and subzones can be found in the {{ic|/usr/share/zoneinfo/<Zone>/<SubZone>}} directories.<br />
<br />
To view the available <Zone>, check the directory {{ic|/usr/share/zoneinfo/}}:<br />
<br />
# ls /usr/share/zoneinfo/<br />
<br />
Similarly, you can check the contents of directories belonging to a <SubZone>:<br />
<br />
# ls /usr/share/zoneinfo/Europe<br />
<br />
Create a symbolic link {{ic|/etc/localtime}} to your zone file {{ic|/usr/share/zoneinfo/<Zone>/<SubZone>}} using this command:<br />
<br />
# ln -s /usr/share/zoneinfo/<Zone>/<SubZone> /etc/localtime<br />
<br />
'''Example:'''<br />
<br />
# ln -s /usr/share/zoneinfo/Europe/Minsk /etc/localtime<br />
<br />
==== Hardware clock ====<br />
<br />
Set the hardware clock mode uniformly between your operating systems. Otherwise, they may overwrite the hardware clock and cause time shifts.<br />
<br />
You can generate {{ic|/etc/adjtime}} automatically by using one of the following commands:<br />
<br />
* '''UTC''' (recommended)<br />
<br />
: {{Note|Using [[Wikipedia:Coordinated Universal Time|UTC]] for the hardware clock does not mean that software will display time in UTC.}}<br />
<br />
: {{bc|# hwclock --systohc --utc}}<br />
<br />
To synchronize your "UTC" time over the internet, see [[Network Time Protocol daemon|NTPd]].<br />
<br />
* '''localtime''' (discouraged; used by default in Windows)<br />
<br />
: {{Warning|Using ''localtime'' may lead to several known and unfixable bugs. However, there are no plans to drop support for ''localtime''.}}<br />
<br />
: {{bc|# hwclock --systohc --localtime}}<br />
<br />
If you have (or planning on having) a dual boot setup with Windows:<br />
<br />
* Recommended: Set both Arch Linux and Windows to use UTC. A quick [[Time#UTC in Windows|registry fix]] is needed. Also, be sure to prevent Windows from synchronizing the time on-line, because the hardware clock will default back to ''localtime''. <br />
<br />
* Not recommended: Set Arch Linux to ''localtime'' and disable any time-related services, like [[Network Time Protocol daemon|NTPd]] . This will let Windows take care of hardware clock corrections and you will need to remember to boot into Windows at least two times a year (in Spring and Autumn) when [[Wikipedia:Daylight saving time|DST]] kicks in. So please don't ask on the forums why the clock is one hour behind or ahead if you usually go for days or weeks without booting into Windows.<br />
<br />
==== Kernel modules ====<br />
<br />
{{Tip|This is just an example, you do not need to set it. All needed modules are automatically loaded by udev, so you will rarely need to add something here. Only add modules that you know are missing.}}<br />
<br />
For kernel modules to load during boot, place a {{ic|*.conf}} file in {{ic|/etc/modules-load.d/}}, with a name based on the program that uses them.<br />
<br />
{{hc|# nano /etc/modules-load.d/virtio-net.conf|<br />
# Load 'virtio-net.ko' at boot.<br />
<br />
virtio-net}}<br />
<br />
If there are more modules to load per {{ic|*.conf}}, the module names can be separated by newlines. A good example are the [[VirtualBox#Arch Linux guests|VirtualBox Guest Additions]].<br />
<br />
Empty lines and lines starting with {{ic|#}} or {{ic|;}} are ignored.<br />
<br />
==== Hostname ====<br />
<br />
Set the [[Wikipedia:hostname|hostname]] to your liking (e.g. ''arch''):<br />
<br />
# echo ''myhostname'' > /etc/hostname<br />
<br />
{{Note|There is no need to edit {{ic|/etc/hosts}}.}}<br />
<br />
=== Configure the network ===<br />
<br />
You need to configure the network again, but this time for your newly installed environment. The procedure and prerequisites are very similar to the one described [[#Establish an internet connection|above]], except we are going to make it persistent and automatically run at boot.<br />
<br />
{{Note|For more in-depth information on network configration, visit [[Network Configuration]] and [[Wireless Setup]].}}<br />
<br />
==== Wired ====<br />
<br />
; Dynamic IP<br />
<br />
{{Warning|A bug has been noted in the install ISO, in which the name your interface has during installation differs from the one it will have upon reboot. See [https://bugs.archlinux.org/task/33923 Bug #33923] for more details.<br />
Until this bug is fixed, you can use the following script to find the name your interface will have after boot:<br />
for i in /sys/class/net/*; do<br />
echo "&#61;&#61;$i"<br />
udevadm test-builtin net_id "$i";<br />
echo<br />
done 2>/dev/null<br />
}}<br />
<br />
If you only use a single fixed wired network connection, you do not need a network management service and can simply enable and start the {{ic|dhcpcd}} service. Where <interface> is your wired interface:<br />
# systemctl enable dhcpcd@<interface>.service<br />
# systemctl start dhcpcd<br />
<br />
Alternatively, you can use {{Pkg|netcfg}}'s {{ic|net-auto-wired}}, which gracefully handles dynamic connections to new networks:<br />
<br />
Install {{Pkg|ifplugd}}, which is required for {{ic|net-auto-wired}}:<br />
# pacman -S ifplugd<br />
<br />
Edit {{ic|/etc/conf.d/netcfg}} and modify the network interface name, most likely it is not eth0. You can find out more about the naming in the warning above.<br />
{{hc|nano /etc/conf.d/netcfg|2=<br />
WIRED_INTERFACE="<interface>"}}<br />
<br />
Enable and start the {{ic|net-auto-wired}} service.<br />
# systemctl enable net-auto-wired.service<br />
# systemctl start dhcpcd<br />
<br />
; Static IP<br />
<br />
Copy a sample profile from {{ic|/etc/network.d/examples}} to {{ic|/etc/network.d}}:<br />
# cd /etc/network.d<br />
# cp examples/ethernet-static .<br />
<br />
Edit the profile as needed (modify {{ic|INTERFACE}}, {{ic|ADDR}}, {{ic|GATEWAY}} and {{ic|DNS}}):<br />
# nano ethernet-static<br />
<br />
Edit {{ic|/etc/conf.d/netcfg}} and add the new network profile to the {{ic|NETWORKS}} array:<br />
{{hc|nano /etc/conf.d/netcfg|<br />
2=NETWORKS=(ethernet-static)}}<br />
<br />
Enable the {{ic|netcfg}} service:<br />
# systemctl enable netcfg.service<br />
<br />
==== Wireless ====<br />
<br />
You will need to install additional programs to be able to configure and manage wireless network profiles for [[netcfg]].<br />
<br />
[[NetworkManager]] and [[Wicd]] are other popular alternatives.<br />
<br />
* Install the required packages:<br />
<br />
# pacman -S wireless_tools wpa_supplicant wpa_actiond dialog<br />
<br />
If your wireless adapter requires a firmware (as described in the above [[#Wireless|Establish an internet connection]] section and also [[Wireless Setup#Drivers and firmware|here]]), install the package containing your firmware. For example:<br />
<br />
# pacman -S zd1211-firmware<br />
<br />
* After finishing the rest of this installation and rebooting, you can connect to the network with {{ic|wifi-menu <interface>}} (where {{ic|<interface>}} is the interface of your wireless chipset), which will generate a profile file in {{ic|/etc/network.d}} named after the SSID. There are also templates available in {{ic|/etc/network.d/examples/}} for manual configuration.<br />
<br />
# wifi-menu <interface><br />
<br />
{{Warning|If you're using {{ic|wifi-menu}}, this must be done *after* your reboot when you're no longer chrooted. The process spawned by this command will conflict with the one you have running outside of the chroot. Alternatively, you could just configure a network profile manually using the templates previously mentioned so that you don't have to worry about using {{ic|wifi-menu}} at all.}}<br />
<br />
* Enable the {{ic|net-auto-wireless}} service, which will connect to known networks and gracefully handle roaming and disconnects:<br />
<br />
# systemctl enable net-auto-wireless.service<br />
<br />
{{Note|[[Netcfg]] also provides {{ic|net-auto-wired}}, which can be used in conjunction with {{ic|net-auto-wireless}}.}}<br />
<br />
* Make sure that the correct wireless interface (e.g. {{ic|wlp3s0}}) is set in {{ic|/etc/conf.d/netcfg}}:<br />
<br />
{{hc|# nano /etc/conf.d/netcfg|2=<br />
WIRELESS_INTERFACE="wlp3s0"}}<br />
<br />
It is also possible to define a list of network profiles that should be automatically connected, using the {{ic|AUTO_PROFILES}} variable in {{ic|/etc/conf.d/netcfg}}. If {{ic|AUTO_PROFILES}} is not set, all known wireless networks will be tried.<br />
<br />
==== xDSL (PPPoE), analog modem or ISDN ====<br />
<br />
For xDSL, dial-up and ISDN connections, see [[Direct Modem Connection]].<br />
<br />
=== Configure pacman ===<br />
<br />
Pacman is the Arch Linux '''pac'''kage '''man'''ager. It is highly recommended to study and learn how to use it. Read {{ic|man pacman}}, have a look at the [[pacman]] and [[Pacman - An Introduction]] articles, or check out the [[Pacman Rosetta]] article for a comparison to other popular package managers.<br />
<br />
For repository selections and pacman options, edit {{ic|pacman.conf}}:<br />
# nano /etc/pacman.conf<br />
<br />
Most people will want to use {{ic|[core]}}, {{ic|[extra]}} and {{ic|[community]}}.<br />
<br />
If you installed Arch Linux x86_64, it's recommended that you enable the {{ic|[multilib]}} repository, as well (to be able to run both 32 bit and 64 bit applications):<br />
<br />
{{Note|When choosing repos, be sure to uncomment both the {{ic|[''repo_name'']}} header lines, as well as the lines below. Failure to do so will result in the selected repository being omitted! This is a very common error. A correct example for the multilib repository is found below.}}<br />
<br />
[multilib]<br />
SigLevel = PackageRequired<br />
Include = /etc/pacman.d/mirrorlist<br />
<br />
You will then need to update the package list by running {{ic|pacman}} with the {{ic|-Sy}} switch. Failing to do so will generate "warning: database file for 'multilib' does not exist" error when next using pacman.<br />
<br />
See [[Official Repositories]] for more information, including details about the purpose of each repository.<br />
<br />
For software unavailable directly through pacman, see [[Arch User Repository]].<br />
<br />
=== Create an initial ramdisk environment ===<br />
<br />
{{Tip|Most users can skip this step and use the defaults provided in {{ic|mkinitcpio.conf}}. The initramfs image (from the {{ic|/boot}} folder) has already been generated based on this file when the {{Pkg|linux}} package (the Linux kernel) was installed earlier with {{ic|pacstrap}}.}}<br />
<br />
Here you need to set the right [[Mkinitcpio#HOOKS|hooks]] if the root is on a USB drive, if you use RAID, LVM, or if {{ic|/usr}} is on a separate partition.<br />
<br />
Edit {{ic|/etc/mkinitcpio.conf}} as needed and re-generate the initramfs image with:<br />
<br />
# mkinitcpio -p linux<br />
<br />
{{Note|Arch VPS installations on QEMU (e.g. when using {{ic|virt-manager}}) may need {{ic|virtio}} modules in {{ic|mkinitcpio.conf}} to be able to boot.<br />
<br />
{{hc|# nano /etc/mkinitcpio.conf|2=<br />
MODULES="virtio virtio_blk virtio_pci virtio_net"}}}}<br />
<br />
=== Set the root password and add a regular user ===<br />
<br />
Set the root password with:<br />
<br />
# passwd<br />
<br />
{{Warning|Linux is a multi-user operating system. You should not perform everyday tasks using the root account. It is considered a very poor practice and could be extremely dangerous. The root account should only be used for administrative tasks.}}<br />
<br />
Then add a normal user account. The user ''archie'' is just an example.<br />
<br />
# useradd -m -g users -G wheel -s /bin/bash ''archie''<br />
# passwd ''archie''<br />
<br />
If you wish to start over, use {{ic|userdel}}. The {{ic|-r}} option will remove the user's home directory and its content, along with the user's settings (the so-called "dot" files).<br />
<br />
# userdel -r ''archie''<br />
<br />
For more information, read [[Users and Groups]].<br />
<br />
=== Install and configure a bootloader ===<br />
<br />
==== For BIOS motherboards ====<br />
<br />
For BIOS systems, there are three bootloaders - Syslinux, GRUB, and [[LILO]]. Choose the bootloader as per your convenience. Below only Syslinux and GRUB are explained. <br />
<br />
* Syslinux is (currently) limited to loading only files from the partition where it was installed. Its configuration file is considered to be easier to understand. An example configuration can be found [https://bbs.archlinux.org/viewtopic.php?pid=1109328#p1109328 here].<br />
<br />
* GRUB is more feature-rich and supports more complex scenarios. Its configuration file(s) is more similar to a scripting language, which may be difficult for beginners to manually write. It is recommended that they automatically generate one.<br />
<br />
{{Note|Some BIOS systems may have issues with GPT. See http://mjg59.dreamwidth.org/8035.html and http://rodsbooks.com/gdisk/bios.html for more info and possible workarounds.}}<br />
<br />
===== Syslinux =====<br />
<br />
Install the {{Pkg|syslinux}} package and then use the {{ic|syslinux-install_update}} script to automatically ''install'' the files ({{ic|-i}}), mark the partition ''active'' by setting the boot flag ({{ic|-a}}), and install the ''MBR'' boot code ({{ic|-m}}):<br />
<br />
{{Note|If you have partitioned the drive as GPT, install {{Pkg|gptfdisk}} package, as well ({{ic|pacman -S gptfdisk}}), because it contains {{ic|sgdisk}}, which will be used to set the GPT-specific boot flag.}}<br />
<br />
# pacman -S syslinux<br />
# syslinux-install_update -i -a -m<br />
<br />
Configure {{ic|syslinux.cfg}} to point to the right root partition. This step is vital. If it points to the wrong partition, Arch Linux will not boot. Change {{ic|/dev/sda3}} to reflect your root partition ''(if you partitioned your drive as in [[#Prepare the storage drive|the example]], your root partition is sda1)''. Do the same for the fallback entry.<br />
<br />
{{hc|# nano /boot/syslinux/syslinux.cfg|2=<br />
...<br />
LABEL arch<br />
...<br />
APPEND root=/dev/sda3 ro<br />
...}}<br />
<br />
For more information on configuring and using Syslinux, see [[Syslinux]].<br />
<br />
===== GRUB =====<br />
<br />
Install the {{Pkg|grub-bios}} package and then run {{ic|grub-install}}:<br />
<br />
{{Note|Change {{ic|/dev/sda}} to reflect the drive you installed Arch on. Do not append a partition number (do not use {{ic|sda''X''}}).}}<br />
<br />
{{Note|For GPT-partitioned drives on BIOS motherboards, GRUB needs a "[[GRUB#GPT specific instructions|BIOS Boot Partition]]".}}<br />
<br />
# pacman -S grub-bios<br />
# grub-install --target=i386-pc --recheck /dev/sda<br />
# cp /usr/share/locale/en\@quot/LC_MESSAGES/grub.mo /boot/grub/locale/en.mo<br />
<br />
While using a manually created {{ic|grub.cfg}} is absolutely fine, it's recommended that beginners automatically generate one:<br />
<br />
{{Tip|To automatically search for other operating systems on your computer, install {{Pkg|os-prober}} ({{ic|pacman -S os-prober}}) before running the next command.}}<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
For more information on configuring and using GRUB, see [[GRUB]].<br />
<br />
==== For UEFI motherboards ====<br />
<br />
For UEFI boot, the drive needs to be GPT-partitioned, and a UEFI System Partition (512 MiB or higher, FAT32, type {{ic|EF00}}) must be present and mounted on {{ic|/boot/efi}}. If you have followed this guide from the beginning, you've already done all of these.<br />
<br />
While there are other [[UEFI Bootloaders|UEFI bootloaders]] available, using EFISTUB is recommended. Below are instructions for setting up EFISTUB and GRUB.<br />
<br />
{{Note|Syslinux does not yet support UEFI.}}<br />
<br />
===== EFISTUB =====<br />
<br />
The Linux kernel can act as its own bootloader using EFISTUB. This is the UEFI boot method recommended by developers and simpler compared to {{ic|grub-efi-x86_64}}. The below steps set up rEFInd (a fork of rEFIt) to provide a menu for EFISTUB kernels, as well as for booting other UEFI bootloaders. You can also use [[UEFI Bootloaders#Using gummiboot|gummiboot]] instead of rEFInd. Both rEFInd and gummiboot can detect Windows UEFI bootloader in case of dual-boot.<br />
<br />
1. Boot in UEFI mode and load {{ic|efivars}} kernel module before chrooting:<br />
<br />
# modprobe efivars # before chrooting<br />
<br />
2. Mount the UEFISYS partition at {{ic|/mnt/boot/efi}}, chroot and [[UEFI_Bootloaders#Setting_up_EFISTUB|copy the kernel and initramfs files]] as described below.<br />
<br />
* Create {{ic|/boot/efi/EFI/arch/}} directory.<br />
<br />
* Copy {{ic|/boot/vmlinuz-linux}} to {{ic|/boot/efi/EFI/arch/vmlinuz-arch.efi}}. The {{ic|.efi}} file extension is very important as some UEFI firmwares refuse to launch a file without this extension. '''Important:''' Remember that the file is called vmlinu'''z''', but not vmlinu'''x'''.<br />
<br />
* Copy {{ic|/boot/initramfs-linux.img}} to {{ic|/boot/efi/EFI/arch/initramfs-arch.img}}.<br />
<br />
* Copy {{ic|/boot/initramfs-linux-fallback.img}} to {{ic|/boot/efi/EFI/arch/initramfs-arch-fallback.img}}.<br />
<br />
Every time the kernel and initramfs files are updated in {{ic|/boot}}, they need to be updated in {{ic|/boot/efi/EFI/arch}}. This can be automated either [[UEFI Bootloaders#Sync EFISTUB Kernel in UEFISYS partition using Systemd|using systemd]] or [[UEFI Bootloaders#Sync EFISTUB Kernel in UEFISYS partition using Incron|using incron]] (for non-systemd setups).<br />
<br />
3. In this guide you set up a bootloader GUI called rEFInd. Alternative bootloaders can be found on the page [[UEFI Bootloaders#Booting EFISTUB]].<br />
For the recommended rEFInd bootloader install the following packages:<br />
# pacman -S refind-efi efibootmgr<br />
<br />
4. Install rEFInd to the UEFISYS partition (summarized from [[UEFI Bootloaders#Using rEFInd]]):<br />
<br />
# mkdir -p /boot/efi/EFI/refind<br />
# cp /usr/lib/refind/refind_x64.efi /boot/efi/EFI/refind/refind_x64.efi<br />
# cp /usr/lib/refind/config/refind.conf /boot/efi/EFI/refind/refind.conf<br />
# cp -r /usr/share/refind/icons /boot/efi/EFI/refind/icons<br />
<br />
5. Create a {{ic|refind_linux.conf}} file with the kernel parameters to be used by rEFInd:<br />
<br />
{{hc|# nano /boot/efi/EFI/arch/refind_linux.conf|2=<br />
"Boot to X" "root=/dev/sdaX ro rootfstype=ext4 systemd.unit=graphical.target"<br />
"Boot to console" "root=/dev/sdaX ro rootfstype=ext4 systemd.unit=multi-user.target"}}<br />
<br />
{{Note|{{ic|refind_linux.conf}} is copied in the directory {{ic|/boot/efi/EFI/arch/}} where the initramfs and the kernel have been copied to in step 2. }}<br />
{{Note|In {{ic|refind_linux.conf}}, sdaX refers to your root file system, not your boot partition, if you created them separately. }}<br />
<br />
6. Add rEFInd to UEFI boot menu using [[UEFI#efibootmgr|efibootmgr]]. <br />
<br />
{{Warning|Using {{ic|efibootmgr}} on Apple Macs may brick the firmware and may need reflash of the motherboard ROM. For Macs, use {{AUR|mactel-boot}}, or "bless" from within Mac OS X.}}<br />
<br />
# efibootmgr -c -g -d /dev/sdX -p Y -w -L "rEFInd" -l '\EFI\refind\refind_x64.efi'<br />
<br />
{{Note|In the above command, X and Y denote the drive and partition of the UEFISYS partition. For example, in {{ic|/dev/sdc5}}, X is "c" and Y is "5".}}<br />
<br />
7. (Optional) As a fallback, in case {{ic|efibootmgr}} created boot entry does not work, copy {{ic|refind_x64.efi}} to {{ic|/boot/efi/EFI/boot/bootx64.efi}} as follows:<br />
<br />
# cp -r /boot/efi/EFI/refind/* /boot/efi/EFI/boot/<br />
# mv /boot/efi/EFI/boot/refind_x64.efi /boot/efi/EFI/boot/bootx64.efi<br />
<br />
===== GRUB =====<br />
<br />
{{Note|In case you have a system with 32-bit EFI, like pre-2008 Macs, install {{ic|grub-efi-i386}} instead, and use {{ic|1=--target=i386-efi}}.}}<br />
<br />
# pacman -S grub-efi-x86_64 efibootmgr<br />
# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=arch_grub --recheck<br />
# cp /usr/share/locale/en\@quot/LC_MESSAGES/grub.mo /boot/grub/locale/en.mo<br />
<br />
The next command creates a menu entry for GRUB in the UEFI boot menu. However, as of {{Pkg|grub-efi-x86_64}} version 2.00, {{ic|grub-install}} tries to create a menu entry, so running {{ic|efibootmgr}} may not be necessary. See [[UEFI#efibootmgr]] for more info.<br />
<br />
# efibootmgr -c -g -d /dev/sdX -p Y -w -L "Arch Linux (GRUB)" -l '\EFI\arch_grub\grubx64.efi'<br />
<br />
Next, while using a manually created {{ic|grub.cfg}} is absolutely fine, it's recommended that beginners automatically generate one:<br />
<br />
{{Tip|To automatically search for other operating systems on your computer, install {{Pkg|os-prober}} ({{ic|pacman -S os-prober}}) before running the next command.}}<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
For more information on configuring and using GRUB, see [[GRUB]].<br />
<br />
=== Unmount the partitions and reboot ===<br />
<br />
Exit from the chroot environment:<br />
<br />
# exit<br />
<br />
Since the partitions are mounted under {{ic|/mnt}}, we use the following command to unmount them:<br />
<br />
# umount /mnt/{boot,home,}<br />
<br />
Reboot the computer:<br />
<br />
# reboot<br />
<br />
{{Tip|Be sure to remove the installation media, otherwise you will boot back into it.}}<noinclude><br />
{{Beginners' Guide navigation}}</noinclude></div>Geshhttps://wiki.archlinux.org/index.php?title=GUID_Partition_Table&diff=248120GUID Partition Table2013-02-21T21:33:23Z<p>Gesh: Fixed grammar (noun-verb order)</p>
<hr />
<div>[[Category:File systems]]<br />
[[es:GUID Partition Table]]<br />
[[tr:Guid_Bölümledirme_Tablosu]]<br />
[[zh-CN:GUID Partition Table]]<br />
{{Article summary start}}<br />
{{Article summary text|An overview of the GUID Partition Table.}}<br />
{{Article summary heading|Overview}}<br />
{{Article summary text|{{Boot process overview}}}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Unified Extensible Firmware Interface}}<br />
{{Article summary wiki|Master Boot Record}}<br />
{{Article summary wiki|Arch Boot Process}}<br />
{{Article summary end}}<br />
<br />
GUID Partition Table (GPT) is a new style of partitioning which is part of the [[Unified Extensible Firmware Interface]] Specification, using the [[Wikipedia:Globally unique identifier | globally unique identifier]] for devices. It is different from the [[Master Boot Record]] (the more commonly used partitioning style) in many aspects and has many advantages.<br />
<br />
To understand GPT, it is important to understand what MBR is and what its disadvantages are.<br />
<br />
For any partitioning style, the number of partitions that can be defined is based on the total space allotted for the partition table and the space required for storing the information of a single partition.<br />
<br />
== Master Boot Record ==<br />
The MBR partition table stores the partitions info in the first sector of a hard disk as follows<br />
<br />
{| border="1"<br />
! Location in the HDD !! Purpose of the Code<br />
|-<br />
| First 440 bytes || MBR boot code that is launched by the BIOS.<br />
|-<br />
| 441-446 bytes || MBR disk signature.<br />
|-<br />
| 447-510 bytes || Actual partition table with info about primary and extended partitions. (Note that logical partitions are not listed here)<br />
|-<br />
| 511-512 bytes || MBR boot signature 0xAA55.<br />
|}<br />
<br />
The entire information about the primary partitions is limited to the 64 bytes allotted. To extend this, extended partitions were used. An extended partition is simply a primary partition in the MBR which acts like a container for other partitions called logical partitions. So one is limited to either 4 primary partitions, or 3 primary and 1 extended partitions with many logical partitions inside it.<br />
<br />
=== Problems with MBR ===<br />
# Only 4 primary partitions or 3 primary + 1 extended partitions (with arbitrary number of logical partitions within the extended partition) can be defined. If you have 3 primary + 1 extended partitions, and you have some free space outside the extended partition area, you cannot create a new partition over that free space.<br />
# Within the extended partition, the logical partitions' meta-data is stored in a linked-list structure. If one link is lost, all the logical partitions following that metadata is lost.<br />
# MBR supports only 1 byte partition type codes which leads to many collisions.<br />
# MBR stores partition sector information using 32-bit LBA values. This LBA length along with 512 byte sector size (more commonly used) limits the maximum addressable size of the disk to be 2 TiB. Any space beyond 2 TiB cannot be defined as a partition if MBR partitioning is used.<br />
<br />
== GUID Partition Table ==<br />
GUID Partition Table (GPT) uses GUIDs (or UUIDs in linux world) to define partitions and its types, hence the name. The GPT consists of:<br />
{| border="1"<br />
! Location in the HDD !! Purpose<br />
|-<br />
| First logical sector of the disk or First 512 bytes || Protective MBR - Same as a normal MBR but the 64-byte area contains a single 0xEE type Primary partition entry defined over the entire size of the disk or in case of >2 TiB, upto a partition size of 2 TiB.<br />
|-<br />
| Second logical sector of the disk or Next 512 bytes || Primary GPT Header - Contains the Unique Disk GUID, Location of the Primary Partition Table, Number of possible entries in partition table, CRC32 checksums of itself and the Primary Partition Table, Location of the Secondary (or Backup) GPT Header<br />
|-<br />
| 16 KiB (by default) following the second logical sector of the disk<br />
| Primary GPT Table - 128 Partition entries (by default, can be higher), each with an entry of size 128 bytes (hence total of 16 KiB for 128 partition entries). Sector numbers are stored as 64-bit LBA and each partition has a Partition Type GUID and a Unique Partition GUID.<br />
|-<br />
| 16 KiB (by default) before the last logical sector of the disk || Secondary GPT table - It is byte-for-byte identical to the Primary table. Used mainly for recovery in case the primary partition table is damaged.<br />
|-<br />
| Last logical sector of the disk or Last 512 bytes || Secondary GPT Header - Contains the Unique Disk GUID, Location of the Secondary Partition Table, Number of possible entries in the partition table, CRC32 checksums of itself and the Secondary Partition Table, Location of the Primary GPT Header. This header can be used to recover GPT info in case the primary header is corrupted.<br />
|}<br />
<br />
=== Advantages of GPT ===<br />
# Uses GUIDs (UUIDs) to identify partition types - No collisions.<br />
# Provides a unique disk GUID and unique partition GUID for each partition - A good filesystem-independent way of referencing partitions and disks.<br />
# Arbitrary number of partitions - depends on space allocated for the partition table - No need for extended and logical partitions. By default the GPT table contains space for defining 128 partitions. However if the user wants to define more partitions, he/she can allocate more space to the partition table (currently only gdisk is known to support this feature).<br />
# Uses 64-bit LBA for storing Sector numbers - maximum addressable disk size is 2 ZiB.<br />
# Stores a backup header and partition table at the end of the disk that aids in recovery in case the primary ones are damaged.<br />
# CRC32 checksums to detect errors and corruption of the header and partition table.<br />
<br />
=== Kernel Support ===<br />
<br />
{{ic|CONFIG_EFI_PARTITION}} option in the kernel config enables GPT support in the kernel (despite the name EFI PARTITION). This options must be built-in the kernel and not compiled as a loadable module. This option is required even if GPT disks are used only for data storage and not for booting. This option is enabled by default in Arch's {{Pkg|linux}} and {{Pkg|linux-lts}} kernels in [core] repo. In case of a custom kernel enable this option by doing {{ic|1=CONFIG_EFI_PARTITION=y}}.<br />
<br />
== Bootloader Support ==<br />
<br />
=== UEFI systems ===<br />
<br />
All UEFI Bootloaders support GPT disks since GPT is a part of UEFI Specification and thus mandatory for UEFI boot. See [[UEFI_Bootloaders]] for more info.<br />
<br />
=== BIOS systems ===<br />
<br />
{{Note|Some BIOS systems may not boot from GPT disks. See http://mjg59.dreamwidth.org/8035.html and http://rodsbooks.com/gdisk/bios.html for more info and possible workarounds.}}<br />
<br />
* [[GRUB]](2) requires a 1007 KiB "BIOS Boot Partition" (EF02 type code in gdisk and bios_grub flag in GNU Parted) in BIOS systems to embed its {{ic|core.img}} file due to lack of post-MBR embed gap in GPT disks. Runtime GPT support in GRUB(2) is provided by the {{ic|part_gpt}} module. See [[GRUB#GPT_specific_instructions]] for more information.<br />
<br />
* [[Syslinux]] requires the partition containing {{ic|/boot/syslinux/ldlinux.sys}} (irrespective whether {{ic|/boot}} is a separate partition or not) to be marked as "Legacy BIOS Bootable" GPT attribute (''legacy_boot'' flag in GNU Parted) to identify the partition containing the Syslinux boot files by its 440-byte MBR boot code {{ic|gptmbr.bin}}. See [[Syslinux#GUID_Partition_Table_aka_GPT]] for more information. It is equivalent to "boot" flag in MBR disks.<br />
<br />
* [[GRUB Legacy]], present in the AUR as {{AUR|grub-legacy}}, does not support GPT disks. Fedora's heavily patched GRUB Legacy fork {{AUR|grub-legacy-fedora-git}} contains GPT patches from Intel (tested in Fedora, not tested in Arch).<br />
<br />
{{Note|Fedora developers have mentioned that after the release of Fedora 17, ''grub-legacy-fedora'' development will stop. Fedora already uses GRUB(2) as its default BIOS bootloader since F16. Users are recommended to switch to GRUB(2) or Syslinux instead.}}<br />
<br />
{{Note|Some Intel Desktop Board motherboards will only boot a GPT disk if the protective MBR partition has its Boot flag set. This can be done safely with fdisk/cfdisk without damaging the GPT (but have backups / double-check the integrity of the GPT afterwards anyway).}}<br />
<br />
* [[LILO]]'s GPT support has not been tested so it is unclear whether it has issues booting in GPT disks.<br />
<br />
== Partitioning Utilities ==<br />
=== GPT fdisk ===<br />
<br />
GPT fdisk is a set of text-mode utilities for editing GPT disks. It consists of gdisk, sgdisk and cgdisk which are equivalent to respective tools from util-linux fdisk (used for MBR disks). It is available in the [extra] repository as {{Pkg|gptfdisk}}.<br />
<br />
{{Note|The fdisk partitioning utilities from util-linux (i.e. fdisk, cfdisk and sfdisk) do not support GPT, and may damage the GPT header and partition table if used on a GPT disk.}}<br />
<br />
==== Convert from MBR to GPT ====<br />
<br />
One of the best features of gdisk (and sgdisk and cgdisk too) is its ability to convert MBR and BSD disklabels to GPT without data loss. Upon conversion, all the MBR primary partitions and the logical partitions become GPT partitions with the correct partition type GUIDs and Unique partition GUIDs created for each partition. <br />
<br />
Just open the MBR disk using gdisk and exit with "w" option to write the changes back to the disk (similar to fdisk) to convert the MBR disk to GPT. '''Watch out for any error and fix them before writing any change to disk''' because you may risk losing data. See http://www.rodsbooks.com/gdisk/mbr2gpt.html for more info. After conversion, the bootloaders will need to be reinstalled to configure them to boot from GPT.<br />
<br />
{{Note|Remember that GPT stores a secondary table at the end of disk. You may have to make sure that the last 1 MiB of the disk is not used by any partition.}}<br />
<br />
{{Warning|Keep in mind that if your Boot-Manager is Grub, it needs a [[GRUB2#GPT_specific_instructions|BIOS Boot Partition]]. Create that BEFORE you convert to GPT. If you do not, gparted will not resize your boot partition to allow its creation, and when you reboot GRUB2 will not know where to look.}}<br />
<br />
=== GNU Parted ===<br />
<br />
In GNU Parted >=3.0, the {{ic|parted}} command-line utility does not support any filesystem related operation, and most of the FS related code has been removed from the libparted, leaving only minimal code required by external applications like gparted. The upstream recommends using the filesystem specific tools or one of the parted's GUI wrappers like gparted (which calls these external tools) for filesystem related operations.<br />
<br />
==See also==<br />
# Wikipedia's Page on [http://en.wikipedia.org/wiki/GUID_Partition_Table GPT] and [http://en.wikipedia.org/wiki/Master_boot_record MBR]<br />
# [http://rodsbooks.com/gdisk/ Homepage of Rod Smith's GPT fdisk tool] and its [http://sourceforge.net/projects/gptfdisk/ Sourceforge.net Project page - gptfdisk]<br />
# Rod Smith's page on [http://rodsbooks.com/gdisk/mbr2gpt.html Converting MBR to GPT] and [http://rodsbooks.com/gdisk/booting.html Booting OSes from GPT]<br />
# Rod Smith's page on the [http://www.rodsbooks.com/linux-fs-code/index.html New Partition Type GUID] for Linux data partitions<br />
# [http://sysresccd.org/Sysresccd-Partitioning-The-new-GPT-disk-layout System Rescue CD's page on GPT]<br />
# Wikipedia page on [http://en.wikipedia.org/wiki/BIOS_Boot_partition BIOS Boot Partition]<br />
# [http://www.ibm.com/developerworks/linux/library/l-gpt/index.html?ca=dgr-lnxw07GPT-Storagedth-lx&S_TACT=105AGY83&S_CMP=grlnxw07 Make the most of large drives with GPT and Linux - IBM Developer Works]<br />
# [http://www.microsoft.com/whdc/device/storage/GPT_FAQ.mspx Microsoft's Windows and GPT FAQ]</div>Geshhttps://wiki.archlinux.org/index.php?title=Synchronization_and_backup_programs&diff=239934Synchronization and backup programs2012-12-11T17:10:21Z<p>Gesh: Removed Backup-Manager, as upstream is dead</p>
<hr />
<div>[[Category:Data compression and archiving]]<br />
[[Category:System recovery]]<br />
[[ru:Backup Programs]]<br />
This wiki page contains information about various backup programs. It's a good idea to ''have'' regular backups of important data, most notably configuration files ({{Ic|/etc/*}}) and the local pacman database (usually {{Ic|/var/lib/pacman/local/*}}).<br />
<br />
== Introduction ==<br />
Before you start trying various programs out, try to think about your needs, e.g. consider the following questions:<br />
* What backup medium do I have available? (CD, DVD, remote server, external hard drive, etc.)<br />
* How often do I plan to backup? (daily, weekly, monthly, etc.)<br />
* What features do I expect from the backup solution? (compression, encryption, handles renames, etc.)<br />
* How do I plan to restore backups if needed?<br />
<br />
== Incremental backups ==<br />
Applications that can do incremental backups remember and take into account what data has been backed up during the last run and eliminate the need to have duplicates of unchanged data. Restoring the data to a certain point in time would require locating the last full backup and all the incremental backups from then to the moment when it is supposed to be restored. This sort of backup is useful for those who do it very often.<br />
<br />
=== Rsync-type backups ===<br />
The main characteristic of this type of backups is that they maintain a copy of the directory you want to keep a backup of, in a traditional "mirror" fashion.<br />
<br />
Certain rsync-type packages also do snapshot backups by storing files which describe how the contents of files and folders changed from the last backup (so-called 'diffs'). Hence, they are inherently incremental, but usually they do not have compression or encryption. On the other hand, a working copy of everything is immediately available, no decompression/decryption needed. A downside to rsync-type programs is that they cannot be easily burned and restored from a CD or DVD.<br />
<br />
==== Console ====<br />
* {{App|[[rsync]]|A file transfer program to keep remote files in sync.<br />
** rsync almost always makes a mirror of the source.<br />
** Impossible to restore a full backup before the most recent backup (but you can use --backup to keep old versions of the files).<br />
** Standard install on all distros.<br />
** Can run over SSH (port 22) or native rsync protocol (port 873).<br />
** Win32 version available.<br />
|http://rsync.samba.org/|{{Pkg|rsync}}}}<br />
<br />
* {{App|[[Wikipedia:Rsync#Variations|rdiff-backup]]|A utility for local/remote mirroring and incremental backups.<br />
** Stores the most recent backup as regular files.<br />
** To revert to older versions, you apply the diff files to recreate the older versions.<br />
** It is granularly incremental (delta backup), it only stores changes to a file; will not create a new copy of a file upon change.<br />
** Win32 version available.<br />
|http://www.nongnu.org/rdiff-backup/|{{Pkg|rdiff-backup}}}}<br />
<br />
* {{App|rsnapshot|A remote filesystem snapshot utility.<br />
** Does not store diffs, instead it copies entire files if they have changed.<br />
** Creates hard links between a series of backed-up trees (snapshots).<br />
** It is differential in that the size of the backup is only the original backup size plus the size of all files that have changed since the last backup.<br />
** Destination filesystem must support hard links.<br />
** Win32 version available.<br />
|http://www.rsnapshot.org/|{{Pkg|rsnapshot}}}}<br />
<br />
* {{App|SafeKeep|A client/server backup system which uses rdiff-backup.<br />
** Integrates with Linux LVM and databases to create consistent backups.<br />
** Bandwidth throttling.<br />
|http://safekeep.sourceforge.net/|{{AUR|safekeep}}}}<br />
<br />
* {{App|Link-Backup|A tool similar to rsync based scripts, but which does not use rsync.<br />
** Creates hard links between a series of backed-up trees (snapshots).<br />
** Intelligently handles renames, moves, and duplicate files without additional storage or transfer.<br />
** The backup directory contains {{ic|.catalog}}, a catalog of all unique file instances; backup trees hard-link to this catalog.<br />
** Transfer occurs over standard I/O locally or remotely between a client and server instance of this script.<br />
** It copies itself to the server; it does not need to be installed on the server.<br />
** Requires SSH for remote backups.<br />
** It resumes stopped backups; it can even be told to run for an arbitrary number of minutes.<br />
|http://www.scottlu.com/Content/Link-Backup.html|{{AUR|link-backup}}}}<br />
<br />
* {{App|[[Wikipedia:Unison (file synchronizer)|Unison]]|A program that synchronizes files between two machines over network (LAN or Inet) using a smart diff method + rsync. Allows the user to interactively choose which changes to push, pull, or merge.|http://www.cis.upenn.edu/~bcpierce/unison/|{{Pkg|unison}}}}<br />
<br />
* {{App|oldtime|A highly customizable and configurable backup & restore system.|https://github.com/GutenYe/oldtime|{{AUR?|oldtime}}}}<br />
<br />
==== Graphical ====<br />
* {{App|Back In Time|A simple backup tool for Linux inspired by the [[Wikipedia:FlyBack|FlyBack]] and [https://wiki.ubuntu.com/TimeVault/ TimeVault] projects.<br />
** Creates hard links between a series of backed-up trees (snapshots).<br />
** Really is just a front-end to {{ic|rsync}}, {{ic|diff}}, {{ic|cp}}.<br />
** A new snapshot is created only if something changed since the last snapshot.<br />
|http://backintime.le-web.org/|{{AUR|backintime}}}}<br />
<br />
* {{App|[[Wikipedia:FlyBack|FlyBack]]|A clone of Apple's [[Wikipedia:Time Machine (Mac OS)|Time Machine]], a backup utility for Mac OS X.|http://www.flyback-project.org/|{{AUR|flyback}}}}<br />
<br />
* {{App|[[Wikipedia:Areca Backup|Areca Backup]]|An easy to use and reliable backup solution for Linux and Windows.<br />
** Written in Java.<br />
** Primarily archive-based (zip), but will do file-based backup as well.<br />
** Delta backup supported (stores only changes).<br />
|http://areca.sourceforge.net/|{{AUR|areca}}}}<br />
<br />
* {{App|[[Wikipedia:LuckyBackup|luckyBackup]]|An easy program to backup and sync your files.<br />
** It is written in Qt and C++.<br />
** It has sync, backup (with include and exclude options) and restore capabilities.<br />
** It can do remote connection backups, scheduled backups.<br />
** A command line mode.<br />
|http://luckybackup.sourceforge.net/index.html|{{AUR|luckybackup}}}}<br />
<br />
* {{App|syncBackup|A front-end for rsync that provides a fast and extraordinary copying tool. It offers the most common options that control its behavior and permit very flexible specification of the set of files to be copied.<br />
|http://www.darhon.com/syncbackup|{{AUR|syncbackup}}}}<br />
<br />
* {{App|[[BackupPC]]|A high-performance, enterprise-grade system for backing up Unix, Linux, Windows, and Mac OS X desktops and laptops to a remote server.<br />
** Deduplication: Identical files across multiple backups of the same or different PCs are stored only once resulting in substantial savings in disk storage and disk I/O.<br />
** Optional compression support further reducing disk storage.<br />
** No client-side software is needed.<br />
** Simple but powerful web-based UI.<br />
|http://backuppc.sourceforge.net/index.html|{{Pkg|backuppc}}}}<br />
<br />
=== Other backups ===<br />
Most other backup applications tend to create (big) archive files and (of course) keep track of what's been archived. Creating {{ic|.tar.bz2}} or {{ic|.tar.gz}} archives has the advantage that you can extract the backups with just tar/bzip2/gzip, so you do not need to have the backup program around.<br />
<br />
==== Console ====<br />
* {{App|Arch Backup|A trivial backup script with simple configuration.<br />
** Configurable compression method.<br />
** Multiple backup targets.<br />
|http://code.google.com/p/archlinux-stuff/|{{Pkg|arch-backup}}}}<br />
<br />
* {{App|[[Backup with hdup|hdup]]|A very simple command line backup tool.<br />
** Creates tar.gz or tar.bz2 archives.<br />
** Supports gpg encryption.<br />
** Supports pushing over SSH.<br />
** Multiple backup targets.<br />
|http://miek.nl/projects/hdup2/|{{AUR|hdup}}}}<br />
<br />
* {{App|rdup|A platform for backups that provides scripts to facilitate backups and delegates the encryption, compression, transfer and packaging to other utilities in a true Unix-way.<br />
** Creates tar.gz archives or rsync-type copy.<br />
** Encryption (gpg, blowfish and others); also applies for rsync-type copy.<br />
** Compression (also for rsync-type copy).<br />
|http://miek.nl/projects/rdup|{{AUR|rdup}}}}<br />
<br />
* {{App|[[Duplicity]]|A simple command-line utility which allows encrypted compressed incremental backup to nearly any storage.<br />
** Supports gpg encryption and signing.<br />
** Supports gzip compression.<br />
** Supports full or incremental backups, incremental backup stores only difference between new and old file.<br />
** Supports pushing over FTP, SSH, rsync, WebDAV, WebDAVs, HSi and Amazon S3 or local filesystem.<br />
|http://www.nongnu.org/duplicity/|{{Pkg|duplicity}}}}<br />
<br />
* {{App|[[Wikipedia:DAR (Disk Archiver)|DAR]]|A full-featured command-line backup tool, short for Disk ARchive.<br />
** It uses its own format for archives (so you need to have it around when you want to restore).<br />
** Supports splitting backups into more files by size.<br />
** Makefile-type config files, some custom scripts are available along with it.<br />
** Supports basic encryption.<br />
** Automatic backup using [[cron]] is possible with {{AUR|sarab}}.<br />
|http://dar.linux.free.fr/|{{AUR|dar}} {{AUR|kdar}} (fontend)}}<br />
<br />
* {{App|Manent|An algorithmically strong backup and archival program. NOTE: no upstream activity since 2009.<br />
** Efficient backup to anything that looks like a storage.<br />
** Works well over a slow and unreliable network.<br />
** Offers online access to the contents of the backup.<br />
** Backed up storage is completely encrypted.<br />
** Several computers can use the same storage for backup, automatically sharing data.<br />
** Not reliant on timestamps of the remote system to detect changes.<br />
** Cross-platform support for Unicode file names.<br />
|http://code.google.com/p/manent/|{{AUR|manent}}}}<br />
<br />
* {{App|btar|tar-compatible archiver<br />
** Fast archive creation (multicore compression or ciphering)<br />
** Arbitrary chain of compression/ciphers (calls any compression/ciphering programs)<br />
** Indexed archive retrieval or listing<br />
** Redundancy<br />
** Serialization through pipes (and only one file per backup)<br />
** Can be extracted or checked with gnutar<br />
** Differential backups of multiple levels<br />
** Optional encoding of big files with rsync-differences<br />
|http://viric.name/cgi-bin/btar|{{AUR|btar}}}}<br />
<br />
==== Graphical ====<br />
* {{App|Backerupper|A simple program for backing up selected directories over a local network. Its main intended purpose is backing up a user's personal data.<br />
** Creates {{ic|.tar.gz}} archives.<br />
** Configurable backup frequency, backup time and max copies.<br />
|http://sourceforge.net/projects/backerupper/|{{AUR|backerupper}}}}<br />
<br />
* {{App|[[Duplicity|Déjà Dup]]|A simple GTK+ backup program. It hides the complexity of doing backups the 'right way' (encrypted, off-site, and regular) and uses duplicity as the backend.<br />
** Automatic, timed backup configurable in GUI.<br />
** Restore wizard.<br />
** Integrated into the Nautilus file manager.<br />
** Inherits several features of duplicity.<br />
|https://launchpad.net/deja-dup|{{Pkg|deja-dup|}}}}<br />
<br />
* {{App|Synkron|A folder synchronization tool.<br />
** Syncs multiple folders.<br />
** Can exclude files from sync based on wildcards.<br />
** Restores files.<br />
** Cross-platform support.<br />
|http://synkron.sourceforge.net/|{{AUR|synkron}}}}<br />
<br />
== Cloud backups ==<br />
* {{App|[[Wikipedia:CrashPlan|CrashPlan]]|An online/offsite backup solution.<br />
** Unlimited online space for very reasonable pricing.<br />
** Automatic and incremental backups to multiple destinations.<br />
** Intuitive GUI.<br />
** Offers encryption and de-duplication.<br />
** Software is generally free.<br />
|http://www.crashplan.com/|{{AUR|crashplan}}}}<br />
<br />
* {{App|[[Dropbox]]|A popular file-sharing service.<br />
** A daemon monitors a specified directory, and uploads incremental changes to dropbox.com. <br />
** Changes automatically show up on your other computers. <br />
** Includes file sharing and a public directory. <br />
** You can recover deleted files. <br />
** Community written add-ons. <br />
** Free accounts have 2GB storage.<br />
|http://www.getdropbox.com|{{AUR|dropbox}} {{AUR|nautilus-dropbox}}}}<br />
<br />
* {{App|[[Wikipedia:Jungle Disk|Jungle Disk]]|An online backup tool that stores its data in Amazon S3 or Rackspace Cloud Files.<br />
** A Nautilus extension.<br />
** Only paid plans available.<br />
|http://www.jungledisk.com/|{{AUR|nautilus-jungledisk}}}}<br />
<br />
* {{App|Tarsnap|A secure online backup service for BSD, Linux, OS X, Solaris and Windows (through Cygwin).<br />
** Compressed encrypted backups to Amazon S3 Servers.<br />
** Automate via [[cron]].<br />
** Incremental backups.<br />
** Backup any files or directories.<br />
** Command line only client.<br />
** Pay only for usage (bandwidth and storage). <br />
|http://www.tarsnap.com|{{Pkg|tarsnap}}}}<br />
<br />
* {{App|[[Wikipedia:Wuala|Wuala]]|A secure online storage, file synchronization, versioning and backup service.<br />
** Closed source, free and paid version available.<br />
** Free account holds 5GB.<br />
** Includes file sharing and a public directory.<br />
** Incremental backup and sync are both supported.<br />
** Social networking features.<br />
** All files in the cloud are first encrypted locally.<br />
|http://www.wuala.com/|{{AUR|wuala}}, {{AUR|wuala-daemon}} &ndash; to run as daemon}}<br />
<br />
* {{App|[[Wikipedia:SpiderOak|SpiderOak]]|An online backup tool for Windows, Mac and Linux users to back up, share, sync, access and store[1] their data.<br />
** Free and paid version available.<br />
** Free account holds 2GB.<br />
** Includes file sharing and a public directory.<br />
** Incremental backup and sync are both supported.<br />
|https://spideroak.com/|{{AUR|spideroak}}}}<br />
<br />
* {{App|[[Ubuntu One]]|An online storage service with sync and sharing across platforms.<br />
** Free and payed versions available.<br />
** Free account with 5GB.<br />
** Mobile access.<br />
** Music streaming.<br />
|https://one.ubuntu.com/services/|{{Pkg|ubuntuone-client}}}}<br />
<br />
* {{App|Packrat|A simple, modular backup system that uses [[Wikipedia:DAR (Disk Archiver)|DAR]] to take full or incremental backups of files and can store them locally, on a remote system via SSH, or on Amazon S3.|http://www.zeroflux.org/projects|{{AUR|packrat}}}}<br />
<br />
== Non-incremental backups ==<br />
Another type of backups are those used in case of a disaster. These include application that allow easy backup of entire filesystems and recovery in case of failure, usually in the form of a Live CD or USB drive. The contains complete system images from one or more specific points in time and are frequently used by to record known good configurations.<br />
<br />
* {{App|Q7Z|P7Zip GUI for Linux, which attempts to simplify data compression and backup. It can create the following archive types: 7z, BZip2, Zip, GZip, Tar.<br />
** Updates existing archives quickly.<br />
** Backup multiple folders to a storage location.<br />
** Create or extract protected archives.<br />
** Lessen effort by using archiving profiles and lists.<br />
|http://k7z.sourceforge.net/|{{AUR|q7z}}}}<br />
<br />
* {{App|[[Partclone]]|A tool that can be used to back up and restore a partition while considering only used blocks.<br />
** Supports ext2, ext3, hfs+, reiser3.5, reiser3.6, reiser4, ext4 and btrfs.<br />
** Supports compression.<br />
|http://partclone.nchc.org.tw/trac/|{{AUR|partclone}}}}<br />
<br />
* {{App|[[Wikipedia:Redo Backup and Recovery|Redo Backup and Recovery]]|A backup and disaster recovery application that runs from a bootable Linux CD image.<br />
** Is capable of bare-metal backup and recovery of disk partitions.<br />
** Uses [http://www.xpud.org/ xPUD] and [[Partclone]] for the backend.<br />
|http://www.redobackup.org/|{{AUR?|redobackup}}}}<br />
<br />
* {{App|[[Wikipedia:Clonezilla|Clonezilla]]|A disaster recovery, disk cloning, disk imaging and deployment solution.<br />
** Boots from live CD, USB flash drive, or PXE server.<br />
** Supports ext2, ext3, ext4, reiserfs, reiser4, xfs, jfs, btrfs FAT32, NTFS, HFS+ and others.<br />
** Uses Partclone (default), Partimage (optional), ntfsclone (optional), or dd to image or clone a partition.<br />
** Multicasting server to restore to many machines at once.<br />
|http://clonezilla.org/|{{AUR|clonezilla}}}}<br />
<br />
* {{App|[[Wikipedia:Partimage|Partimage]]|A disk cloning utility for Linux/UNIX environments.<br />
** Has a Live CD.<br />
** Supports the most popular filesystems on Linux, Windows and Mac OS.<br />
** Compression.<br />
** Saving to multiple CDs or DVDs or across a network using Samba/NFS.<br />
|http://www.partimage.org/Main_Page|{{Pkg|partimage}}}}<br />
<br />
* {{App|FSArchiver|A safe and flexible file-system backup and deployment tool<br />
** Support for basic file attributes (permissions, owner, ...).<br />
** Support for multiple file-systems per archive.<br />
** Support for extended attributes (they are used by SELinux).<br />
** Support the basic file-system attributes (label, uuid, block-size) for all linux file-systems.<br />
** Support for [http://www.fsarchiver.org/Cloning-ntfs ntfs filesystems] (ability to create flexible clones of a Windows partitions).<br />
** Checksumming of everything which is written in the archive (headers, data blocks, whole files).<br />
** Ability to restore an archive which is corrupt (it will just skip the current file).<br />
** Multi-threaded lzo, gzip, bzip2, lzma compression.<br />
** Support for splitting large archives into several files with a fixed maximum size.<br />
** Encryption of the archive using a password. Based on blowfish from libcrypto from [[OpenSSL]].<br />
** Support backup of a mounted root filesystem (-A option).<br />
|http://www.fsarchiver.org/Main_Page|{{Pkg|fsarchiver}}}}<br />
<br />
* {{App|[[Wikipedia:Mondo Rescue|Mondo Rescue]]|A disaster recovery solution to create backup media that can be used to redeploy the damaged system.<br />
** Image-based backups, supporting Linux/Windows.<br />
** Compression rate is adjustable.<br />
** Can backup live systems (without having to halt it).<br />
** Can split image over many files.<br />
** Supports booting to a Live CD to perform a full restore.<br />
** Can backup/restore over NFS, from CDs, tape drives and and other media.<br />
** Can verify backups.<br />
|http://www.mondorescue.org/|{{AUR|mondo}}}}<br />
<br />
== Versioning systems ==<br />
These are traditionally used for keeping track of software development; but if you want to have a simple way to manage your config files in one directory, it might be a good solution.<br />
<br />
=== Version control systems ===<br />
{{Wikipedia|Comparison of revision control software}}.<br />
<br />
* {{App|[[Git]]|A distributed revision control and source code management system with an emphasis on speed.<br />
** Very easy creation, merging, and deletion of branches.<br />
** Nearly all operations are performed locally, giving it a huge speed advantage on centralized systems.<br />
** Has a "staging area" or "index", this is an intermediate area where commits can be formatted and reviewed before completing the commit.<br />
** Does not handle binary files very well.<br />
|http://git-scm.com/|{{Pkg|git}}}}<br />
<br />
* {{App|[[Subversion]]|A full-featured centralized version control system originally designed to be a better CVS.<br />
** Renamed/copied/moved/removed files retain full revision history.<br />
** Native support for binary files, with space-efficient binary-diff storage.<br />
** Costs proportional to change size, not to data size.<br />
** Allows arbitrary metadata ("properties") to be attached to any file or directory. <br />
|http://subversion.apache.org/|{{Pkg|subversion}}}}<br />
<br />
* {{App|[[Mercurial]]|A distributed version control system written in Python and similar in many ways to Git.<br />
** Platform independent.<br />
** Support for [http://mercurial.selenic.com/wiki/UsingExtensions extensions].<br />
** A set of commands consistent with Subversion.<br />
** Supports tags.<br />
|http://mercurial.selenic.com/|{{Pkg|mercurial}}}}<br />
<br />
* {{App|[[Wikipedia:Bazaar (software)|Bazaar]]|A distributed version control system that helps you track project history over time and to collaborate easily with others.<br />
** Similar commands to Subversion.<br />
** Supports working with or without a central server.<br />
** Support for working with some other revision control systems<br />
** Complete Unicode support.<br />
|http://bazaar.canonical.com/en/|{{Pkg|bzr}}}}<br />
<br />
* {{App|[[Wikipedia:Darcs|Darcs]]|A distributed revision control system that was designed to replace traditional, centralized source control systems such as CVS and Subversion.<br />
** Offline mode.<br />
** Easy branching and merging.<br />
** Written in Haskell.<br />
** Not very fast.<br />
|http://darcs.net/|{{AUR|darcs}}}}<br />
<br />
=== VCS-based backups ===<br />
<br />
* {{App|Gibak|A backup system based on [[Git]].<br />
** Supports binary diffs.<br />
** Uses all of Git's features (such as {{ic|.gitignore}} for filtering files).<br />
** Uses Git's hook system to save information that Git does not (permissions, mtime, empty directories, etc).<br />
|https://github.com/pangloss/gibak|{{AUR|gibak}}}}<br />
* {{App|bup|A fledgling Git-based backup solution written in Python and C.<br />
** Uses a rolling checksum algorithm (similar to rsync) to split large files into chunks.<br />
** Can back up directly to a remote bup server.<br />
** Has an improved index format to allow you to track many files.<br />
|https://github.com/apenwarr/bup|{{AUR|bup}}}}<br />
* {{App|ColdStorage|Another backup tool using Git at its core, written in [[Qt]].|http://gitorious.org/coldstorage|{{AUR|coldstorage-git}}}}<br />
<br />
== External Resources ==<br />
* [http://www.halfgaar.net/backing-up-unix Backing up Linux and other Unix(-like) systems]<br />
* [http://www.askapache.com/security/mirror-using-rsync-ssh.html Mirroring an Entire Site using Rsync over SSH]</div>Geshhttps://wiki.archlinux.org/index.php?title=Mutt&diff=218303Mutt2012-08-16T21:28:45Z<p>Gesh: Spelling errors: HTLM => HTML; quiet => quite</p>
<hr />
<div>[[Category:Email Client]]<br />
[[es:Mutt]]<br />
[[it:Mutt]]<br />
[[zh-CN:Mutt]]<br />
[[zh-TW:Mutt]]<br />
{{Article summary start}}<br />
{{Article summary text|A guide on configuring and using Mutt.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|fdm}}<br />
{{Article summary wiki|msmtp}}<br />
{{Article summary end}}<br />
<br />
'''Mutt''' is a text-based mail client renowned for its powerful features. Though over a decade old, Mutt remains the mail client of choice for a great number of power-users. Unfortunately, a default Mutt install is plagued by complex keybindings along with a daunting amount of documentation. This guide will help the average user get Mutt up and running, and begin customizing it to their particular needs.<br />
<br />
==Overview==<br />
Mutt focuses primarily on being a Mail User Agent (MUA), and was originally written to view mail. Later implementations added for retrieval, sending, and filtering mail are simplistic compared to other mail applications and, as such, users may wish to use external applications to extend Mutt's capabilities. <br />
<br />
Nevertheless, the Arch Linux {{Pkg|mutt}} package is compiled with IMAP, POP3 and SMTP support, removing the necessity for external applications.<br />
<br />
This article covers using both native IMAP sending and retrieval, and a setup depending on [[OfflineIMAP]] or [[getmail]] (POP3) to retrieve mail, [[procmail]] to filter it in the case of POP3, and [[msmtp]] to send it.<br />
<br />
==Installing==<br />
[[pacman|Install]] {{Pkg|mutt}}, available in the [[Official Repositories]]. <br />
<br />
Optionally install external helper applications for an IMAP setup, such as {{Pkg|offlineimap}} and {{Pkg|msmtp}}.<br />
<br />
Or (if using POP3) {{Pkg|getmail}} or {{Pkg|fdm}} and {{Pkg|procmail}}.<br />
<br />
{{Note|<br />
*If you just need the authentication methods LOGIN and PLAIN, these are satisfied with the dependency {{Pkg|libsasl}}<br />
*If you want to (or have to) use CRAM-MD5, GSSAPI or DIGEST-MD5, install the package {{Pkg|cyrus-sasl-gssapi}}<br />
*If you are using Gmail as your SMTP server, you may need to install the package {{Pkg|cyrus-sasl}}<br />
}}<br />
<br />
==Configuring==<br />
This section covers IMAP, [[#POP3]], [[#Maildir]] and [[#SMTP]] configuration.<br />
<br />
Note that Mutt will recognize two locations for its configuration file; {{ic|~/.muttrc}} and {{ic|~/.mutt/muttrc}}. Either location will work.<br />
You should also know some prerequisite for Mutt configuration. Its syntax is very close the Bourne Shell. For example, you can get the content of another config file:<br />
source /path/to/other/config/file<br />
You can use variables and assign the result of shell commands to them.<br />
set editor=`echo \$EDITOR`<br />
Here the {{ic|$}} gets escaped so that it does not get substituted by Mutt before being passed to the shell.<br />
Also note the use of the backquotes, as bash syntax {{ic|$(...)}} does not work.<br />
Mutt has a lot of predefined variables, but you can also set your own. User variable '''must begin with "my"!'''<br />
set my_name = "John Doe"<br />
<br />
===IMAP===<br />
''Native and external setups''<br />
<br />
====Using native IMAP support====<br />
The pacman version of Mutt is compiled with IMAP support. At the very least you need to have 4 lines in your muttrc file to be able to access your mail.<br />
<br />
=====imap_user=====<br />
set imap_user=USERNAME<br />
<br />
Continuing with the previous example, remember that Gmail requires your full email address (this is not standard):<br />
set imap_user=your.username@gmail.com<br />
<br />
=====imap_pass=====<br />
If unset, the password will be prompted for.<br />
set imap_pass=SECRET<br />
<br />
=====folder=====<br />
Instead of a local directory which contains all your mail (and directories), use your server (and the highest folder in the hierarchy, if needed).<br />
set folder=imap[s]://imap.server.domain[:port]/[folder/]<br />
<br />
You do not have to use a folder, but it might be convenient if you have all your other folders inside your INBOX, for example. Whatever you set here as your folder can be accessed later in Mutt with just an equal sign (=). Example:<br />
set folder=imaps://imap.gmail.com/<br />
<br />
It should be noted that for several accounts, it is best practice to use different folders -- e.g. for ''account-hook''. If you have several Gmail account, use<br />
set folder=imaps://username@imap.gmail.com/<br />
instead, where your account is ''username@gmail.com''.<br />
<br />
=====spoolfile=====<br />
You can now use '=' or '+' as a substitution for the full {{Ic|folder}} path that was configured above. For example:<br />
set spoolfile=+INBOX<br />
<br />
=====mailboxes=====<br />
Any imap folders that should be checked regularly for new mail should be listed here:<br />
mailboxes =INBOX =family<br />
mailboxes imaps://imap.gmail.com/INBOX imaps://imap.gmail.com/family<br />
<br />
Alternatively, check for all subscribed IMAP folders (as if all were added with a {{Ic|mailboxes}} line):<br />
set imap_check_subscribed<br />
<br />
These two versions are equivalent, but the first is much more convenient. Also, newer Mutt versions are configured by default to include a macro bound to the 'y' key which will allow you to change to any of the folders listed under mailboxes.<br />
<br />
=====Summary=====<br />
Using these options, you will be able to start Mutt, enter your IMAP password, and start reading your mail. Here is a muttrc snippet (for Gmail) with some other lines you might consider adding for better IMAP support.<br />
{{bc|1=<br />
set folder = imaps://imap.gmail.com/<br />
set imap_user = your.username@gmail.com<br />
set imap_pass = your-imap-password<br />
set spoolfile = +INBOX<br />
mailboxes = +INBOX<br />
<br />
# store message headers locally to speed things up<br />
# if hcache is a folder, Mutt will create sub cache folders for each account which may speeds things even more up<br />
set header_cache = ~/.mutt/hcache<br />
<br />
# specify where to save and/or look for postponed messages<br />
set postponed = +[Gmail]/Drafts<br />
<br />
# allow Mutt to open new imap connection automatically<br />
unset imap_passive<br />
<br />
# keep imap connection alive by polling intermittently (time in seconds)<br />
set imap_keepalive = 300<br />
<br />
# how often to check for new mail (time in seconds)<br />
set mail_check = 120<br />
}}<br />
<br />
====External IMAP support====<br />
While IMAP-functionality is built into Mutt, it does not download mail for offline-use. The [[OfflineIMAP]] article describes how to download your emails to a local folder which can then be processed by Mutt.<br />
<br />
Consider using applications such as [[spamassassin]] or [[imapfilter]] to sort mail.<br />
<br />
===POP3===<br />
''Retrieving and sorting mail with external applications''<br />
<br />
====Retrieving mail====<br />
Create the directory {{ic|~/.getmail/}}. Open the file {{ic|~/.getmail/getmailrc}} in your favorite text editor.<br />
<br />
Here is an example {{ic|getmailrc}} used with a gmail account.<br />
{{bc|1=<br />
[retriever]<br />
type = SimplePOP3SSLRetriever<br />
server = pop.gmail.com<br />
username = username@gmail.com<br />
port = 995<br />
password = password<br />
<br />
[destination]<br />
type = Maildir<br />
path = ~/mail/<br />
}}<br />
<br />
You can tweak this to your POP3 service's specification.<br />
<br />
Most people will like to add the following section to their {{ic|getmailrc}} to prevent all the mail on the server being downloaded every time getmail is ran.<br />
{{bc|1=<br />
[options]<br />
read_all = False<br />
}}<br />
<br />
As you can see {{ic|~/.getmail/getmailrc}} contains sensitive information (namely, email account passwords in plain text). You will want to change access permissions to the directory so only the owner can see it:<br />
<br />
$ chmod 700 ~/.getmail<br />
<br />
For this guide we will be storing our mail in the {{ic|maildir}} format. The two main mailbox formats are {{ic|mbox}} and {{ic|maildir}}. The main difference between the two is that {{ic|mbox}} is one file, with all of your mails and their headers stored in it, whereas a {{ic|maildir}} is a directory tree. Each mail is its own file, which will often speed things up.<br />
<br />
A {{ic|maildir}} is just a folder with the folders {{ic|cur}}, {{ic|new}} and {{ic|tmp}} in it.<br />
mkdir -p ~/mail/{cur,new,tmp}<br />
<br />
Now, run getmail. If it works fine, you can create a cronjob for getmail to run every n hours/minutes. Type {{ic|crontab -e}} to edit cronjobs, and enter the following:<br />
*/10 * * * * /usr/bin/getmail<br />
That will run {{ic|getmail}} every 10 minutes.<br />
<br />
Also, to quiet getmail down, we can reduce its verbosity to zero by adding the following to {{ic|getmailrc}}.<br />
{{bc|1=<br />
[options]<br />
verbose = 0<br />
}}<br />
<br />
=====More than one Email account with getmail=====<br />
By default, when you run {{ic|getmail}} the program searches for the file getmailrc created as seen above. If you have more than one mail account you would like to get mail from, then you can create such a file for each email address, and then tell getmail to run using both of them. Obviously if you have two accounts and two files you cannot have both of them called getmailrc. What you do is give them two different names, using myself as an example: I call one personal, and one university. These two files contain content relevant to my personal mail, and my university work mail respectively. Then to get getmail to work on these two files, instead of searching for getmailrc(default), I use the --rcfile switch like so: {{ic|getmail --rcfile university --rcfile personal}} This can work with more files if you have more email accounts, just make sure each file is in the .getmail directory and make sure to alter the cronjob to run the command with the --rcfile switches. E.g.<br />
'''*/30 * * * * /usr/bin/getmail --rcfile university --rcfile personal'''<br />
<br />
Obviously you can call your files whatever you want, providing you include them in the cronjob or shell command, and they are in the .getmail/ directory, getmail will fetch mail from those two accounts.<br />
<br />
====Sorting mail====<br />
[http://www.procmail.org/ Procmail] is an extremely powerful sorting tool. For the purposes of this wiki, we will do some primitive sorting to get started.<br />
<br />
You must edit your getmailrc to pass retrieved mail to procmail:<br />
{{bc|1=<br />
[destination]<br />
type = MDA_external<br />
path = /usr/bin/procmail<br />
}}<br />
<br />
Now, open up {{ic|.procmailrc}} in your favorite editor. The following will sort all mail from the happy-kangaroos mailing list, and all mail from your lovey-dovey friend in their own maildirs.<br />
{{bc|1=<br />
MAILDIR=$HOME/mail<br />
DEFAULT=$MAILDIR/inbox/<br />
LOGFILE=$MAILDIR/log<br />
<br />
:0:<br />
* ^To: happy-kangaroos@nicehost.com<br />
happy-kangaroos/<br />
<br />
:0:<br />
* ^From: loveydovey@iheartyou.net<br />
lovey-dovey/<br />
}}<br />
After you have saved your {{ic|.procmailrc}}, run getmail and see if procmail succeeds in sorting your mail into the appropriate directories.<br />
<br />
{{Note|One easy to make mistake with .procmailrc is the permission. procmail require it to have permission 644 and will not give meaningless error message if you do not.}}<br />
<br />
===Maildir===<br />
Maildir is a generic and standardized format. Almost every MUA is able to handle Maildirs and Mutt's support is excellent. There are just a few simple things that you need to do to get Mutt to use them. Open your muttrc and add the following lines:<br />
{{bc|1=<br />
set mbox_type=Maildir<br />
set folder=$HOME/mail<br />
set spoolfile=+/<br />
set header_cache=~/.hcache<br />
}}<br />
<br />
This is a minimal Configuration that enables you to access your Maildir and checks for new local Mails in INBOX. This configuration also caches the headers of the eMails to speed up directory-listings. It might not be enabled in your build (but it sure is in the Arch-Package). Note that this does not affect OfflineIMAP in any way. It always syncs the all directories on a Server. {{ic|spoolfile}} tells Mutt which local directories to poll for new Mail. You might want to add more Spoolfiles (for example the Directories of Mailing-Lists) and maybe other things. But this is subject to the Mutt manual and beyond the scope of this document.<br />
<br />
===SMTP===<br />
Whether you use POP or IMAP to receive mail you will probably still send mail using SMTP.<br />
<br />
====Using native SMTP support====<br />
The pacman version of Mutt is also compiled with SMTP support. Just check the online manual [http://manual.cream.org/index.cgi/muttrc.5 muttrc], or {{ic|man muttrc}} for more information.<br />
<br />
For example:<br />
{{bc|1=<br />
set my_pass='mysecretpass'<br />
set my_user=myname<br />
<br />
set smtp_url=smtps://$my_user:$my_pass@smtp.domain.tld<br />
set ssl_force_tls = yes<br />
}}<br />
<br />
Note that if your SMTP credentials are the same as your IMAP credentials, than you can use those variables:<br />
<br />
{{bc|1=<br />
set smtp_url=smtps://$imap_user:$imap_pass@smtp.domain.tld<br />
}}<br />
<br />
You may need to tweak the security parameters. If you get an error like<br />
{{ic|SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol}},<br />
then your server most probably uses the SMTP instead of SMTPS.<br />
<br />
{{bc|1=<br />
set smtp_url=smtp://$imap_user:$imap_pass@smtp.domain.tld<br />
}}<br />
<br />
There is other variable that you may need to set. For example for use of STARTTLS:<br />
{{bc|1=<br />
set ssl_starttls = yes<br />
}}<br />
<br />
====External SMTP support====<br />
An external SMTP agent such as [[msmtp]] or [[SSMTP]] can also be used. This section exclusively covers configuring Mutt for msmtp.<br />
<br />
Edit Mutt's configuration file or create it if unpresent:<br />
{{hc|muttrc|2=<br />
set realname='Disgruntled Kangaroo'<br />
<br />
set sendmail="/usr/bin/msmtp"<br />
<br />
set edit_headers=yes<br />
set folder=~/mail<br />
set mbox=+mbox<br />
set spoolfile=+inbox<br />
set record=+sent<br />
set postponed=+drafts<br />
set mbox_type=Maildir<br />
<br />
mailboxes +inbox +lovey-dovey +happy-kangaroos<br />
}}<br />
<br />
====Sending mails from Mutt====<br />
Now, startup {{Ic|mutt}}:<br />
<br />
You should see all the mail in {{ic|~/mail/inbox}}. Press {{keypress|m}} to compose mail; it will use the editor defined by your {{Ic|EDITOR}} environment variable. If this variable is not set, you can fix it before starting Mutt:<br />
$ export EDITOR=your-favorite-editor<br />
$ mutt<br />
<br />
You should store the EDITOR value into your shell resource configuration file (such as [[bashrc]]).<br />
You can also set the editor from Mutt's configuration file:<br />
{{hc|.muttrc|2=<br />
set editor=your-favorite-editor<br />
}}<br />
<br />
For testing purposes, address the letter to yourself. After you have written the letter, save and exit the editor. You will return to Mutt, which will now show information about your e-mail. Press {{keypress|y}} to send it.<br />
<br />
===Multiple accounts===<br />
<br />
Now you should have a working configuration for one account at least. You might wonder how to use several accounts, since we put everything into a single file.<br />
Mutt can handle this thanks to one of its most powerful feature: hooks.<br />
Basically a hook is a command that gets executed before a specific action.<br />
There are several hook availables. For multiple accounts, either account-hooks or folder-hooks are useful. Folder-hooks will run a command before switching folders. Let's give an example with folder-hooks:<br />
<br />
{{bc|1=<br />
folder-hook 'personal' 'source ~/.mutt/personal_config'<br />
folder-hook 'work' 'source ~/.mutt/work_config'<br />
<br />
## Switch to default account on startup.<br />
source "~/.mutt/work_config"<br />
}}<br />
<br />
In that case, all the IMAP/POP3/SMTP config for each account should go to its respective folder.<br />
{{Warning|When one account is setting a variable that is not specified for other accounts, you '''must unset''' it for them, otherwise configuration will overlap and you will most certainly experience unexpected behaviour.}}<br />
<br />
Now all your accounts are set, start Mutt. To switch from one account to another, just change the folder ({{keypress|c}} key). But since you have to type the complete address -- for IMAP/POP3 folders, this may be quite inconvenient -- let's bind some key to it.<br />
<br />
{{bc|<br />
## Shortcuts<br />
macro index <f2> '<sync-mailbox><enter-command>source ~/.mutt/personal_config<enter><change-folder>!<enter>'<br />
macro index <f3> '<sync-mailbox><enter-command>source ~/.mutt/work_config<enter><change-folder>!<enter>'<br />
}}<br />
<br />
===Passwords management===<br />
Keep in mind that writing your password in {{ic|.muttrc}} is a security risk, and it might be of your concern.<br />
The trivial way to keep your passwords safe is not writing them in the config file. Mutt will then prompt for it when needed.<br />
However, this is quiet combersome in the long run, especiallly if you have several accounts.<br />
<br />
Here follows a smart and convenient solution: all your passwords are encrypted into one file and Mutt will prompt for a passphrase on startup only.<br />
Since GPG is a Mutt dependency, we will use it, but you can use any other keyring tool as well (e.g. {{pkg|pwsafe}}).<br />
<br />
First create a pair of public/private keys:<br />
gpg --gen-key<br />
{{Note|Do not leave any blank when giving your full name (surname and given name). Use {{Keypress|_}} or {{Keypress|-}} as a separator}}<br />
If you do not understand this process have a look at [http://en.wikipedia.org/wiki/Asymmetric_cryptography Wikipedia/Asymmetric cryptography].<br />
<br />
Create a file '''in a secure environment''' since it will contain your passwords for a couple of seconds:<br />
{{hc|~/.my-pwds|<nowiki><br />
set my_pw_personal = ****<br />
set my_pw_work = ****</nowiki><br />
}}<br />
<br />
Now encrypt the file:<br />
gpg -e -r <your-name> ~/.my-pwds<br />
Note that <your-name> must match the one you provided at the {{ic|gpg --gen-key}} step.<br />
Now you can wipe your file containing your passwords in clear:<br />
wipe -l2 -x7 -p3 ~/.my-pwds<br />
{{Note|you must first [[pacman|install]] {{Pkg|wipe}} if not already installed}}<br />
Back to your account dedicated files, e.g. {{ic|.mutt/personal_config}}:<br />
{{bc|1=<br />
set imap_pass=$my_pw_personal<br />
# Every time the password is needed, use $my_pw_personal variable.<br />
}}<br />
<br />
And in your {{ic|.muttrc}}, '''before''' you source any account dedicated file:<br />
{{bc|<br />
source "gpg2 -dq ~/.my-pwds.gpg {{ic|<nowiki>|</nowiki>}}"<br />
}}<br />
<br />
* The {{ic|-q}} parameter makes gpg2 quiet which prevents gpg2 output messing with Mutt interface.<br />
* The pipe {{ic|<nowiki>|</nowiki>}} at the end of a string is the Mutt syntax to tell that you want the result of what is preceeding.<br />
<br />
Explanation: when Mutt starts, it will first source the result of the password decryption, that's why it will prompt for a passphrase. Then all passwords will be stored in memory in specific variables for the time Mutt runs. Then when a folder-hook is called, is sets the imap_pass variable to the variable holding the appropriate password. When switching account, the imap_pass variable will be set to another variable holding another password, etc.<br />
<br />
If you use external tools like OfflineIMAP and msmtp, you need to set up an agent (e.g. gpg-agent, see [[GnuPG#gpg-agent]]) to keep the passphrase into cache and thus avoiding those tools always prompting for it.<br />
<br />
==Customizing==<br />
Guides to get you started with using & customizing Mutt : <br />
* [http://mutt.blackfish.org.uk/ My first Mutt] (maintained by Bruno Postle) <br />
* [http://www.therandymon.com/woodnotes/mutt/using-mutt.html The Woodnotes Guide to the Mutt Email Client] (maintained by Randall Wood)<br />
<br />
If you have any Mutt specific questions, feel free to ask in [[ArchChannel|the irc channel]].<br />
<br />
===Printing===<br />
You can install {{AUR|muttprint}} from the [[AUR]] for a fancier printing quality.<br />
In your muttrc file, insert:<br />
set print_command="/usr/bin/muttprint %s -p {PrinterName}"<br />
<br />
===Custom mail headers===<br />
One of the greatest thing in Mutt is that you can have full control over your mail header.<br />
<br />
First, make your headers editable when you write e-mails:<br />
set edit_headers=yes<br />
<br />
Mutt also features a special function {{ic|my_hdr}} for customizing your header. Yes, it is named just like a variable, but in fact it is a function.<br />
<br />
You can clear it completely, which you ''should'' do when switching accounts with different headers, otherwise they will overlap:<br />
unmy_hdr *<br />
<br />
Other variables have also an impact on the headers, so it is wise to clear them before using {{ic|my_hdr}}:<br />
unset use_from<br />
unset use_domain<br />
unset user_agent<br />
<br />
Now, you can add any field you want -- even non-standard one -- to your header using the following syntax:<br />
my_hdr <FIELD>: <VALUE><br />
Note that <VALUE> can be the result of a command.<br />
<br />
Example:<br />
{{bc|<br />
## Extra info.<br />
my_hdr X-Info: Keep It Simple, Stupid.<br />
<br />
## OS Info.<br />
my_hdr X-Operating-System: `uname -s`, kernel `uname -r`<br />
<br />
## This header only appears to MS Outlook users<br />
my_hdr X-Message-Flag: WARNING!! Outlook sucks<br />
<br />
## Custom Mail-User-Agent ID.<br />
my_hdr User-Agent: Every email client sucks, this one just sucks less.<br />
}}<br />
<br />
===Signature block===<br />
Create a .signature in your home directory. Your signature will be appended at the end of your email.<br />
Alternatively you can specify a file in your Mutt configuration:<br />
set signature="path/to/sig/file"<br />
====Random signature====<br />
You can use fortune to add a random signature to Mutt.<br />
{{bc|$ pacman -S fortune-mod}}<br />
<br />
Create a fortune file and then add the following line to your .muttrc:<br />
{{bc|1=set signature="fortune pathtofortunefile&#124;"}}<br />
Note the pipe at the end. It tells Mutt that the specified string is not a file, but a command.<br />
<br />
===Viewing URLs & opening your favorite web browser===<br />
Your should start by creating a .mutt directory in $HOME if not done yet. There, create a file named macros. Insert the following:<br />
macro pager \cb <pipe-entry>'urlview'<enter> 'Follow links with urlview'<br />
<br />
Then install {{AUR|urlview}} from the [[AUR]].<br />
<br />
Create a .urlview in $HOME and insert the following:<br />
REGEXP (((http|https|ftp|gopher)|mailto)[.:][^ >"\t]*|www\.[-a-z0-9.]+)[^ .,;\t>">\):]<br />
COMMAND <your-browser> %s <br />
<br />
When you read an email on the pager, hitting ctrl+b will list all the urls from the email. Navigate up or down with arrow keys and hit enter on the desired url. Your browser will start and go to the selected site.<br />
<br />
Some browser will require additional arguments to work properly. For example, [[Luakit]] will close on Mutt exit. You need to fork it to background, using the {{ic|-n}} parameter:<br />
COMMAND luakit -n %s 2>/dev/null<br />
The {{ic|2>/dev/null}} is to make it quiet, i.e. to prevent useless message printing where you do not want them to.<br />
<br />
*Note - If you have some problems with urlview due to Mutt's url encoding you can try [http://www.memoryhole.net/~kyle/extract_url/ extract_url.pl]<br />
<br />
*Note - If you would like to see a short contextual preview of the content around each URL, try [https://aur.archlinux.org/packages.php?ID=44853 urlscan]. The macro in your muttrc is the same as for urlview (except for the 'urlscan' command). There is no additional configuration required other than ensuring $BROWSER is set.<br />
<br />
===Viewing HTML===<br />
It is possible to pass the html body to an external HTML program and then dump it, keeping email viewing uniform and unobtrusive. Two programs are described here: lynx and w3m.<br />
<br />
Install lynx or w3m:<br />
pacman -S lynx<br />
or<br />
pacman -S w3m<br />
<br />
If {{ic|~/.mutt/mailcap}} does not exist you will need to create it and save the following to it.<br />
text/html; lynx -display_charset=utf-8 -dump %s; nametemplate=%s.html; copiousoutput<br />
or, in case of w3m,<br />
text/html; w3m -I %{charset} -T text/html; copiousoutput;<br />
<br />
Edit muttrc and add the following,<br />
set mailcap_path = ~/.mutt/mailcap<br />
<br />
To automatically open HTML messages in lynx, add this additional line to the muttrc:<br />
auto_view text/html<br />
<br />
The beauty of this is, instead of seeing an html body as source or being opened<br />
by a separate program, in this case lynx, you see the formatted content directly,<br />
and any url links within the email can be displayed with {{keypress|Ctrl+b}}.<br />
<br />
If you receive many emails with multiple or alternate encodings Mutt may default to treating every email as html. To avoid this, add the following variable to your ~/.muttrc to have Mutt default to text when available and use w3m/lynx only when no text version is availble in the email:<br />
alternative_order text/plain text/html<br />
<br />
===Mutt and Vim===<br />
*To limit the width of text to 72 characters, edit your .[[vim]]rc file and add:<br />
au BufRead /tmp/mutt-* set tw=72<br />
<br />
*Another choice is to use Vim's mail filetype plugin to enable other mail-centric options besides 72 character width. Edit {{ic|~/.vim/filetype.vim}}, creating it if unpresent, and add:<br />
{{bc| <br />
augroup filetypedetect<br />
" Mail<br />
autocmd BufRead,BufNewFile *mutt-* setfiletype mail<br />
augroup END<br />
}}<br />
<br />
*To set a different tmp directory, e.g. ~/.tmp, add a line to your muttrc as follows:<br />
set tmpdir="~/.tmp"<br />
<br />
*To reformat a modified text see the Vim context help<br />
:h 10.7<br />
<br />
===Mutt and GNU nano===<br />
[[nano]] is another nice console editor to use with Mutt. <br />
<br />
To limit the width of text to 72 characters, edit your .nanorc file and add:<br />
set fill 72<br />
<br />
Also, in muttrc file, you can specify the line to start editing so that you will skip the mail header:<br />
set editor="nano +7"<br />
<br />
===Mutt and Emacs===<br />
Emacs has a ''mail'' major mode.<br />
To switch to mail-mode automatically when Emacs is called from Mutt, you can add the following to your {{ic|.emacs}}:<br />
{{hc|.emacs|<nowiki><br />
;; Mutt support. <br />
(setq auto-mode-alist<br />
(append<br />
'(("/tmp/mutt.*" . mail-mode)<br />
)<br />
auto-mode-alist)<br />
)</nowiki><br />
}}<br />
<br />
If you usually run Emacs daemon, you may want Mutt to connect to it. Add this to your {{ic|.muttrc}}:<br />
{{hc|.muttrc|<nowiki><br />
set editor="emacsclient -a \"\" -t"</nowiki><br />
}}<br />
<br />
===Colors===<br />
Append sample color definitions to your .muttrc file:<br />
$ cat /usr/share/doc/mutt/samples/colors.linux >> ~/.muttrc<br />
Then adjust to your liking.<br />
The actual color each of these settings will produce depends on the colors set in your [[Xresources|~/.Xresources]] file.<br />
<br />
Alternatively, you can source any file you want containing colors (and thus act as a theme file):<br />
{{bc|<br />
source ~/.mutt/colors.zenburn<br />
}}<br />
<br />
A nice theme example:<br />
{{bc|<nowiki><br />
## Theme kindly inspired from <br />
## http://nongeekshandbook.blogspot.ie/2009/03/mutt-color-configuration.html <br />
<br />
## Colours for items in the index <br />
color index brightcyan black ~N<br />
color index brightred black ~O<br />
color index brightyellow black ~F<br />
color index black green ~T<br />
color index brightred black ~D<br />
mono index bold ~N<br />
mono index bold ~F<br />
mono index bold ~T<br />
mono index bold ~D<br />
<br />
## Highlights inside the body of a message. <br />
<br />
## URLs <br />
color body brightgreen black "(http|ftp|news|telnet|finger)://[^ \"\t\r\n]*"<br />
color body brightgreen black "mailto:[-a-z_0-9.]+@[-a-z_0-9.]+"<br />
mono body bold "(http|ftp|news|telnet|finger)://[^ \"\t\r\n]*"<br />
mono body bold "mailto:[-a-z_0-9.]+@[-a-z_0-9.]+"<br />
<br />
## Email addresses. <br />
color body brightgreen black "[-a-z_0-9.%$]+@[-a-z_0-9.]+\\.[-a-z][-a-z]+"<br />
<br />
## Header <br />
color header green black "^from:"<br />
color header green black "^to:"<br />
color header green black "^cc:"<br />
color header green black "^date:"<br />
color header yellow black "^newsgroups:"<br />
color header yellow black "^reply-to:"<br />
color header brightcyan black "^subject:"<br />
color header red black "^x-spam-rule:"<br />
color header green black "^x-mailer:"<br />
color header yellow black "^message-id:"<br />
color header yellow black "^Organization:"<br />
color header yellow black "^Organisation:"<br />
color header yellow black "^User-Agent:"<br />
color header yellow black "^message-id: .*pine"<br />
color header yellow black "^X-Fnord:"<br />
color header yellow black "^X-WebTV-Stationery:"<br />
<br />
color header red black "^x-spam-rule:"<br />
color header green black "^x-mailer:"<br />
color header yellow black "^message-id:"<br />
color header yellow black "^Organization:"<br />
color header yellow black "^Organisation:"<br />
color header yellow black "^User-Agent:"<br />
color header yellow black "^message-id: .*pine"<br />
color header yellow black "^X-Fnord:"<br />
color header yellow black "^X-WebTV-Stationery:"<br />
color header yellow black "^X-Message-Flag:"<br />
color header yellow black "^X-Spam-Status:"<br />
color header yellow black "^X-SpamProbe:"<br />
color header red black "^X-SpamProbe: SPAM"<br />
<br />
## Coloring quoted text - coloring the first 7 levels: <br />
color quoted cyan black<br />
color quoted1 yellow black<br />
color quoted2 red black<br />
color quoted3 green black<br />
color quoted4 cyan black<br />
color quoted5 yellow black<br />
color quoted6 red black<br />
color quoted7 green black<br />
<br />
## Default color definitions <br />
#color hdrdefault white green <br />
color signature brightmagenta black<br />
color indicator black cyan<br />
color attachment black green<br />
color error red black<br />
color message white black<br />
color search brightwhite magenta<br />
color status brightyellow blue<br />
color tree brightblue black<br />
color normal white black<br />
color tilde green black<br />
color bold brightyellow black<br />
#color underline magenta black <br />
color markers brightcyan black<br />
<br />
## Colour definitions when on a mono screen <br />
mono bold bold<br />
mono underline underline<br />
mono indicator reverse</nowiki><br />
}}<br />
<br />
===Index Format===<br />
<br />
Here follows a quick example to put in your {{ic|.muttrc}} to customize the Index Format, i.e. the columns displayed in the folder view.<br />
{{bc|<nowiki><br />
set date_format="%y-%m-%d %T"<br />
set index_format="%2C | %Z [%d] %-30.30F (%-4.4c) %s"</nowiki><br />
}}<br />
See the [http://www.mutt.org/doc/manual/manual-6.html Mutt Reference], {{ic|man 3 strftime}} and {{ic|man 3 printf}} for more details.<br />
<br />
===Address aliases===<br />
''Aliases'' is the way Mutt manages contacts.<br />
An alias is '''nickname [longname] <address>'''.<br />
* The '''nickname''' is what you will type in Mutt to get your contact address. One word only, and should be easy to remember.<br />
* The '''longname''' is optional. It may be several words.<br />
* An '''<address>''' must be in a valid form (i.e. with an {{keypress|@}}).<br />
<br />
It is quite simple indeed. Add this to {{ic|.muttrc}}:<br />
{{bc|1=<br />
set alias_file = "~/.mutt/aliases"<br />
set sort_alias = alias<br />
set reverse_alias = yes<br />
source $alias_file<br />
}}<br />
<br />
Explanation:<br />
* {{ic|alias_file}} is the file where the information is getting stored when you add an alias from within Mutt.<br />
* {{ic|sort_alias}} specifies which field to use to sort the alias list when displayed in Mutt. Possible values: alias, address.<br />
* {{ic|reverse_alias}} sorts in reverse order if set to yes.<br />
* {{ic|source $alias_file}} tells Mutt to read aliases on startup. Needed for auto-completion.<br />
<br />
Now all you have to do when prompted {{ic|To:}} is writing the alias instead of the full address. The beauty of it is that you can auto-complete the alias using {{keypress|Tab}}.<br />
Autocompleting a wrong or an empty string will display the full list. You can select the alias as usual, or by typing its index number.<br />
<br />
There is two ways to create aliases:<br />
* From Mutt, press {{keypress|a}} when an e-mail of the targetted person if selected.<br />
* Edit the alias_file manually. The syntax is really simple:<br />
{{bc|<br />
alias nickname Long Name <my-friend@domain.tld><br />
}}<br />
<br />
== Tips and tricks ==<br />
<br />
===Request IMAP mail retrieval manually===<br />
If you do not want to wait for the next automatic IMAP fetching (or if you did no enable it), you might want to fetch mails manually.<br />
There is a mutt command {{ic|imap-fetch-mail}} for that.<br />
Alternatively, you could bind it to a key:<br />
bind index "^" imap-fe<br />
12a9<br />
tch-mail<br />
<br />
===Speed up folders switch===<br />
Add this to your {{ic|.muttrc}}:<br />
{{bc|1=<br />
set sleep_time = 0<br />
}}<br />
<br />
===Use Mutt to send mail from command line===<br />
Man pages will show all available commands and how to use them, but here are a couple of examples. You could use Mutt to send alerts, logs or some other system information, triggered by login through .bash_profile, or as a regular cron job.<br />
<br />
Send a message:<br />
mutt -s "Subject" somejoeorjane@someserver.com < /var/log/somelog<br />
<br />
Send a message with attachment:<br />
mutt -s "Subject" somejoeorjane@someserver.com -a somefile < /tmp/sometext.txt<br />
<br />
===Composing HTML e-mails===<br />
<br />
Since Mutt has nothing of a WYSIWIG client, HTML is quite straightforward, and you can do much more than with all WYSIWIG mail clients around since you edit the source code directly.<br />
Simply write your mail using HTML syntax. For example:<br />
{{bc|<nowiki><br />
This is normal text<br><br />
<b>This is bold text</b></nowiki><br />
}}<br />
Now before sending the mail, use the {{ic|edit-type}} command (default shortcut {{keypress|Ctrl+t}}), and replace {{ic|text/plain}} by {{ic|text/html}}.<br />
<br />
{{Note|HTML e-mails are regarded by many people as useless, cumbersome, and subject to reading issues. Mutt can read HTLM mails with a text browser like w3m or lynx, but it has clearly no advantage over a plain-text e-mail. You should avoid writing HTLM e-mails when possible.}}<br />
<br />
===How to display another email while composing===<br />
A common complaint with Mutt is that when composing a new mail (or reply), you cannot open another mail (i.e. for checking with another correspondent) without closing the current mail (postponing). The following describes a solution:<br />
<br />
First, fire up Mutt as usual. Then, launch another terminal window. Now start a new Mutt with <br />
mutt -R<br />
This starts Mutt in read-only mode, and you can browse other emails at your convenience. It is strongly recommended to always launch a second Mutt in read-only mode, as conflicts will easily arise otherwise.<br />
<br />
Now, this solution calls for a bit of typing, so we would like to automate this. The following works with [[Awesome]], in other WM's or DE's similar solutions are probably available: just google how to add a key binding, and make the desired key execute <br />
$TERM -e mutt -R <br />
where $TERM is your terminal.<br />
<br />
As for Awesome: edit your rc.lua, and add the following on one of the first lines, after terminal = "yourTerminal" etc.<br />
mailview = terminal .. " -e mutt -R"<br />
This automatically uses your preferred terminal, ".." is concatenation in Lua. Note the space before -e.<br />
<br />
Then add the following inside --{{{ Key bindings<br />
awful.key({ modkey, }, "m", function() awful.util.spawn(mailview) end),<br />
<br />
Omit the final comma if this is the last line. You can, of course use another key than "m". Now, save&quit, and check your syntax with <br />
awesome -k<br />
If this is good, restart awesome and give it a try!<br />
<br />
Now, a usage example: Launch Mutt as usual. Start a new mail, and then press "Mod4"+"m". This opens your mailbox in a new terminal, and you can browse around and read other emails. Now, a neat bonus: exit this read-only-Mutt with "q", and the terminal window it created disappears!<br />
<br />
===Mutt-Sidebar===<br />
{{Aur|mutt-sidebar}} - A patch for a list of folders on the left side of the Mutt window.<br />
<br />
[http://www.lunar-linux.org/mutt-sidebar/ mutt-sidebar maintainer website and documentation]<br />
<br />
===Migrating mails from one computer to another===<br />
In case you are transfering your mails to a new machine (copy&paste), you probably need to delete ~/.hcache to make mutt able to read your migrated E-Mails. Otherwise mutt may freeze.<br />
<br />
==Troubleshooting==<br />
<br />
===Backspace does not work in Mutt===<br />
This is a common problem with some xterm-like terminals.<br />
Two solutions:<br />
* Either rebind the key in {{ic|.muttrc}}<br />
bind index,pager ^? previous-page<br />
Note that {{ic|^?}} is one single character representing backspace in [http://en.wikipedia.org/wiki/Caret_notation Caret notation]. To type in Emcas, use {{keypress|Ctrl+q Backspace}}, in Vim {{keypress|Ctrl+v Backspace}}.<br />
<br />
* Or fix your terminal:<br />
$ infocmp > termbs.src <br />
Edit {{ic|termbs.src}} and change {{ic|1= kbs=^H}} to {{ic|1= kbs=\177}}, then: <br />
$ tic -x termbs.src<br />
<br />
== See also ==<br />
* [http://www.mutt.org/ The official Mutt website]<br />
* [http://wiki.mutt.org/ The Mutt wiki]<br />
* [http://pbrisbin.com/posts/two_accounts_in_mutt/ Brisbin's great guide on how to setup different IMAP accounts with Mutt + offlineimap + msmtp]<br />
* [http://home.roadrunner.com/~computertaijutsu/mutt.html A Quick Guide to Mutt]<br />
* [http://pyropus.ca/software/getmail/configuration.html#running Documentation on Configuring Getmail with rcfiles]</div>Geshhttps://wiki.archlinux.org/index.php?title=Zsh&diff=217963Zsh2012-08-15T12:04:51Z<p>Gesh: Fixed dead link</p>
<hr />
<div>[[Category:Command shells]]<br />
[[cs:Zsh]]<br />
[[fr:Zsh]]<br />
[[zh-CN:Zsh]]<br />
[http://www.zsh.org Zsh] is a powerful shell that operates as both an interactive shell and as a scripting language interpreter. While being compatible with [[Bash]] (not by default, only if you issue "emulate sh"), it offers many advantages such as:<br />
<br />
*Faster<br />
*Improved tab completion<br />
*Improved globbing<br />
*Improved array handling<br />
*Fully customisable<br />
<br />
The Zsh FAQ offers [http://zsh.sourceforge.net/FAQ/zshfaq01.html#l4 more reasons] to use Zsh as your shell.<br />
<br />
==Installation==<br />
<br />
Before starting you may want to see what shell is currently being used:<br />
<br />
$ echo $SHELL<br />
<br />
[[pacman|Install]] the {{Pkg|zsh}} package available in the [[Official Repositories|official repositories]].<br />
<br />
===Initial configuration===<br />
<br />
Make sure that Zsh has been installed correctly by running the following in a terminal:<br />
<br />
$ zsh<br />
<br />
You should now see '''zsh-newuser-install''', which will walk you through some basic configuration. If you want to skip this, press {{Ic|q}}.<br />
<br />
===Making Zsh your default shell===<br />
<br />
If the shell is listed in {{ic|/etc/shells}} you can use the {{Ic|chsh}} command to change your default shell without root access. If you installed Zsh from the [[Official Repositories|official repositories]], it should already have an entry in {{ic|/etc/shells}}. <br />
<br />
Change the default shell for the current user:<br />
<br />
$ chsh -s $(which zsh)<br />
<br />
{{Note|You have to log out and log back in, in order to start using Zsh as your default shell.}}<br />
<br />
After logging back in, you should notice Zsh's prompt, which by default looks different from Bash's. However you can verify that Zsh is the current shell by issuing:<br />
<br />
$ echo $SHELL<br />
<br />
{{Tip|If you are replacing {{Pkg|bash}}, you may want to move some code from {{ic|~/.bashrc}} to {{ic|~/.zshrc}} (e.g. the prompt and the aliases) and from {{ic|~/.bash_profile}} to {{ic|~/.zprofile}} (e.g. [[Start X at Boot|the code that starts your X Window System]]).}}<br />
<br />
==Configuration files==<br />
At login, Zsh sources the following files in this order:<br />
;{{ic|~/.zshenv}}:This file should contain commands to set the command search path, plus other important environment variables; it should not contain commands that produce output or assume the shell is attached to a tty. <br />
;{{ic|/etc/profile}}:This file is sourced by all Bourne-compatible shells upon login: it sets up an environment upon login and application-specific ({{ic|/etc/profile.d/*.sh}}) settings. <br />
;{{ic|~/.zprofile}}:This file is generally used for automatic execution of user's scripts.<br />
;{{ic|~/.zshrc}}:This is Zsh's main configuration file.<br />
;{{ic|~/.zlogin}}:This file is generally used for automatic execution of user's scripts.<br />
<br />
At logout it sources '''{{ic|~/.zlogout}}''', which is used for automatic execution of user's scripts.<br />
<br />
{{Note|<br />
*The paths used in Arch's {{Pkg|zsh}} package are different from the default ones used in the man pages.<br />
*{{Ic|$ZDOTDIR}} defaults to {{Ic|$HOME}}<br />
*{{ic|/etc/profile}} is not a part of the regular list of startup files run for Zsh, but is sourced from {{ic|/etc/zsh/zprofile}} in the {{Pkg|zsh}} package. Users should take note that {{ic|/etc/profile}} sets the {{ic|$PATH}} variable which will overwrite any {{ic|$PATH}} variable set in {{ic|~/.zshenv}}. To prevent this, either replace the {{ic|/etc/zsh/zprofile}} file with your own, or set your {{ic|$PATH}} variable from {{ic|~/.zshrc}}.<br />
}}<br />
<br />
==~/.zshrc configuration==<br />
<br />
Although Zsh is usable out of the box, it is almost certainly not set up the way you would like to use it, but due to the sheer amount of customisation available in Zsh, configuring Zsh can be a daunting and time-consuming experience.<br />
<br />
Included below is a sample configuration file, it provides a decent set of default options as well as giving examples of many ways that Zsh can be customised. In order to use this configuration save it as a file named {{ic|.zshrc}}. You can then apply the changes without needing to logout and then back in by running:<br />
<br />
$ source ~/.zshrc<br />
<br />
===Simple .zshrc===<br />
<br />
Here is a simple {{ic|.zshrc}}, that should be sufficient to get you started:<br />
<br />
{{hc|~/.zshrc|<br />
autoload -U compinit promptinit<br />
compinit<br />
promptinit<br />
<br />
# This will set the default prompt to the walters theme<br />
prompt walters}}<br />
<br />
=== Command Completion ===<br />
Perhaps the most compelling feature of Zsh is its advanced autocompletion abilities. At the very least, you will want to enable autocompletion in your {{ic|.zshrc}}. To enable autocompletion, add the following to:<br />
<br />
{{hc|~/.zshrc|<br />
autoload -U compinit<br />
compinit}}<br />
<br />
The above configuration includes ssh/scp/sftp hostnames completion but in order for this feature to work you will need to prevent ssh from hashing hosts names in ~/.ssh/known_hosts (Warning: be aware that this makes your computer vulnerable to [http://nms.lcs.mit.edu/projects/ssh/README.hashed-hosts "Island-hopping" attacks]). In that intention, comment the following line or set the value to "no":<br />
{{hc|/etc/ssh/ssh_config|<br />
#HashKnownHosts yes}}<br />
And move your ~/.ssh/known_hosts somewhere else so that ssh creates a new one with with un-hashed hostnames (warning: previously known hosts will thus be lost).<br />
<br />
For autocompletion with an arrow-key driven interface, add the following to:<br />
{{hc|~/.zshrc|<br />
zstyle ':completion:*' menu select}}<br />
<br />
For autocompletion of command line switches for aliases, add the following to:<br />
{{hc|~/.zshrc|<br />
setopt completealiases}}<br />
<br />
=== Key Bindings ===<br />
Zsh does not use readline, instead it uses its own and more powerful zle. It does not read {{ic|/etc/inputrc}} or {{ic|~/.inputrc}}.<br />
zle has an emacs mode and a vi mode. By default, it tries to guess whether you want emacs or vi keys from the $EDITOR environment variable. If it is empty, it will default to [[emacs]]. You can change this with bindkey -v or bindkey -e.<br />
<br />
To get some special keys working:<br />
{{hc|~/.zshrc|<br />
bindkey "\e[1~" beginning-of-line # Home<br />
bindkey "\e[4~" end-of-line # End<br />
bindkey "\e[5~" beginning-of-history # PageUp<br />
bindkey "\e[6~" end-of-history # PageDown<br />
bindkey "\e[2~" quoted-insert # Ins<br />
bindkey "\e[3~" delete-char # Del<br />
bindkey "\e[5C" forward-word<br />
bindkey "\eOc" emacs-forward-word<br />
bindkey "\e[5D" backward-word<br />
bindkey "\eOd" emacs-backward-word<br />
bindkey "\e\e[C" forward-word<br />
bindkey "\e\e[D" backward-word<br />
bindkey "\e[Z" reverse-menu-complete # Shift+Tab<br />
# for rxvt<br />
bindkey "\e[7~" beginning-of-line # Home<br />
bindkey "\e[8~" end-of-line # End<br />
# for non RH/Debian xterm, can't hurt for RH/Debian xterm<br />
bindkey "\eOH" beginning-of-line<br />
bindkey "\eOF" end-of-line<br />
# for freebsd console<br />
bindkey "\e[H" beginning-of-line<br />
bindkey "\e[F" end-of-line<br />
# for guake<br />
bindkey "\eOF" end-of-line<br />
bindkey "\eOH" beginning-of-line<br />
bindkey "<nowiki>^[[1;5D</nowiki>" backward-word<br />
bindkey "<nowiki>^[[1;5C</nowiki>" forward-word<br />
bindkey "\e[3~" delete-char # Del<br />
}}<br />
<br />
{{Note|To get the proper sequences for certain key combinations, start {{Ic|cat}} or {{Ic|read}} without any parameters and press them; they should then be printed in the terminal. Both can be closed again via {{Keypress|Ctrl}}+{{Keypress|C}}.}}<br />
<br />
===History search===<br />
You can add these lines to your .zshrc<br />
<br />
{{hc|~/.zshrc|<nowiki><br />
bindkey "^[[A" history-beginning-search-backward<br />
bindkey "^[[B" history-beginning-search-forward<br />
</nowiki>}}<br />
<br />
Doing this, only past commands beginning with the current input would have been shown.<br />
<br />
===Prompts===<br />
<br />
There is a quick and easy way to set up a colored prompt in Zsh. Make sure that prompt is set to autoload in your {{ic|.zshrc}}. This can be done by adding these lines to:<br />
<br />
{{hc|~/.zshrc|<br />
autoload -U promptinit<br />
promptinit<br />
}}<br />
<br />
You can now see available prompts by running the command:<br />
<br />
$ prompt -l<br />
<br />
To try one of the commands that is listed, use the command prompt followed by the name of the prompt you like. For example, to use the "walters" prompt, you would enter:<br />
<br />
$ prompt walters<br />
<br />
===Customizing your prompt===<br />
<br />
In case you are dissatisfied with the prompts mentioned above(or want to expand their usefulness), zsh offers the possibility to build your own custom prompt. Zsh supports a left- and right-sided prompt additional to the single, left-sided prompt that is common to all shells. You can customize it by using "PROMPT =" with the following variables:<br />
<br />
====Prompt variables====<br />
=====General=====<br />
; %n : The username<br />
; %m : The computer's hostname(truncated to the first period)<br />
; %M : The computer's hostname<br />
; %l : The current tty<br />
; %? : The return code of the last-run application.<br />
; %# : The prompt based on user privileges ({{Ic|#}} for root and {{Ic|%}} for the rest)<br />
<br />
=====Times=====<br />
; %T : System time(HH:MM)<br />
; %* : System time(HH:MM:SS)<br />
; %D : System date(YY-MM-DD)<br />
<br />
=====Directories=====<br />
; %~ : The current working directory. If you are in you are in your {{ic|$HOME}}, this will be replaced by {{ic|~}}.<br />
; %d : The current working directory.<br />
<br />
For the options mentioned above: You can prefix an integer to show only certain parts of your working path. If you entered {{Ic|%1d}} and found yourself in {{Ic|/usr/bin}} it would show {{Ic|bin}}. This can also be done with negative integers:<br />
{{Ic|%-1d}} using the same directory as above would show {{Ic|/}}.<br />
<br />
=====Formatting=====<br />
; %U [...] %u : Begin and end underlined print<br />
; %B [...] %b : Begin and end bold print<br />
; %{ [...] %} : Begin and enter area that will not be printed. Useful for setting colors.<br />
:In fact, this tag forces Zsh to ignore anything inside them when making indents for the prompt as well.<br />
:As such, not to use it can have some weird effects on the margins and indentation of the prompt.<br />
<br />
=====Colors=====<br />
Zsh has a different approach to setting colors on the terminal than the one depicted [https://wiki.archlinux.org/index.php/Color_Bash_Prompt here]. First you write in your {{Ic|.zshrc}}:<br />
autoload -U colors && colors<br />
<br />
Following commands would now produce the color escape sequence needed to set the requested color when the prompt is printed:<br />
; $fg[color] : will set the text color (red, green, blue, etc.)<br />
; $reset_color : will reset the text color to white<br />
It is useful to put these color commands inside {{Ic|%{ [...] %} }}, so the shell knows there is no output from these sequences and the cursor hasn't moved.<br />
<br />
;Possible color values<br />
{| border="1"<br />
|-<br />
|black || red, <br />
|-<br />
|green || yellow, <br />
|-<br />
|blue || magenta<br />
|-<br />
|cyan || white<br />
|-<br />
|}<br />
Note that bold text doesn't necessarily use the same colors as normal text. The bold colors are also referred to as ''high intensity'' or ''bright'' versions. See [[Rxvt-unicode#Colors]].<br />
<br />
====Example====<br />
To have a two-sided prompt you could write:<br />
PROMPT="%{$fg[red]%}%n%{$reset_color%}@%{$fg[blue]%}%m %{$fg[yellow]%}%1~ %{$reset_color%}%#"<br />
RPROMPT="[%{$fg[yellow]%}%?%{$reset_color%}]"<br />
<br />
It would equal(without colors):<br />
username@host ~ % [0]<br />
<br />
===Sample .zshrc files===<br />
<br />
Here is a list of {{ic|.zshrc}} files. Feel free to add your own:<br />
<br />
* [https://github.com/robbyrussell/oh-my-zsh Oh-my-zsh Plugin and Theme system for Zsh] can help you manage your zshrc file and has a huge community of over 2000 forks on github;<br />
* Basic setup, with dynamic prompt and window title/hardinfo => http://github.com/MrElendig/dotfiles-alice/blob/master/.zshrc;<br />
* An Arch package named [https://www.archlinux.org/packages/extra/any/grml-zsh-config/ grml-zsh-config] comes from http://grml.org/zsh and provides a zshrc file that includes many tweaks for your zshell.<br />
* https://github.com/slashbeast/things/blob/master/configs/DOTzshrc - zshrc with multiple features, be sure to check out comments into it. Notable features: confirm function to ensure that user wnat to run poweroff, reboot or hibernate, support for GIT in prompt (done without vcsinfo), tab completion with menu, printing current executed command into window's title bar and more.<br />
<br />
==Global configuration==<br />
Occasionally you might want to have some settings applied globally to all zsh users. The zsh wiki tells us that there are some global configuration files, for example {{ic|/etc/zshrc}}. This however is slightly different on ArchLinux, since it has been compiled with flags specifically to target {{ic|/etc/zsh/}} instead.<br />
<br />
So, for global configuration use {{ic|/etc/zsh/zshrc}}, not {{ic|/etc/zshrc}}. The same goes for {{ic|/etc/zsh/zshenv}}, {{ic|/etc/zsh/zlogin}} and {{ic|/etc/zsh/zlogout}}. Note that these files are not installed by default, so you need to create them yourself if you want to use them.<br />
<br />
The only exception is zprofile, use {{ic|/etc/profile}} instead.<br />
<br />
===Autostarting applications===<br />
Zsh always executes {{ic|/etc/zsh/zshenv}} and {{ic|$ZDOTDIR/.zshenv}} so do not bloat these files.<br />
<br />
If the shell is a login shell, commands are read from {{ic|/etc/profile}} and then {{ic|$ZDOTDIR/.zprofile}}. Then, if the shell is interactive, commands are read from {{ic|/etc/zsh/zshrc}} and then {{ic|$ZDOTDIR/.zshrc}}. Finally, if the shell is a login shell, {{ic|/etc/zsh/zlogin}} and {{ic|$ZDOTDIR/.zlogin}} are read.<br />
<br />
==Uninstallation==<br />
If you decide that Zsh is not the shell for you and you want to return to Bash, you must first change your default shell back to Bash, before removing the Zsh package.<br />
<br />
Follow, [[Zsh#Making Zsh your default shell]] to change the default shell back to Bash, just replace zsh with bash.<br />
<br />
Now you can safely remove the Zsh package.<br />
<br />
{{Warning| Failure to follow the above will result in all kinds of problems.}}<br />
<br />
If you did not follow the above, you can still change the default shell back to Bash by editing {{ic|/etc/passwd}} as root. <br />
<br />
{{Warning| It is '''strongly''' recommended to use vipw when editing user information as it prevents badly formatted entries.}}<br />
<br />
For example: <br />
<br />
from:<br />
username:x:1000:1000:Full Name,,,:/home/username:/bin/zsh<br />
to:<br />
username:x:1000:1000:Full Name,,,:/home/username:/bin/bash<br />
<br />
==See also==<br />
*[http://zsh.sourceforge.net/Intro/intro_1.html#SEC1 Zsh Introduction]<br />
*[http://zsh.sourceforge.net/Guide/zshguide.html Users Guide]<br />
*[http://zsh.sourceforge.net/Doc/Release/index-frame.html Zsh Docs] (you can choose a different format for the doc in http://zsh.sourceforge.net/Doc/)<br />
*[http://zsh.sourceforge.net/FAQ/zshfaq01.html Zsh FAQ]<br />
*[http://zshwiki.org/home/ Zsh Wiki]<br />
*[http://grml.org/zsh/zsh-lovers.html Zsh-lovers]<br />
*[http://www.bash2zsh.com/zsh_refcard/refcard.pdf Bash2Zsh Reference Card]<br />
*[https://github.com/robbyrussell/oh-my-zsh Oh My Zshell by Robby Russell] <br />
*[http://www.gentoo.org/doc/en/zsh.xml Gentoo Linux Documentation -- zsh Configuration and Installation Guide]<br />
*[http://my.opera.com/blackbelt_jones/blog/2007/06/05/zsh-prompt-configuration-issue-solved Setting up the zsh prompt]<br />
<br />
*'''IRC channel''': #zsh at irc.freenode.org</div>Geshhttps://wiki.archlinux.org/index.php?title=Virtual_user_mail_system_with_Postfix,_Dovecot_and_Roundcube&diff=217598Virtual user mail system with Postfix, Dovecot and Roundcube2012-08-12T17:27:42Z<p>Gesh: Changed perms to Dovecot's suggested values</p>
<hr />
<div>[[Category:Web Server]]<br />
<br />
This article describes how to set up a complete virtual user mail system on an Arch Linux system in the simplest manner possible. However, since a mail system consists of many complex components, quite a bit of configuration will still be necessary. Roughly, the components used in this article are Postfix, Dovecot, PostfixAdmin and Roundcube.<br />
<br />
In the end, the provided solution will allow you to use the best currently available security mechanisms, you will be able to send mails using SMTP and SMTPS and receive mails using POP3, POP3S, IMAP and IMAPS. Additionally, configuration will be easy thanks to PostfixAdmin and users will be able to login using Roundcube. What a deal!<br />
<br />
This article assumes that you have a working [[LAMP]] setup as we will need a working Apache2 as well as MYSQL database. Of course, with a few changes to these instructions you could easily use another httpd and database. For the purposes of this tutorial, however, the choice made above will be used. Additionally, the article assumes all-default settings for every package installed below. No changes except for those mentioned will be required.<br />
<br />
Should any unforeseen problems occur, feel free to use the discussion page to voice your problems and I will try to answer.<br />
<br />
== Installation ==<br />
# pacman -S dovecot postfix<br />
<br />
== Configuration ==<br />
=== User ===<br />
For security reasons, a new user should be created to store the mails:<br />
groupadd -g 5000 vmail<br />
useradd -u 5000 -g vmail -s /sbin/nologin -d /home/vmail -m vmail<br />
A gid and uid of 5000 is used in both cases so that we do not run into conflicts with regular users. All your mail will then be stored in '''/home/vmail'''. You could change the home dir to something like '''/var/mail/vmail''' but careful to change this in any configuration below as well.<br />
<br />
=== Database ===<br />
You will need to create an empty database and corresponding user. We will be using PostfixAdmin's tables to fill the database later on. In this article, ''postfix_user'' will have read/write access to ''postfix_db'' using ''hunter2'' for a password. You are expected to create your database and user yourself as shown in the following code. Make sure to assign proper permissions.<br />
<br />
{{hc|$> mysql -u root -p|password:}}<br />
{{bc|<br />
CREATE SCHEMA `postfix_db` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci ;<br />
CREATE USER 'postfix_user'@'localhost' IDENTIFIED BY 'hunter2';<br />
GRANT ALL ON `postfix_db`.* TO `postfix_user`@`localhost`;<br />
}}<br />
<br />
=== Postfix ===<br />
There are basically 2 ways for of doing SMTPS. <br />
<br />
One is using the wrapper mode which enables even old/odd clients like Outlook to use TLS. The wrapper mode uses the system service "smtps" which is a non-standard service and runs on port 465. <br />
<br />
The other, more proper method is to use a port that simply enforces TLS without any wrapping. The system service for this is "submission" which is standard and uses port 587.<br />
<br />
For the improper variant uncomment this in {{ic|/etc/postfix/master.cf}}:<br />
smtps inet n - n - - smtpd<br />
-o smtpd_tls_wrappermode=yes<br />
-o smtpd_sasl_auth_enable=yes<br />
<br />
For the proper variant uncomment this in {{ic|/etc/postfix/master.cf}}:<br />
submission inet n - n - - smtpd<br />
-o smtpd_tls_security_level=encrypt<br />
-o smtpd_sasl_auth_enable=yes<br />
<br />
To {{ic|/etc/postfix/main.cf}} append:<br />
relay_domains = *<br />
virtual_alias_maps = proxy:mysql:/etc/postfix/virtual_alias_maps.cf<br />
virtual_mailbox_domains = proxy:mysql:/etc/postfix/virtual_domains_maps.cf<br />
virtual_mailbox_maps = proxy:mysql:/etc/postfix/virtual_mailbox_maps.cf<br />
virtual_mailbox_base = /home/vmail<br />
virtual_mailbox_limit = 512000000<br />
virtual_minimum_uid = 5000<br />
virtual_transport = virtual<br />
virtual_uid_maps = static:5000<br />
virtual_gid_maps = static:5000<br />
local_transport = virtual<br />
local_recipient_maps = $virtual_mailbox_maps<br />
transport_maps = hash:/etc/postfix/transport<br />
<br />
smtpd_sasl_auth_enable = yes<br />
smtpd_sasl_type = dovecot<br />
smtpd_sasl_path = /var/run/dovecot/auth-client<br />
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination<br />
smtpd_sasl_security_options = noanonymous<br />
smtpd_sasl_tls_security_options = $smtpd_sasl_security_options<br />
smtpd_tls_auth_only = yes<br />
smtpd_tls_cert_file = /etc/ssl/private/server.crt<br />
smtpd_tls_key_file = /etc/ssl/private/server.key<br />
smtpd_sasl_local_domain = $mydomain<br />
broken_sasl_auth_clients = yes<br />
smtpd_tls_loglevel = 1<br />
<br />
This references a lot of files that do not even exist yet. Let's create them.<br />
<br />
Edit {{ic|/etc/postfix/virtual_alias_maps.cf}} as new and add:<br />
user = postfix_user<br />
password = hunter2<br />
hosts = localhost<br />
dbname = postfix_db<br />
query = SELECT goto FROM alias WHERE address='%s' AND active = true<br />
<br />
Edit {{ic|/etc/postfix/virtual_domains_maps.cf}} as new and add:<br />
user = postfix_user<br />
password = hunter2<br />
hosts = localhost<br />
dbname = postfix_db<br />
query = SELECT domain FROM domain WHERE domain='%s' AND backupmx = false AND active = true<br />
<br />
Edit {{ic|/etc/postfix/virtual_mailbox_limits.cf}} as new and add:<br />
user = postfix_user<br />
password = hunter2<br />
hosts = localhost<br />
dbname = postfix_db<br />
query = SELECT quota FROM mailbox WHERE username='%s'<br />
<br />
Edit {{ic|/etc/postfix/virtual_mailbox_maps.cf}} as new and add:<br />
user = postfix_user<br />
password = hunter2<br />
hosts = localhost<br />
dbname = postfix_db<br />
query = SELECT maildir FROM mailbox WHERE username='%s' AND active = true<br />
<br />
Run ''postmap'' on ''transport'' to generate its db:<br />
postmap /etc/postfix/transport<br />
<br />
We still need the SSL cert and private key:<br />
cd /etc/ssl/certs<br />
openssl req -new -x509 -newkey rsa:1024 -days 365 -keyout server.key -out server.crt<br />
openssl rsa -in server.key -out server.key<br />
chown nobody:nobody server.key server.crt<br />
chmod 400 server.key<br />
chmod 444 server.crt<br />
mv server.key /etc/ssl/private/<br />
mv server.crt /etc/ssl/private/<br />
<br />
=== Dovecot ===<br />
Start by getting a fresh config file from the pre-existing sample config:<br />
cp /etc/dovecot/dovecot.conf.sample /etc/dovecot/dovecot.conf<br />
<br />
In {{ic|/etc/dovecot/dovecot.conf}} we'll need to do quite some configuration:<br />
protocols = imap pop3<br />
auth_mechanisms = plain<br />
passdb {<br />
driver = sql<br />
args = /etc/dovecot/dovecot-sql.conf<br />
}<br />
userdb sql {<br />
driver = sql<br />
args = /etc/dovecot/dovecot-sql.conf<br />
}<br />
<br />
service auth {<br />
unix_listener auth-client {<br />
group = postfix<br />
mode = 0660<br />
user = postfix<br />
}<br />
user = root<br />
}<br />
<br />
mail_home = /home/vmail/%d/%u<br />
mail_location = maildir:~<br />
<br />
ssl_cert = </etc/ssl/private/server.crt<br />
ssl_key = </etc/ssl/private/server.key<br />
<br />
Now obviously we also need the {{ic|/etc/dovecot/dovecot-sql.conf}} we just referenced in the config above. Go ahead and create a {{ic|/etc/dovecot/dovecot-sql.conf}} with these contents:<br />
driver = mysql<br />
connect = host=localhost dbname=postfix_db user=postfix_user password=hunter2<br />
# The new name for MD5 is MD5-CRYPT so you might need to change this depending on version<br />
default_pass_scheme = MD5-CRYPT<br />
# Get the mailbox<br />
user_query = SELECT '/home/vmail/%d/%u' as home, 'maildir:/home/vmail/%d/%u' as mail, 5000 AS uid, 5000 AS gid, concat('dirsize:storage=', quota) AS quota FROM mailbox WHERE username = '%u' AND active = '1'<br />
# Get the password<br />
password_query = SELECT username as user, password, '/home/vmail/%d/%u' as userdb_home, 'maildir:/home/vmail/%d/%u' as userdb_mail, 5000 as userdb_uid, 5000 as userdb_gid FROM mailbox WHERE username = '%u' AND active = '1'<br />
# If using client certificates for authentication, comment the above and uncomment the following<br />
#password_query = SELECT null AS password, ‘%u’ AS user<br />
<br />
=== PostfixAdmin ===<br />
To install PostfixAdmin, we need to manually get its upstream package and extract it to our web root (or other desired directory). You should use the most recent version available at the time. This article will use the most recent version at the time of writing.<br />
cd /srv/http/<br />
wget http://sourceforge.net/projects/postfixadmin/files/postfixadmin/postfixadmin-2.3.5/postfixadmin-2.3.5.tar.gz/download<br />
tar xzf postfixadmin-2.3.5.tar.gz<br />
cd postfixadmin-2.3.5<br />
<br />
Next, PostfixAdmin needs to be configured. Assuming localhost is the hostname of the machine you are installing this on, navigate to ''http://localhost/postfixadmin-2.3.2/setup.php''. The setup will guide you through the remaining steps to set up PostfixAdmin.<br />
<br />
=== Roundcube ===<br />
As with PostfixAdmin, this article will use the most recent version as of the time of writing. You should always use the most recent version available.<br />
cd /srv/http/<br />
wget http://sourceforge.net/projects/roundcubemail/files/roundcubemail/0.7.2/roundcubemail-0.7.2.tar.gz/download<br />
tar xzf roundcubemail-0.7.2.tar.gz<br />
cd roundcubemail-0.7.2<br />
<br />
Make some directories writable by the webserver:<br />
chown -R http:http temp logs<br />
<br />
Assuming that localhost is your current host, navigate a browser to ''http://localhost/roundcubemail-0.7.2/installer/'' and follow the instructions. You could use the same database for Roundcube that you already used for PostfixAdmin though you shouldn't. For a proper setup, create a second database "roundcube_db" and a "roundcube_user" for use with Roundcube. <br />
<br />
While running the installer, make sure to address the IMAP host with '''tls://localhost/''' instead of just '''localhost'''. Use port 993. Likewise with SMTP, make sure to provide '''ssl://localhost/''' on port 465 if you used the wrapper mode and '''tls://localhost/''' on port 587 if you used the proper TLS mode. See [[#Postfix|here]] for an explanation on that.<br />
<br />
=== rc.conf ===<br />
Make sure your DAEMONS array in {{ic|/etc/rc.conf}} contains:<br />
DAEMONS=( ... dovecot postfix ... )<br />
<br />
== Fire it up ==<br />
Since now hopefully everything is set up correctly, all necessary daemons should be started for a test run:<br />
rc.d start postfix dovecot<br />
<br />
Now for testing purposes, create a domain and mail account in PostfixAdmin. Try to login to this account using Roundcube. Now send yourself a mail.<br />
<br />
== Troubleshooting ==<br />
If you get errors like your imap/pop3 client failing to receive mails, take a look into your /var/log/mail.log file.<br />
It turned out that the maildir /home/vmail/mail@domain.tld is just being created if there is at least one email waiting. Otherwise there wouldn't be any need for the directory.<br />
<br />
==See also==<br />
*[[Courier MTA]]<br />
*[[Postfix]]<br />
*[[SOHO Postfix]]</div>Geshhttps://wiki.archlinux.org/index.php?title=Virtual_user_mail_system_with_Postfix,_Dovecot_and_Roundcube&diff=217321Virtual user mail system with Postfix, Dovecot and Roundcube2012-08-10T01:56:42Z<p>Gesh: Cleaned up bash command</p>
<hr />
<div>[[Category:Web Server]]<br />
<br />
This article describes how to set up a complete virtual user mail system on an Arch Linux system in the simplest manner possible. However, since a mail system consists of many complex components, quite a bit of configuration will still be necessary. Roughly, the components used in this article are Postfix, Dovecot, PostfixAdmin and Roundcube.<br />
<br />
In the end, the provided solution will allow you to use the best currently available security mechanisms, you will be able to send mails using SMTP and SMTPS and receive mails using POP3, POP3S, IMAP and IMAPS. Additionally, configuration will be easy thanks to PostfixAdmin and users will be able to login using Roundcube. What a deal!<br />
<br />
This article assumes that you have a working [[LAMP]] setup as we will need a working Apache2 as well as MYSQL database. Of course, with a few changes to these instructions you could easily use another httpd and database. For the purposes of this tutorial, however, the choice made above will be used. Additionally, the article assumes all-default settings for every package installed below. No changes except for those mentioned will be required.<br />
<br />
Should any unforeseen problems occur, feel free to use the discussion page to voice your problems and I will try to answer.<br />
<br />
== Installation ==<br />
# pacman -S dovecot postfix<br />
<br />
== Configuration ==<br />
=== User ===<br />
For security reasons, a new user should be created to store the mails:<br />
groupadd -g 5000 vmail<br />
useradd -u 5000 -g vmail -s /sbin/nologin -d /home/vmail -m vmail<br />
A gid and uid of 5000 is used in both cases so that we do not run into conflicts with regular users. All your mail will then be stored in '''/home/vmail'''. You could change the home dir to something like '''/var/mail/vmail''' but careful to change this in any configuration below as well.<br />
<br />
=== Database ===<br />
You will need to create an empty database and corresponding user. We will be using PostfixAdmin's tables to fill the database later on. In this article, ''postfix_user'' will have read/write access to ''postfix_db'' using ''hunter2'' for a password. You are expected to create your database and user yourself as shown in the following code. Make sure to assign proper permissions.<br />
<br />
{{hc|$> mysql -u root -p|password:}}<br />
{{bc|<br />
CREATE SCHEMA `postfix_db` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci ;<br />
CREATE USER 'postfix_user'@'localhost' IDENTIFIED BY 'hunter2';<br />
GRANT ALL ON `postfix_db`.* TO `postfix_user`@`localhost`;<br />
}}<br />
<br />
=== Postfix ===<br />
There are basically 2 ways for of doing SMTPS. <br />
<br />
One is using the wrapper mode which enables even old/odd clients like Outlook to use TLS. The wrapper mode uses the system service "smtps" which is a non-standard service and runs on port 465. <br />
<br />
The other, more proper method is to use a port that simply enforces TLS without any wrapping. The system service for this is "submission" which is standard and uses port 587.<br />
<br />
For the improper variant uncomment this in {{ic|/etc/postfix/master.cf}}:<br />
smtps inet n - n - - smtpd<br />
-o smtpd_tls_wrappermode=yes<br />
-o smtpd_sasl_auth_enable=yes<br />
<br />
For the proper variant uncomment this in {{ic|/etc/postfix/master.cf}}:<br />
submission inet n - n - - smtpd<br />
-o smtpd_tls_security_level=encrypt<br />
-o smtpd_sasl_auth_enable=yes<br />
<br />
To {{ic|/etc/postfix/main.cf}} append:<br />
relay_domains = *<br />
virtual_alias_maps = proxy:mysql:/etc/postfix/virtual_alias_maps.cf<br />
virtual_mailbox_domains = proxy:mysql:/etc/postfix/virtual_domains_maps.cf<br />
virtual_mailbox_maps = proxy:mysql:/etc/postfix/virtual_mailbox_maps.cf<br />
virtual_mailbox_base = /home/vmail<br />
virtual_mailbox_limit = 512000000<br />
virtual_minimum_uid = 5000<br />
virtual_transport = virtual<br />
virtual_uid_maps = static:5000<br />
virtual_gid_maps = static:5000<br />
local_transport = virtual<br />
local_recipient_maps = $virtual_mailbox_maps<br />
transport_maps = hash:/etc/postfix/transport<br />
<br />
smtpd_sasl_auth_enable = yes<br />
smtpd_sasl_type = dovecot<br />
smtpd_sasl_path = /var/run/dovecot/auth-client<br />
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination<br />
smtpd_sasl_security_options = noanonymous<br />
smtpd_sasl_tls_security_options = $smtpd_sasl_security_options<br />
smtpd_tls_auth_only = yes<br />
smtpd_tls_cert_file = /etc/ssl/private/server.crt<br />
smtpd_tls_key_file = /etc/ssl/private/server.key<br />
smtpd_sasl_local_domain = $mydomain<br />
broken_sasl_auth_clients = yes<br />
smtpd_tls_loglevel = 1<br />
<br />
This references a lot of files that do not even exist yet. Let's create them.<br />
<br />
Edit {{ic|/etc/postfix/virtual_alias_maps.cf}} as new and add:<br />
user = postfix_user<br />
password = hunter2<br />
hosts = localhost<br />
dbname = postfix_db<br />
query = SELECT goto FROM alias WHERE address='%s' AND active = true<br />
<br />
Edit {{ic|/etc/postfix/virtual_domains_maps.cf}} as new and add:<br />
user = postfix_user<br />
password = hunter2<br />
hosts = localhost<br />
dbname = postfix_db<br />
query = SELECT domain FROM domain WHERE domain='%s' AND backupmx = false AND active = true<br />
<br />
Edit {{ic|/etc/postfix/virtual_mailbox_limits.cf}} as new and add:<br />
user = postfix_user<br />
password = hunter2<br />
hosts = localhost<br />
dbname = postfix_db<br />
query = SELECT quota FROM mailbox WHERE username='%s'<br />
<br />
Edit {{ic|/etc/postfix/virtual_mailbox_maps.cf}} as new and add:<br />
user = postfix_user<br />
password = hunter2<br />
hosts = localhost<br />
dbname = postfix_db<br />
query = SELECT maildir FROM mailbox WHERE username='%s' AND active = true<br />
<br />
Run ''postmap'' on ''transport'' to generate its db:<br />
postmap /etc/postfix/transport<br />
<br />
We still need the SSL cert and private key:<br />
cd /etc/ssl/certs<br />
openssl req -new -x509 -newkey rsa:1024 -days 365 -keyout server.key -out server.crt<br />
openssl rsa -in server.key -out server.key<br />
chown nobody:nobody server.key<br />
chmod 600 server.key<br />
mv server.key /etc/ssl/private/<br />
mv server.crt /etc/ssl/private/<br />
<br />
=== Dovecot ===<br />
Start by getting a fresh config file from the pre-existing sample config:<br />
cp /etc/dovecot/dovecot.conf.sample /etc/dovecot/dovecot.conf<br />
<br />
In {{ic|/etc/dovecot/dovecot.conf}} we'll need to do quite some configuration:<br />
protocols = imap pop3<br />
auth_mechanisms = plain<br />
passdb {<br />
driver = sql<br />
args = /etc/dovecot/dovecot-sql.conf<br />
}<br />
userdb sql {<br />
driver = sql<br />
args = /etc/dovecot/dovecot-sql.conf<br />
}<br />
<br />
service auth {<br />
unix_listener auth-client {<br />
group = postfix<br />
mode = 0660<br />
user = postfix<br />
}<br />
user = root<br />
}<br />
<br />
mail_home = /home/vmail/%d/%u<br />
mail_location = maildir:~<br />
<br />
ssl_cert = </etc/ssl/private/server.crt<br />
ssl_key = </etc/ssl/private/server.key<br />
<br />
Now obviously we also need the {{ic|/etc/dovecot/dovecot-sql.conf}} we just referenced in the config above. Go ahead and create a {{ic|/etc/dovecot/dovecot-sql.conf}} with these contents:<br />
driver = mysql<br />
connect = host=localhost dbname=postfix_db user=postfix_user password=hunter2<br />
# The new name for MD5 is MD5-CRYPT so you might need to change this depending on version<br />
default_pass_scheme = MD5-CRYPT<br />
# Get the mailbox<br />
user_query = SELECT '/home/vmail/%d/%u' as home, 'maildir:/home/vmail/%d/%u' as mail, 5000 AS uid, 5000 AS gid, concat('dirsize:storage=', quota) AS quota FROM mailbox WHERE username = '%u' AND active = '1'<br />
# Get the password<br />
password_query = SELECT username as user, password, '/home/vmail/%d/%u' as userdb_home, 'maildir:/home/vmail/%d/%u' as userdb_mail, 5000 as userdb_uid, 5000 as userdb_gid FROM mailbox WHERE username = '%u' AND active = '1'<br />
# If using client certificates for authentication, comment the above and uncomment the following<br />
#password_query = SELECT null AS password, ‘%u’ AS user<br />
<br />
=== PostfixAdmin ===<br />
To install PostfixAdmin, we need to manually get its upstream package and extract it to our web root (or other desired directory). You should use the most recent version available at the time. This article will use the most recent version at the time of writing.<br />
cd /srv/http/<br />
wget http://sourceforge.net/projects/postfixadmin/files/postfixadmin/postfixadmin-2.3.5/postfixadmin-2.3.5.tar.gz/download<br />
tar xzf postfixadmin-2.3.5.tar.gz<br />
cd postfixadmin-2.3.5<br />
<br />
Next, PostfixAdmin needs to be configured. Assuming localhost is the hostname of the machine you are installing this on, navigate to ''http://localhost/postfixadmin-2.3.2/setup.php''. The setup will guide you through the remaining steps to set up PostfixAdmin.<br />
<br />
=== Roundcube ===<br />
As with PostfixAdmin, this article will use the most recent version as of the time of writing. You should always use the most recent version available.<br />
cd /srv/http/<br />
wget http://sourceforge.net/projects/roundcubemail/files/roundcubemail/0.7.2/roundcubemail-0.7.2.tar.gz/download<br />
tar xzf roundcubemail-0.7.2.tar.gz<br />
cd roundcubemail-0.7.2<br />
<br />
Make some directories writable by the webserver:<br />
chown -R http:http temp logs<br />
<br />
Assuming that localhost is your current host, navigate a browser to ''http://localhost/roundcubemail-0.7.2/installer/'' and follow the instructions. You could use the same database for Roundcube that you already used for PostfixAdmin though you shouldn't. For a proper setup, create a second database "roundcube_db" and a "roundcube_user" for use with Roundcube. <br />
<br />
While running the installer, make sure to address the IMAP host with '''tls://localhost/''' instead of just '''localhost'''. Use port 993. Likewise with SMTP, make sure to provide '''ssl://localhost/''' on port 465 if you used the wrapper mode and '''tls://localhost/''' on port 587 if you used the proper TLS mode. See [[#Postfix|here]] for an explanation on that.<br />
<br />
=== rc.conf ===<br />
Make sure your DAEMONS array in {{ic|/etc/rc.conf}} contains:<br />
DAEMONS=( ... dovecot postfix ... )<br />
<br />
== Fire it up ==<br />
Since now hopefully everything is set up correctly, all necessary daemons should be started for a test run:<br />
rc.d start postfix dovecot<br />
<br />
Now for testing purposes, create a domain and mail account in PostfixAdmin. Try to login to this account using Roundcube. Now send yourself a mail.<br />
<br />
== Troubleshooting ==<br />
If you get errors like your imap/pop3 client failing to receive mails, take a look into your /var/log/mail.log file.<br />
It turned out that the maildir /home/vmail/mail@domain.tld is just being created if there is at least one email waiting. Otherwise there wouldn't be any need for the directory.<br />
<br />
==See also==<br />
*[[Courier MTA]]<br />
*[[Postfix]]<br />
*[[SOHO Postfix]]</div>Geshhttps://wiki.archlinux.org/index.php?title=Talk:Virtual_user_mail_system_with_Postfix,_Dovecot_and_Roundcube&diff=217320Talk:Virtual user mail system with Postfix, Dovecot and Roundcube2012-08-10T01:35:14Z<p>Gesh: Certificate ownership</p>
<hr />
<div>== This is your friendly original author speaking. ==<br />
<br />
Hey there, hopefully there are no problems while working down the guide. If there are, feel free to write them down here and I will come to them! However, please *do* try to correct any issues you find in the guide yourself if you can.<br />
--[[User:Svenstaro|Svenstaro]] 12:39, 19 September 2010 (EDT)<br />
<br />
<br />
Expanded the Database section with the code needed to create a rudimentary db and dba for pfadmin to work on and removed the "Needs expansion" banner.<br />
--[[User:Justforgetme|Justforgetme]] ([[User talk:Justforgetme|talk]]) 12:02, 19 June 2012 (UTC)<br />
<br />
KingX did exactly the updates I had in mind to do tonight, great job. Now the SQL queries will actually work out of the box for $domain/$user@$domain maildirs/mailschemes (which is what almost everyone wants to use afaik). Lets hope this doesn't lock down the how to too much.<br />
--[[User:Justforgetme|Justforgetme]] ([[User talk:Justforgetme|talk]]) 22:28, 22 June 2012 (UTC)<br />
<br />
Hey awesome!! I am glad I am not the only one looking at this page. :) I am planning on expanding the postfixadmin and roundcubemail section. Just want to touch base on one thing, so postfixadmin and postfix share the same db right? in this case postfix_db? and Roundcube has its own db. The original author mentioned that "we will use postfixadmin to fill the tables later", but never really clarified or mentioned how... or I missed it. I think that can be one thing that should be clarified also.--[[User:KingX|KingX]] ([[User talk:KingX|talk]]) 22:51, 22 June 2012 (UTC)<br />
<br />
postfixadmin and roundcube have different databases. Both are populated via the http GUI and hold the meta configuration. For example roundcube will hold user identities (name, sig), searches, contacts, contactgroups (aka mail lists), a dictioary etc. Most of these are only populated when you use the Http interface, since roundcube doesn't actually come into contact with the mailboxes that postfix(and dovecot) uses. The postfix db, in my installations usually just called postfix - no need for extra designation since you already know it is a DB - holds more interesting data since there you will find routing paths (what mailbox each alias maps to), usage information (like quotas), vacation data, hashed login credentials etc.. I don't think it makes sense to drill deeper into that topic inside the tutorial since even the admin wont be much in touch with those dbs and debugging roundcube and dovecot (&pfadmin) issues would really call for a separate document. What are You interested in adding?<br />
--[[User:Justforgetme|Justforgetme]] ([[User talk:Justforgetme|talk]]) 16:33, 29 June 2012 (UTC)<br />
<br />
Ok yeh I have a perfectly working mailserver now. :) I was just going to expand the roundcube and postfixadmin section a little, as now roundcube is available in official repo so need to grab the source manually. And just add some hints for people trying to configure postfixadmin. --[[User:KingX|KingX]] ([[User talk:KingX|talk]]) 22:51, 29 June 2012 (UTC)<br />
<br />
... I have undone the modification of user [[User:Gesh|Gesh]]. The relay_domains variable in this specific postfix setup should only be relevant as an additional filter since the MT authentication/authorization is done via the database. Correct me if I'm wrong but I think this is necessary in case of dynamic multi domain hosting. The resulting server does not operate as an open relay unless you add a tld wildcard for every tld you want to OR for in the db ;-)<br />
--[[User:Justforgetme|Justforgetme]] ([[User talk:Justforgetme|talk]]) 15:49, 9 August 2012 (UTC)<br />
<br />
[http://wiki2.dovecot.org/SSL/DovecotConfiguration Dovecot configuration] suggests setting the certs 0444 for the .crt and 0400 for the .key, but the wiki suggests 0644 and 0600, respectively. Personally, I do not see why anyone should have write permissions on the certs, esp. since they're not meant to be modified. Suggestions? --[[User:Gesh|Gesh]] ([[User talk:Gesh|talk]]) 23:30, 9 August 2012 (UTC)<br />
<br />
Hmm... I think you are right Gesh. I can't fathom how making the certs read only could damage the setup.<br />
--[[User:Justforgetme|Justforgetme]] ([[User talk:Justforgetme|talk]]) 00:10, 10 August 2012 (UTC)<br />
<br />
Also, shouldn't the chown nobody:nobody also be executed on the .crt file? I cannot understand the rationale of having it owned by root. At least with system-configuration files, you'd want both that root will be able to edit them and that *only* root be able to edit them. --[[User:Gesh|Gesh]] ([[User talk:Gesh|talk]]) 01:35, 10 August 2012 (UTC)</div>Geshhttps://wiki.archlinux.org/index.php?title=Talk:Virtual_user_mail_system_with_Postfix,_Dovecot_and_Roundcube&diff=217314Talk:Virtual user mail system with Postfix, Dovecot and Roundcube2012-08-09T23:30:07Z<p>Gesh: Certificate permissions</p>
<hr />
<div>== This is your friendly original author speaking. ==<br />
<br />
Hey there, hopefully there are no problems while working down the guide. If there are, feel free to write them down here and I will come to them! However, please *do* try to correct any issues you find in the guide yourself if you can.<br />
--[[User:Svenstaro|Svenstaro]] 12:39, 19 September 2010 (EDT)<br />
<br />
<br />
Expanded the Database section with the code needed to create a rudimentary db and dba for pfadmin to work on and removed the "Needs expansion" banner.<br />
--[[User:Justforgetme|Justforgetme]] ([[User talk:Justforgetme|talk]]) 12:02, 19 June 2012 (UTC)<br />
<br />
KingX did exactly the updates I had in mind to do tonight, great job. Now the SQL queries will actually work out of the box for $domain/$user@$domain maildirs/mailschemes (which is what almost everyone wants to use afaik). Lets hope this doesn't lock down the how to too much.<br />
--[[User:Justforgetme|Justforgetme]] ([[User talk:Justforgetme|talk]]) 22:28, 22 June 2012 (UTC)<br />
<br />
Hey awesome!! I am glad I am not the only one looking at this page. :) I am planning on expanding the postfixadmin and roundcubemail section. Just want to touch base on one thing, so postfixadmin and postfix share the same db right? in this case postfix_db? and Roundcube has its own db. The original author mentioned that "we will use postfixadmin to fill the tables later", but never really clarified or mentioned how... or I missed it. I think that can be one thing that should be clarified also.--[[User:KingX|KingX]] ([[User talk:KingX|talk]]) 22:51, 22 June 2012 (UTC)<br />
<br />
postfixadmin and roundcube have different databases. Both are populated via the http GUI and hold the meta configuration. For example roundcube will hold user identities (name, sig), searches, contacts, contactgroups (aka mail lists), a dictioary etc. Most of these are only populated when you use the Http interface, since roundcube doesn't actually come into contact with the mailboxes that postfix(and dovecot) uses. The postfix db, in my installations usually just called postfix - no need for extra designation since you already know it is a DB - holds more interesting data since there you will find routing paths (what mailbox each alias maps to), usage information (like quotas), vacation data, hashed login credentials etc.. I don't think it makes sense to drill deeper into that topic inside the tutorial since even the admin wont be much in touch with those dbs and debugging roundcube and dovecot (&pfadmin) issues would really call for a separate document. What are You interested in adding?<br />
--[[User:Justforgetme|Justforgetme]] ([[User talk:Justforgetme|talk]]) 16:33, 29 June 2012 (UTC)<br />
<br />
Ok yeh I have a perfectly working mailserver now. :) I was just going to expand the roundcube and postfixadmin section a little, as now roundcube is available in official repo so need to grab the source manually. And just add some hints for people trying to configure postfixadmin. --[[User:KingX|KingX]] ([[User talk:KingX|talk]]) 22:51, 29 June 2012 (UTC)<br />
<br />
... I have undone the modification of user [[User:Gesh|Gesh]]. The relay_domains variable in this specific postfix setup should only be relevant as an additional filter since the MT authentication/authorization is done via the database. Correct me if I'm wrong but I think this is necessary in case of dynamic multi domain hosting. The resulting server does not operate as an open relay unless you add a tld wildcard for every tld you want to OR for in the db ;-)<br />
--[[User:Justforgetme|Justforgetme]] ([[User talk:Justforgetme|talk]]) 15:49, 9 August 2012 (UTC)<br />
<br />
[http://wiki2.dovecot.org/SSL/DovecotConfiguration Dovecot configuration] suggests setting the certs 0444 for the .crt and 0400 for the .key, but the wiki suggests 0644 and 0600, respectively. Personally, I do not see why anyone should have write permissions on the certs, esp. since they're not meant to be modified. Suggestions? --[[User:Gesh|Gesh]] ([[User talk:Gesh|talk]]) 23:30, 9 August 2012 (UTC)</div>Geshhttps://wiki.archlinux.org/index.php?title=Virtual_user_mail_system_with_Postfix,_Dovecot_and_Roundcube&diff=217155Virtual user mail system with Postfix, Dovecot and Roundcube2012-08-09T01:02:10Z<p>Gesh: removed relay_domains = * <--- This causes Postfix to act as an open mail relay, which is probably unwanted</p>
<hr />
<div>[[Category:Web Server]]<br />
<br />
This article describes how to set up a complete virtual user mail system on an Arch Linux system in the simplest manner possible. However, since a mail system consists of many complex components, quite a bit of configuration will still be necessary. Roughly, the components used in this article are Postfix, Dovecot, PostfixAdmin and Roundcube.<br />
<br />
In the end, the provided solution will allow you to use the best currently available security mechanisms, you will be able to send mails using SMTP and SMTPS and receive mails using POP3, POP3S, IMAP and IMAPS. Additionally, configuration will be easy thanks to PostfixAdmin and users will be able to login using Roundcube. What a deal!<br />
<br />
This article assumes that you have a working [[LAMP]] setup as we will need a working Apache2 as well as MYSQL database. Of course, with a few changes to these instructions you could easily use another httpd and database. For the purposes of this tutorial, however, the choice made above will be used. Additionally, the article assumes all-default settings for every package installed below. No changes except for those mentioned will be required.<br />
<br />
Should any unforeseen problems occur, feel free to use the discussion page to voice your problems and I will try to answer.<br />
<br />
== Installation ==<br />
# pacman -S dovecot postfix<br />
<br />
== Configuration ==<br />
=== User ===<br />
For security reasons, a new user should be created to store the mails:<br />
groupadd -g 5000 vmail<br />
useradd -u 5000 -g vmail -s /sbin/nologin -d /home/vmail -m vmail<br />
A gid and uid of 5000 is used in both cases so that we do not run into conflicts with regular users. All your mail will then be stored in '''/home/vmail'''. You could change the home dir to something like '''/var/mail/vmail''' but careful to change this in any configuration below as well.<br />
<br />
=== Database ===<br />
You will need to create an empty database and corresponding user. We will be using PostfixAdmin's tables to fill the database later on. In this article, ''postfix_user'' will have read/write access to ''postfix_db'' using ''hunter2'' for a password. You are expected to create your database and user yourself as shown in the following code. Make sure to assign proper permissions.<br />
<br />
{{hc|$> mysql -u root -p|password:}}<br />
{{bc|<br />
CREATE SCHEMA `postfix_db` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci ;<br />
CREATE USER 'postfix_user'@'localhost' IDENTIFIED BY 'hunter2';<br />
GRANT ALL ON `postfix_db`.* TO `postfix_user`@`localhost`;<br />
}}<br />
<br />
=== Postfix ===<br />
There are basically 2 ways for of doing SMTPS. <br />
<br />
One is using the wrapper mode which enables even old/odd clients like Outlook to use TLS. The wrapper mode uses the system service "smtps" which is a non-standard service and runs on port 465. <br />
<br />
The other, more proper method is to use a port that simply enforces TLS without any wrapping. The system service for this is "submission" which is standard and uses port 587.<br />
<br />
For the improper variant uncomment this in {{ic|/etc/postfix/master.cf}}:<br />
smtps inet n - n - - smtpd<br />
-o smtpd_tls_wrappermode=yes<br />
-o smtpd_sasl_auth_enable=yes<br />
<br />
For the proper variant uncomment this in {{ic|/etc/postfix/master.cf}}:<br />
submission inet n - n - - smtpd<br />
-o smtpd_tls_security_level=encrypt<br />
-o smtpd_sasl_auth_enable=yes<br />
<br />
To {{ic|/etc/postfix/main.cf}} append:<br />
virtual_alias_maps = proxy:mysql:/etc/postfix/virtual_alias_maps.cf<br />
virtual_mailbox_domains = proxy:mysql:/etc/postfix/virtual_domains_maps.cf<br />
virtual_mailbox_maps = proxy:mysql:/etc/postfix/virtual_mailbox_maps.cf<br />
virtual_mailbox_base = /home/vmail<br />
virtual_mailbox_limit = 512000000<br />
virtual_minimum_uid = 5000<br />
virtual_transport = virtual<br />
virtual_uid_maps = static:5000<br />
virtual_gid_maps = static:5000<br />
local_transport = virtual<br />
local_recipient_maps = $virtual_mailbox_maps<br />
transport_maps = hash:/etc/postfix/transport<br />
<br />
smtpd_sasl_auth_enable = yes<br />
smtpd_sasl_type = dovecot<br />
smtpd_sasl_path = /var/run/dovecot/auth-client<br />
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination<br />
smtpd_sasl_security_options = noanonymous<br />
smtpd_sasl_tls_security_options = $smtpd_sasl_security_options<br />
smtpd_tls_auth_only = yes<br />
smtpd_tls_cert_file = /etc/ssl/private/server.crt<br />
smtpd_tls_key_file = /etc/ssl/private/server.key<br />
smtpd_sasl_local_domain = $mydomain<br />
broken_sasl_auth_clients = yes<br />
smtpd_tls_loglevel = 1<br />
<br />
This references a lot of files that do not even exist yet. Let's create them.<br />
<br />
Edit {{ic|/etc/postfix/virtual_alias_maps.cf}} as new and add:<br />
user = postfix_user<br />
password = hunter2<br />
hosts = localhost<br />
dbname = postfix_db<br />
query = SELECT goto FROM alias WHERE address='%s' AND active = true<br />
<br />
Edit {{ic|/etc/postfix/virtual_domains_maps.cf}} as new and add:<br />
user = postfix_user<br />
password = hunter2<br />
hosts = localhost<br />
dbname = postfix_db<br />
query = SELECT domain FROM domain WHERE domain='%s' AND backupmx = false AND active = true<br />
<br />
Edit {{ic|/etc/postfix/virtual_mailbox_limits.cf}} as new and add:<br />
user = postfix_user<br />
password = hunter2<br />
hosts = localhost<br />
dbname = postfix_db<br />
query = SELECT quota FROM mailbox WHERE username='%s'<br />
<br />
Edit {{ic|/etc/postfix/virtual_mailbox_maps.cf}} as new and add:<br />
user = postfix_user<br />
password = hunter2<br />
hosts = localhost<br />
dbname = postfix_db<br />
query = SELECT maildir FROM mailbox WHERE username='%s' AND active = true<br />
<br />
Run ''postmap'' on ''transport'' to generate its db:<br />
postmap /etc/postfix/transport<br />
<br />
We still need the SSL cert and private key:<br />
cd /etc/ssl/certs<br />
openssl req -new -x509 -newkey rsa:1024 -days 365 -keyout server.key -out server.crt<br />
openssl rsa -in server.key -out server.key<br />
chown nobody:nobody server.key<br />
chmod 600 server.key<br />
mv server.key /etc/ssl/private/<br />
mv server.crt /etc/ssl/private/<br />
<br />
=== Dovecot ===<br />
Start by getting a fresh config file from the pre-existing sample config:<br />
cp /etc/dovecot/dovecot.conf.sample /etc/dovecot/dovecot.conf<br />
<br />
In {{ic|/etc/dovecot/dovecot.conf}} we'll need to do quite some configuration:<br />
protocols = imap pop3<br />
auth_mechanisms = plain<br />
passdb {<br />
driver = sql<br />
args = /etc/dovecot/dovecot-sql.conf<br />
}<br />
userdb sql {<br />
driver = sql<br />
args = /etc/dovecot/dovecot-sql.conf<br />
}<br />
<br />
service auth {<br />
unix_listener auth-client {<br />
group = postfix<br />
mode = 0660<br />
user = postfix<br />
}<br />
user = root<br />
}<br />
<br />
mail_home = /home/vmail/%d/%u<br />
mail_location = maildir:~<br />
<br />
ssl_cert = </etc/ssl/private/server.crt<br />
ssl_key = </etc/ssl/private/server.key<br />
<br />
Now obviously we also need the {{ic|/etc/dovecot/dovecot-sql.conf}} we just referenced in the config above. Go ahead and create a {{ic|/etc/dovecot/dovecot-sql.conf}} with these contents:<br />
driver = mysql<br />
connect = host=localhost dbname=postfix_db user=postfix_user password=hunter2<br />
# The new name for MD5 is MD5-CRYPT so you might need to change this depending on version<br />
default_pass_scheme = MD5-CRYPT<br />
# Get the mailbox<br />
user_query = SELECT '/home/vmail/%d/%u' as home, 'maildir:/home/vmail/%d/%u' as mail, 5000 AS uid, 5000 AS gid, concat('dirsize:storage=', quota) AS quota FROM mailbox WHERE username = '%u' AND active = '1'<br />
# Get the password<br />
password_query = SELECT username as user, password, '/home/vmail/%d/%u' as userdb_home, 'maildir:/home/vmail/%d/%u' as userdb_mail, 5000 as userdb_uid, 5000 as userdb_gid FROM mailbox WHERE username = '%u' AND active = '1'<br />
# If using client certificates for authentication, comment the above and uncomment the following<br />
#password_query = SELECT null AS password, ‘%u’ AS user<br />
<br />
=== PostfixAdmin ===<br />
To install PostfixAdmin, we need to manually get its upstream package and extract it to our web root (or other desired directory). You should use the most recent version available at the time. This article will use the most recent version at the time of writing.<br />
cd /srv/http/<br />
wget http://sourceforge.net/projects/postfixadmin/files/postfixadmin/postfixadmin-2.3.5/postfixadmin-2.3.5.tar.gz/download<br />
tar xzf postfixadmin-2.3.5.tar.gz<br />
cd postfixadmin-2.3.5<br />
<br />
Next, PostfixAdmin needs to be configured. Assuming localhost is the hostname of the machine you are installing this on, navigate to ''http://localhost/postfixadmin-2.3.2/setup.php''. The setup will guide you through the remaining steps to set up PostfixAdmin.<br />
<br />
=== Roundcube ===<br />
As with PostfixAdmin, this article will use the most recent version as of the time of writing. You should always use the most recent version available.<br />
cd /srv/http/<br />
wget http://sourceforge.net/projects/roundcubemail/files/roundcubemail/0.7.2/roundcubemail-0.7.2.tar.gz/download<br />
tar xzf roundcubemail-0.7.2.tar.gz<br />
cd roundcubemail-0.7.2<br />
<br />
Make some directories writable by the webserver:<br />
chown -R http:http temp logs<br />
<br />
Assuming that localhost is your current host, navigate a browser to ''http://localhost/roundcubemail-0.7.2/installer/'' and follow the instructions. You could use the same database for Roundcube that you already used for PostfixAdmin though you shouldn't. For a proper setup, create a second database "roundcube_db" and a "roundcube_user" for use with Roundcube. <br />
<br />
While running the installer, make sure to address the IMAP host with '''tls://localhost/''' instead of just '''localhost'''. Use port 993. Likewise with SMTP, make sure to provide '''ssl://localhost/''' on port 465 if you used the wrapper mode and '''tls://localhost/''' on port 587 if you used the proper TLS mode. See [[#Postfix|here]] for an explanation on that.<br />
<br />
=== rc.conf ===<br />
Make sure your DAEMONS array in {{ic|/etc/rc.conf}} contains:<br />
DAEMONS=( ... dovecot postfix ... )<br />
<br />
== Fire it up ==<br />
Since now hopefully everything is set up correctly, all necessary daemons should be started for a test run:<br />
for daemon in dovecot postfix; do /etc/rc.d/$daemon start; done<br />
<br />
Now for testing purposes, create a domain and mail account in PostfixAdmin. Try to login to this account using Roundcube. Now send yourself a mail.<br />
<br />
== Troubleshooting ==<br />
If you get errors like your imap/pop3 client failing to receive mails, take a look into your /var/log/mail.log file.<br />
It turned out that the maildir /home/vmail/mail@domain.tld is just being created if there is at least one email waiting. Otherwise there wouldn't be any need for the directory.<br />
<br />
==See also==<br />
*[[Courier MTA]]<br />
*[[Postfix]]<br />
*[[SOHO Postfix]]</div>Gesh