-
-
Notifications
You must be signed in to change notification settings - Fork 1
/
index.html
665 lines (615 loc) · 21.7 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<base target="_blank" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<meta name="referrer" content="same-origin" />
<meta
name="google-site-verification"
content="843HIjF63-uJN0UrleQDJudytAPWccj3FfyOMDXiqp4"
/>
<title>Use the XDG Base Directory Specification!</title>
<meta name="title" content="Use the XDG Base Directory Specification!" />
<meta
name="description"
content="The XDG Base Directory Specification specifies the directories to store user application data on Linux. Use it!"
/>
<meta property="og:type" content="website" />
<meta property="og:title" content="Use the XDG Base Directory Specification!" />
<meta
property="og:description"
content="The XDG Base Directory Specification specifies the directories to store user application data on Linux. Use it!"
/>
<meta property="twitter:card" content="summary_large_image" />
<meta property="twitter:title" content="Use the XDG Base Directory Specification!" />
<meta
property="twitter:description"
content="The XDG Base Directory Specification specifies the directories to store user application data on Linux. Use it!"
/>
<title>Use the XDG Base Dir Spec</title>
<script
data-goatcounter="https://xdgbasedirectoryspecification-com.goatcounter.com/count"
async
src="https://gc.zgo.at/count.js"
></script>
<style>
.ls-long,
.ls-short {
overflow: auto;
max-height: 300px;
display: inline-block;
max-width: 100%;
}
ul > p,
ol > p {
margin-inline-start: 10px;
}
.compliant-software span {
display: inline-block;
padding: 3px;
margin: 2px;
border-radius: 3px;
background-color: #f1f3f5;
}
main {
max-width: 1200px;
}
</style>
<link rel="stylesheet" href="./fox-light.min.css" />
</head>
<body>
<h1>
<b
>Use the
<a
class="title"
href="https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html"
>XDG Base Directory Specification</a
></b
>!
</h1>
<main>
<h2>Why?</h2>
<p>Look at your home</p>
<pre
class="ls-long"
><code>$ find ~ -mindepth 1 -maxdepth 1 -type f -printf '%f\n' -or -type d -printf '%f/\n'
.alsoftrc
.android/
.ansible/
.aqbanking/
.audacity-data/
.bashrc
.cache/
.choosenim/
.code-d/
.config/
config/
.cpan/
data/
Desktop/
Downloads/
Documents/
.eclipse/
.elementary/
.emacs.d/
.emulator_console_auth_token
.flutter
.flutter_tool_state
.gem/
.ghc/
.ghidra/
.gnome/
.gnupg/
.godot/
.gore/
.gradle/
.gsutil/
.guestfish
.heekscad
.helioslauncher/
HomeBank-20210521.bak
HomeBank-20210607.bak
HomeBank-20210611.bak
.hushlogin
.idapro/
.ivy2/
.java/
javasharedresources/
.kb/
.kube/
.lldb/
.local/
.lunarclient/
.lyxauth
.m2/
macOS.vdi
.mcfly/
.metals/
.minecraft/
.mono/
.mozilla
.mputils/
.mume/
Music/
.omnisharp/
.ort/
.osc_cookiejar
.pack/
.paradoxlauncher/
.parsec/
Pictures/
.pki/
.pm2/
.profile
.pythonhist
.sbt/
.scim/
.ssh/
.steam/
.steampath
.steampid
.step/
.subversion/
.swt/
.tooling/
'Universe Sandbox'/
Videos/
.vscode/
.w3m/
.wine/
.xinitrc
.yarnrc
.zcompdump
.zoom/
.zshenv</code></pre>
<p>What if your house was clean and tidy?</p>
<pre
class="ls-short"
><code>$ find ~ -mindepth 1 -maxdepth 1 -type f -printf '%f\n' -or -type d -printf '%f/\n'
.bashrc
.cache/
.config/
Desktop/
Downloads/
Documents/
.local/
Music/
Pictures/
.profile
Videos/</code></pre>
<p>
End users of your application (and hopefully yourself, as well) want a clean home
directory. Instead of having files like
<code>~/.gitconfig</code> scattered chaotically in the home folder, it would be
better for them to reside in a dedicated configuration directory.
</p>
<p>
I like how
<a href="https://0x46.net/thoughts/2019/02/01/dotfile-madness">Filip</a> from
<code>0x46.net</code> explained the issue from the perspective of a user:
</p>
<figure>
<blockquote cite="https://0x46.net/thoughts/2019/02/01/dotfile-madness">
<p>
My own home directory contains 25 ordinary files and 144 hidden files. The
dotfiles contain data that doesn't belong to me: it belongs to the programmers
whose programs decided to hijack the primary location designed as a storage
for my personal files. I can't place those dotfiles anywhere else and they
will appear again if I try to delete them. All I can do is sit here knowing
that in the darkness, behind the scenes, they are there. . . . I dread the day
in which I will hear a loud knock on my door and one of those programmers will
barge in informing me that he is going to store a piece of his furniture in
the middle of my living room, If I don't mind.
</p>
</blockquote>
<figcaption>Filip from <cite>0x46.net</cite></figcaption>
</figure>
<p>
Succinctly, following the spec means (by the very least) your application files
are nearly categorized in subdirectories of the home folder. For instance,
locations of cache files default to <code>~/.cache</code> while locations of
config files default to <code>~/.config</code>, etc.
</p>
<h3>Benefits</h3>
<p>
If you aren't already sold on a clean home directory, there are additional
benefits.
</p>
<ul>
<li>Easier to create backups</li>
<p>
Since several directories (ex. <code>~/.config</code>, by default) represent a
discrete class of application files, it is much easier to make rules for a
specific category of files during backup.
</p>
<li>Easier to share configuration settings</li>
<p>
Since all settings are in a single directory, they can more easily be shared
across computer systems.
</p>
<li>Easier to isolate application state</li>
<p>
Since all data specific to a single machine is in a single directory, you can
easily avoid sharing it between systems when sharing data or backups.
</p>
<li>Easier to temporarily ignore config</li>
<p>
Not all applications have a <code>--no-config</code> option (especially GUI
applications), and those that do have a <code>--config</code> option do not
always work when using <code>/dev/null</code> as a file, shell process
substitution, or a simple empty file. It is easiest to set
<code>XDG_CONFIG_HOME=/tmp/dir</code>.
</p>
<li>Easier to implement ACL</li>
<p>
It can be difficult to constrain system access for an application that writes
files directly in <code>$HOME</code>. Since all directories are specific to a
particular application, implementing access control patterns is easier.
</p>
<li>Decreased reliance on hard-coded paths (flexibility + composability)</li>
</ul>
<p>
As a more concrete example, imagine that <code>/etc</code> did not exist -
configuration would be chaotically scattered about in a way similar to how
<code>$HOME</code> exists today. But, because we have
<code>/etc</code> specifically designated as a directory for config files (along
with other directories) by the
<a href="https://refspecs.linuxfoundation.org/fhs.shtml"
>File Hierarchy Standard</a
>, it is <i>significantly</i> easier to locate, edit, and backup system files
<i>across machines</i>. Those ergonomics should not just exist for system-level
files, but for the user-level as well.
</p>
<p>
Thus, I implore, I <i>beg</i> all you application developers to implement the
<a
href="https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html"
>XDG Base Directory Specification</a
>.
</p>
<h2>How?</h2>
<p>
First, categorize the files that your program needs to write into four categories:
</p>
<ol>
<li><i>Configuration</i></li>
<p>
Configuration files that affect the behavior of an program. Even if the
configuration file is not meant to be human-editable, it likely belongs here.
</p>
<li><i>Data</i></li>
<p>
General files and data that is inherently portable across computers. Examples
include fonts, files downloaded from the internet, and
<a
href="https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html"
>desktop entries</a
>.
</p>
<li><i>State</i></li>
<p>
Files that hold the state of the application. This may include logs, command
history, recently used files, and game save data. In other words, if the data is
unique for a given machine, the file belongs here.
</p>
<li><i>Cache</i></li>
<p>Cache files.</p>
</ol>
<p>
Each aforementioned category is mapped to a special environment variable, which is
the directory that contains all files of that category. For example,
"Configuration" files are all stored in <code>$XDG_CONFIG_HOME</code>. If that
environment variable is invalid, then the default value of
<code>$HOME/.config</code> should be used instead. See the full table below:
</p>
<table>
<tr>
<th>Category</th>
<th>Environment Variable</th>
<th>Default Value</th>
<th>
<a href="https://refspecs.linuxfoundation.org/fhs.shtml">FHS</a> Approximation
</th>
</tr>
<tr>
<td>Configuration</td>
<td><code>$XDG_CONFIG_HOME</code></td>
<td><code>$HOME/.config</code></td>
<td><code>/etc</code></td>
</tr>
<tr>
<td>Data</td>
<td><code>$XDG_DATA_HOME</code></td>
<td><code>$HOME/.local/share</code></td>
<td><code>/usr/share</code></td>
</tr>
<tr>
<td>State</td>
<td><code>$XDG_STATE_HOME</code></td>
<td><code>$HOME/.local/state</code></td>
<td><code>/var/lib</code></td>
</tr>
<tr>
<td>Cache</td>
<td><code>$XDG_CACHE_HOME</code></td>
<td><code>$HOME/.cache</code></td>
<td><code>/var/cache</code></td>
</tr>
</table>
<p>There are three ways the environment variable can be invalid:</p>
<ol>
<li>If it is unset (<code>unset XDG_CONFIG_HOME</code>)</li>
<li>If it is set to an empty value (<code>XDG_CONFIG_HOME=""</code>)</li>
<li>If it is not an absolute path (<code>XDG_CONFIG_HOME="./config"</code>)</li>
</ol>
<h2>Code examples</h2>
<p>
Now that you're acquainted with the standard, you probably want to sees some code
examples. The following programs are for <b><i>Linux only</i></b> (See the FAQ
below for details on MacOS and Windows). Of course, if you are actually writing a
program, I recommend using a library.
</p>
<p>
The following is Go 1.13+ code. Note that it does not use
<a href="https://pkg.go.dev/os#UserConfigDir">os.UserConfigDir</a> (<a
href="https://github.com/golang/go/blob/90860e0c3110ac5898dfe8e0e0fafd0aea8d979a/src/os/file.go#L444"
>Source</a
>) since that does not silently ignore non-absolute paths as per the spec
</p>
<details>
<summary>Show Go</summary>
<pre>
package main
import (
"os"
"fmt"
"log"
"path/filepath"
)
func getConfigDir() (string, error) {
configDir := os.Getenv("XDG_CONFIG_HOME")
// If the value of the environment variable is unset, empty, or not an absolute path, use the default
if configDir == "" || configDir[0:1] != "/" {
homeDir, err := os.UserHomeDir()
if err != nil {
return "", err
}
return filepath.Join(homeDir, ".config", "my-application-name"), nil
}
// The value of the environment variable is valid; use it
return filepath.Join(configDir, "my-application-name"), nil
}
func main() {
config_dir, err := getConfigDir()
if err != nil {
panic(err)
}
fmt.Println(config_dir)
}</pre
>
</details>
<p>
The following is Python 3.5+ code. It uses
<a href="https://docs.python.org/3/library/pathlib.html#pathlib.Path.home"
>Path.home</a
>
(<a
href="https://github.com/python/cpython/blob/ec4d917a6a68824f1895f75d113add9410283da7/Lib/pathlib.py#L994"
>Source</a
>) (which uses
<a href="https://docs.python.org/3/library/pathlib.html#pathlib.Path.home"
>os.path.expanduser</a
>
(<a
href="https://github.com/python/cpython/blob/ec4d917a6a68824f1895f75d113add9410283da7/Lib/posixpath.py#L228"
>Source</a
>))
</p>
<details>
<summary>Show Python</summary>
<pre>
import sys, os
from pathlib import Path
def get_config_dir() -> str:
config_dir = os.getenv('XDG_CONFIG_HOME', '')
// If the value of the environment variable is unset, empty, or not an absolute path, use the default
if config_dir == '' or config_dir[0] != '/':
return str(Path.home().joinpath('.config', 'my-application-name'))
// The value of the environment variable is valid; use it
return str(Path(config_dir).joinpath('my-application-name'))
config_dir = get_config_dir()
print(config_dir)</pre
>
</details>
<p>
The following is Bash code. Note that it does not use
<code>"${XDG_CONFIG_HOME:-$HOME/.config}"</code> since that does not silently
ignore non-absolute paths as per the spec
</p>
<details>
<summary>Show Bash</summary>
<pre>
get_config_dir() {
unset REPLY; REPLY=
local config_dir="${XDG_CONFIG_HOME-}"
# If the value of the environment variable is unset, empty or not an absolute path, use the default
if [ -z "$config_dir" ] || [ "${config_dir::1}" != '/' ]; then
REPLY="$HOME/.config/my-application-name"
return
fi
# The value of the environment variable is valid; use it
REPLY="$config_dir/my-application-name"
}
get_config_dir
printf '%s\n' "$REPLY"</pre
>
</details>
<br />
<h2>FAQ</h2>
<h3>Is that it?</h3>
<p>
There is more to the standard, but you should know and implement
<i>at least</i> the aforementioned, which is the most important part. If you don't
want to implement this yourself,
<a href="https://github.com/dirs-dev/directories-rs">use</a>
<a href="https://github.com/adrg/xdg">a</a>
<a href="https://github.com/sindresorhus/env-paths">library</a>. By implementing
this, your users will silently thank you!
</p>
<h3>What if I already do the wrong thing and use the home folder directly?</h3>
<p>
If you write to a few individual files in <code>$HOME</code>, simply check if
those files exist before following the XDG Base Directory Specification. Consider
the following example, given a traditional config location of
<code>~/foo-app.json</code>: If <code>~/foo-app.json</code> exists use it; if it
does not exist, then check if <code>$XDG_CONFIG_HOME</code> is set and is valid.
If it is, then write to <code>$XDG_CONFIG_HOME/foo-app/foo-app.json</code>. If
not, then write to <code>$HOME/.config/foo-app/foo-app.json</code>.
</p>
<p>
However if you hold all configuration and data inside a subdirectory of home (ex.
<code>~/.ansible</code>), things are a bit less clear-cut. Moving everything to
<code>$XDG_STATE_HOME/application-dir</code> would be easiest to the application
developer, but less semantically correct. If you don't want to worry about
migrating multiple files to separate directories, it would be a good first start
to make the location of the directory configurable by an environment variable. For
example, <a href="https://www.terraform.io">Terraform</a> exposes this option
using <code>TF_DATA_DIR</code>. Even just exposing the directory through an
environment variable is
<a
href="https://github.com/eankeen/dots/blob/d534663b655b3e470ba85abca0828ca9b514a0c2/user/config/profile/modules/xdg.sh"
><i>incredibly</i> useful</a
>.
</p>
<p></p>
<h3>Who else does this?</h3>
<div class="compliant-software">
<span>Kitty</span><span>FontForge</span><span>ImageMagick</span
><span>Alacritty</span><span>Composer</span><span>Terminator</span
><span>clangd</span><span>chezmoi</span><span>aria2</span><span>bat</span
><span>i3</span><span>nano</span><span>picom</span><span>poetry</span
><span>VLC</span><span>awesome</span><span>aerc</span><span>micro</span
><span>Handbrake</span><span>OfflineIMAP</span><span>polybar</span
><span>rclone</span><span>xmonad</span><span>mesa</span><span>Godot</span
><span>Docker</span><span>Anki</span><span>httpie</span><span>citra</span
><span>basher</span><span>asunder</span><span>Transmission</span><span>htop</span
><span>Termite</span><span>Git</span><span>Kakoune</span><span>Blender</span
><span>Gstreamer</span><span>ranger</span><span>Pry</span><span>TypeScript</span
><span>navi</span><span>d-feet</span><span>Mercurial</span><span>LibreOffice</span
><span>Audacious</span><span>byobu</span><span>colordiff</span><span>cmus</span
><span>ccache</span><span>antimicro</span><span>lftp</span><span>mc</span
><span>calcurse</span><span>Deluge</span><span>Terraria</span
><span>Wireshark</span><span>sway</span><span>xsettingsd</span><span>tmux</span
><span>PulseAudio</span><span>neomutt</span><span>VirtualBox</span
><span>broot</span><span>httpie</span><span>ALSA</span><span>pandoc</span
><span>nb</span><span>tig</span><span>cargo</span><span>openbox</span
><span>asdf</span><span>fish</span><span>fontconfig</span><span>Dolphin</span
><span>MultiMC</span><span>pnpm</span><span>GIMP</span><span>binwalk</span
><span>Inkscape</span><span>iwd</span><span>mpv</span><span>josm</span
><span>Wechat</span>
</div>
<p>
See the
<a href="https://wiki.archlinux.org/title/XDG_Base_Directory">Arch Wiki</a> for a
longer list and more details.
</p>
<h3>I already provide a <code>--config</code> option. Do I really need this?</h3>
<p>
Absolutely! The ability to specify files or directories with a command-line
argument cannot consistently be used. For example, you <i>could</i> define a shell
alias, but it won't always be used since the Bash option
<code>expand_aliases</code> is unset by default in a non-interactive environment.
Furthermore, if your program is invoked in any programmatic way (ex. an
<a href="https://man7.org/linux/man-pages/man3/exec.3.html">exec style</a>
syscall), there is no reasonable way to ensure that flag is passed.
</p>
<h3>Should I do this on macOS?</h3>
<p>
I've done quite a bit of research, and there doesn't seem to be a common
consensus. Generally speaking, if your program's only interface is a CLI, then
it's permissible to follow the XDG Base Directory Specification, even if you
aren't on Linux. This seems to be pretty common across the ecosystem, especially
for Bash programs. On the other hand, if it's a GUI, then you would usually follow
the standard
<a
href="https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPFileSystem/Articles/WhereToPutFiles.html"
>macOS directory locations</a
>. For example, Sublime Text 3 stores it's preferences on macOS in
<code>~/Library/Application Support/Sublime Text 3/Packages/User</code>, even if
it also ships with a <code>subl</code> command.
</p>
<h3>Should I do this on Windows?</h3>
<p>
I don't have a straight answer for you, simply because I don't use Windows
frequently enough. I'll add that Windows already has a preexisting directory to
place user data. Notwithstanding this fact, widely-used applications like
<a href="https://scoop.sh">scoop</a> follow the spec
<a
href="https://github.com/lukesampson/scoop/blob/092005046454d94d141d5c68fdbdb4c4a1229ae9/lib/core.ps1#L980"
>for configuration</a
>. Another command line app,
<a href="https://github.com/vexx32/PSKoans">PSKoans</a> hard-codes
<code>~/.config</code>. Admittedly, its usage is not widely prevalent, especially
compared to macOS, so the answer would be closer to a "no".
</p>
<h3>Who are you?</h3>
<p>
I'm <a href="https://edwinkofler.com">Edwin Kofler</a>, a software developer that
wants to proliferate the knowledge (and implementation) of this specification to a
wider group of developers. I've opened issues (that are now fixed) in repositories
such as
<a href="https://github.com/python-poetry/poetry/issues/1659">Poetry</a> and
<a href="https://github.com/pnpm/pnpm/issues/2574">pnpm</a>, and have proposed PRs
(that are now merged) in repositories such as
<a href="https://github.com/openSUSE/osc/pull/940">osc</a>,
<a
href="https://github.com/vscode-kubernetes-tools/vscode-kubernetes-tools/pull/1081"
>vscode-kubernetes-tools</a
>, <a href="https://github.com/shd101wyy/mume/pull/234">mume</a>,
<a href="https://github.com/basherpm/basher/pull/98">basher</a>, and
<a
href="https://github.com/search?l=&q=XDG+author%3Ahyperupcall&type=pullrequests"
>more</a
>! Together, I hope we can make the home directory clean again!
</p>
<h3>Auxillary resources</h3>
<ul>
<li>
<a
href="https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html"
>Official spec</a
>
</li>
<li>
<a href="https://wiki.debian.org/XDGBaseDirectorySpecification">Debian wiki</a>
</li>
<li>
<a href="https://wiki.archlinux.org/title/XDG_Base_Directory"
>Arch Linux wiki</a
>
</li>
<li>
<a href="http://ordiluc.net/fs/libetc">libetc</a>: A shared library using the
<code>LD_PRELOAD</code> trick to force storing files/directories in the proper
place
</li>
<li>
<a href="https://github.com/queer/boxxy">boxxy</a>: Script that uses
bind-mounting shenanigans to force storing files/directories in the proper place
</li>
<li>
<a href="https://github.com/b3nj5m1n/xdg-ninja">xdg-ninja</a>: a shell script
that checks <code>$HOME</code> for unwanted files and directories
</li>
</ul>
</main>
<footer>
<span>© Edwin Kofler</span
><a href="https://github.com/hyperupcall/xdgbasedirectoryspecification.com"
>Source</a
>
</footer>
</body>
</html>