Somebody should tell that to the Rust people. They have a .cargo and a .rustup folder in ~, plus an extra heavy target folder for every project. Would be much nicer if they put the cache one .cache
While I've not fully dug into all of those links, that is rarely the case and it makes the conversations harder when people over simplify situations like this. Generally, I've found when people make assumptions like this, the underlying requirements are a lot more involved and its not a high enough priority for the small group of overtaxed individuals.
You can also use the environment file linked in that blog post to tell Rust to follow the XDG standard. Not perfect because it is not the default behaviour but it is doable.
At least for rust applications of your own, you can use the library https://github.com/dirs-dev/directories-rs to follow XDG on Linux as well as platform conventions on Mac and Windows.
It's important on any system, not just XDG. The OS will assume you do, and offer features based on it, such as cleaning cache dirs, emptying temp dirs, etc.
It's not just about being tidy, although it's important.
But remembering all that stuff is annoying.
If you use Python, the wonderful "appdirs" package will make using the best dir for the job on Windows, Mac and Linux, easy and transparent: https://pypi.org/project/appdirs/
I wish it was part of the stdlib.
Another thing that grind my gears is people putting files inside their code project folder for development.
It should be something configurable, that by default use the OS dir for prod, and "../var" dir with everything on it in dev.
Less gitignore trouble, let's watcher overhead, less indexing for nothing, less clutter in file explorers, less possibility for errors.
But you need to provide an easy way to locate those files, such as a cmd line entrypoints, otherwise it's painful.
One of the things that changed my life recently, that I hadn't seen before: NeoVim has a NVIM_APPNAME variable that lets you change the app name.
So when I wanted to try AstroVim, I just set NVIM_APPNAME=astrovim, and dropped the files in ~/.config/astrovim instead of blowing up my existing (shitty) ~/.config/nvim.
I really wish the idea of configurable appnames was a part of the spec! (or a well-known extension!)
Historically a lot of programs would use argv[0] as their name. Vi-family editors do have an excuse not to do that, since vi uses its name for other purposes, e.g. `view` for readonly.
I want to share my nvim config between both my home Linux machine and my Mac at work, but I don’t want to share my config for gnome and its apps. So now I’ve got to maintain a script to go one more subdirectory deep to pick which dotfiles to sync and which to ignore...
> Easier to temporarily ignore the config
> It is easiest to set XDG_CONFIG_HOME=/tmp/dir
This is such an unreliable way to do it, even within the xdg world. What about stuff in ~/.local/share? It’s a lot easier and more reliable to just set HOME=$(mktemp -d)
Personally when I’m trying to start from a clean profile, I find it much easier to just go and blow away ~/.mozilla than to go and surgically remove .config/epiphany, .local/share/epiphany, .cache/epiphany, and whatever gconf (or gsettings or whatever windows registry clone we’ve got now) settings it’s got.
i want to mess up with wine, now I just backup ~/.wine, do whatever, restore.
With split folders, i'd have to backup a bunch of folders (.config/wine, .local/share/wine, .local/lib/wine or wherever the files, registry, dosdevices and other stuff would be put).
Then you have a whitelist which is clearly not that hard to maintain
For the cache, the opposite argument is just as true:
If I want to clear cache from everything to save space, I can just `rm -rf ~/.cache` instead. And this case is a lot more common than wanting to "start from a clean profile" :/
How did OP manage to get rid of ~/.mozilla? It's the only offending dotfile left in my $HOME and the stickiest. Until Mozilla fixes their 19-year-old feature request to support XDG [1], I couldn't find a workaround that wasn't a total hack.
XDG sucks for the only reason that it is really difficult to configure user directories to one's taste.
For instance, to get rid of Download, Templates, Desktop, Public Share, Documents, Music, Pictures, Videos directories I not only have to point them to somewhere else, I also have to make sure Desktop and Download do not point to the same directory, otherwise my config will not be used.
Here, after literally hours of researching, I figured the config that works:
Yeah, we have a straightforward and widely established standard. Just put the related files in .programname .
Now let's bikeshed and scatter them randomly across several places. To make it more fun let's make those locations programmable with environment variables so you won't even know where to start looking for a particular related file. Add lots of categories to create ambiguity. Make some of the default locations single level and others multiple level directories for no apparent reason for extra fun.
That has never been a standard as many programs have multiple dotfiles in ~. But even if it was, there are still good arguments for the XDG Basedir Spec: common way to change the location via environement variables as well as ability to split cache and non-cache.
> Now let's bikeshed and scatter them randomly across several places
"Now"? The initial draft of the XDG Base Directory Specification was published in 2002.
I don't my backups to include gigabytes of worthless cache files. I want them isolated somewhere, anywhere, so they can be easily excluded in my backup scripts.
I completely agree with the article that more people should use the spec. I already do this for all my personal projects and nothing drives me up the wall more than seeing random config files strewn about.
It also provides an easy target for freeing disk space if you do run into issues (just `rm -r $XDG_CACHE_HOME`).
That said, I do think the spec would be improved by defining what constitutes a "user-specific data file" and how that is different from a "user-specific state file". Wouldn't "user-specific data files" just be "files" from a users perspective? I like the idea they have for this, but it's kind of under defined.
Though that's probably a good thing because no one wants a ontological tome to wade through when working on a bash script or the like.
In what world is simply dumping config items for your app in the user's home directory sensible? Why stop at config items? Do cache or temp crap too. The thought process of persisting with this baffles me. Microsoft would be absolutely ridiculed if one day your msword preferences appeared on your desktop as an XML file, and no matter what, it kept reappearing.
The second example is a nice start, but I'd really like to see invisible files/folders in ~/ done away with altogether.
So starting with that example, I might add a visible ~/Library/ folder, then move ~/.config/ and ~/.local/ in there as ~/Library/Config/ and ~/Library/Local/ as normal visible folders. Same for .bashrc, .profile, etc; put them in ~/Library/Config/ without the dots.
If everything honored this spec, including the part where it reads environment variables to see where the different directories are, you could do that by sticking the right variables in your environment.
I think the one legitimate exception to the rule is profile, because you need that in order to set the variables in the first place. So that one would somehow have to be hard coded to at least have a wider search path
Luckily if you’re a developer on MacOS, you can have that too! In addition to ~/.config and a million .dotfiles and .dotdirectories from decades of unixy tools! Truly a cornucopia.
> The second example is a nice start, but I'd really like to see invisible files/folders in ~/ done away with altogether.
A great many amazing tools shall, by default, skip searching in hidden files (and gain a great speedup thanks to doing that). You'd have to modify all these tools so that they'd skip Library/ by default.
Also, related to that, what would you do with .git/? Move prjs/fizzbuz/.git to Library/fizzbuzz/git while keeping prjs/fizzbuzz?
Yeah, it's a bit alien on macOS. There is no good mapping for some of these folders.
For example, on macOS application configuration isn't even supposed to be done directly via application-specific files. macOS has its User Defaults subsystem, with `defaults read`/`defaults write` commands. And of course this isn't usable by typical command-line tools that don't have a Bundle ID.
Oh huh, I was always under the impression that "X" meant "Cross", as in "Cross-Desktop Group", since they were working on standardizing things across different desktop environments. But I guess the "X" was just a reference to X11? I guess today it encompasses a lot more than X11-based stuff, though...
I see some comments about users having a hard time cleaning their home directory and advices to use tools (boxxy?).
But I read this post as an advice for developers not for users. A long crusade for standardisation may I say ;-)
Any GUI file manager worth its salt can hide invisible and/or dotfiles, it’s table stakes — and just a GUI representation of that same terminal output.
> ... State :... if the data is unique for a given machine, the file belongs [to $XDG_STATE_HOME / $HOME/.local/state]
This statement is misleading/wrong. Like all other XDG stuff, it's not about the machine, it's about the particular user.
Also, why does the author consider the given positive example clean and tidy, when it has files .profile and .bashrc placed directly in the user's home directory? Following the rules, these files should be within the .config/ directory as well.
I strongly disagree: the dot files cause very little inconvenience because they’re typically hidden and they’re easier to type and list than the XDG spec stuff
The XDG defaults put them all (per category like config/data/cache) inside one 'typically hidden' directory, how is that not better?
You're also making an assumption that the alternative is $HOME/.appconfig, which it might be, but that's not any particular standard. It might just as well end up $HOME/app.config or $HOME/Library/Application Support/MacOs/Resources/App.app/config/Config/Resources/config.
The hidden part is another usability mistake, but the main benefit of XDG is respecting user's choice who can set an env var to avoid the mess, hope you wouldn't disagree with an option the improves someone's life without affecting yours in any way?
[+] [-] jenadine|3 years ago|reply
But they don't seem to care https://github.com/rust-lang/cargo/issues/1734 https://github.com/rust-lang/rfcs/pull/1615 https://github.com/rust-lang/cargo/pull/9178
[+] [-] agilob|3 years ago|reply
[+] [-] epage|3 years ago|reply
While I've not fully dug into all of those links, that is rarely the case and it makes the conversations harder when people over simplify situations like this. Generally, I've found when people make assumptions like this, the underlying requirements are a lot more involved and its not a high enough priority for the small group of overtaxed individuals.
[+] [-] senden9|3 years ago|reply
[+] [-] unnah|3 years ago|reply
[+] [-] happymellon|3 years ago|reply
https://github.com/queer/boxxy
[+] [-] BiteCode_dev|3 years ago|reply
It's not just about being tidy, although it's important.
But remembering all that stuff is annoying.
If you use Python, the wonderful "appdirs" package will make using the best dir for the job on Windows, Mac and Linux, easy and transparent: https://pypi.org/project/appdirs/
I wish it was part of the stdlib.
Another thing that grind my gears is people putting files inside their code project folder for development.
It should be something configurable, that by default use the OS dir for prod, and "../var" dir with everything on it in dev.
Less gitignore trouble, let's watcher overhead, less indexing for nothing, less clutter in file explorers, less possibility for errors.
But you need to provide an easy way to locate those files, such as a cmd line entrypoints, otherwise it's painful.
[+] [-] sscherfke|3 years ago|reply
Its successor is https://pypi.org/project/platformdirs/
[+] [-] spott|3 years ago|reply
Which makes this less than ideal.
[+] [-] rektide|3 years ago|reply
So when I wanted to try AstroVim, I just set NVIM_APPNAME=astrovim, and dropped the files in ~/.config/astrovim instead of blowing up my existing (shitty) ~/.config/nvim.
I really wish the idea of configurable appnames was a part of the spec! (or a well-known extension!)
[+] [-] kzrdude|3 years ago|reply
[+] [-] kps|3 years ago|reply
[+] [-] Oxodao|3 years ago|reply
[+] [-] quicklime|3 years ago|reply
> Easier to share configuration settings
I want to share my nvim config between both my home Linux machine and my Mac at work, but I don’t want to share my config for gnome and its apps. So now I’ve got to maintain a script to go one more subdirectory deep to pick which dotfiles to sync and which to ignore...
> Easier to temporarily ignore the config > It is easiest to set XDG_CONFIG_HOME=/tmp/dir
This is such an unreliable way to do it, even within the xdg world. What about stuff in ~/.local/share? It’s a lot easier and more reliable to just set HOME=$(mktemp -d)
Personally when I’m trying to start from a clean profile, I find it much easier to just go and blow away ~/.mozilla than to go and surgically remove .config/epiphany, .local/share/epiphany, .cache/epiphany, and whatever gconf (or gsettings or whatever windows registry clone we’ve got now) settings it’s got.
[+] [-] ajsnigrutin|3 years ago|reply
i want to mess up with wine, now I just backup ~/.wine, do whatever, restore.
With split folders, i'd have to backup a bunch of folders (.config/wine, .local/share/wine, .local/lib/wine or wherever the files, registry, dosdevices and other stuff would be put).
[+] [-] Oxodao|3 years ago|reply
```
*
!nvim/
!dunst/
!i3/
```
Then you have a whitelist which is clearly not that hard to maintain
For the cache, the opposite argument is just as true:
If I want to clear cache from everything to save space, I can just `rm -rf ~/.cache` instead. And this case is a lot more common than wanting to "start from a clean profile" :/
[+] [-] agnos|3 years ago|reply
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=259356
[+] [-] happymellon|3 years ago|reply
https://github.com/queer/boxxy
[Edit] woops, I didn't notice that it is linked right at the bottom.
[+] [-] sam_lowry_|3 years ago|reply
For instance, to get rid of Download, Templates, Desktop, Public Share, Documents, Music, Pictures, Videos directories I not only have to point them to somewhere else, I also have to make sure Desktop and Download do not point to the same directory, otherwise my config will not be used.
Here, after literally hours of researching, I figured the config that works:
[+] [-] account42|3 years ago|reply
[+] [-] upofadown|3 years ago|reply
Now let's bikeshed and scatter them randomly across several places. To make it more fun let's make those locations programmable with environment variables so you won't even know where to start looking for a particular related file. Add lots of categories to create ambiguity. Make some of the default locations single level and others multiple level directories for no apparent reason for extra fun.
[+] [-] weberer|3 years ago|reply
What? Just use the environment variable when reading.
[+] [-] account42|3 years ago|reply
[+] [-] subsection1h|3 years ago|reply
"Now"? The initial draft of the XDG Base Directory Specification was published in 2002.
I don't my backups to include gigabytes of worthless cache files. I want them isolated somewhere, anywhere, so they can be easily excluded in my backup scripts.
[+] [-] PrayagS|3 years ago|reply
This utility has been a lifesaver to clean up my home directory.
[+] [-] zamubafoo|3 years ago|reply
It also provides an easy target for freeing disk space if you do run into issues (just `rm -r $XDG_CACHE_HOME`).
That said, I do think the spec would be improved by defining what constitutes a "user-specific data file" and how that is different from a "user-specific state file". Wouldn't "user-specific data files" just be "files" from a users perspective? I like the idea they have for this, but it's kind of under defined.
Though that's probably a good thing because no one wants a ontological tome to wade through when working on a bash script or the like.
[+] [-] 000ooo000|3 years ago|reply
[+] [-] kitsunesoba|3 years ago|reply
So starting with that example, I might add a visible ~/Library/ folder, then move ~/.config/ and ~/.local/ in there as ~/Library/Config/ and ~/Library/Local/ as normal visible folders. Same for .bashrc, .profile, etc; put them in ~/Library/Config/ without the dots.
[+] [-] yjftsjthsd-h|3 years ago|reply
I think the one legitimate exception to the rule is profile, because you need that in order to set the variables in the first place. So that one would somehow have to be hard coded to at least have a wider search path
[+] [-] drunkpotato|3 years ago|reply
[+] [-] joshka|3 years ago|reply
[+] [-] TacticalCoder|3 years ago|reply
A great many amazing tools shall, by default, skip searching in hidden files (and gain a great speedup thanks to doing that). You'd have to modify all these tools so that they'd skip Library/ by default.
Also, related to that, what would you do with .git/? Move prjs/fizzbuz/.git to Library/fizzbuzz/git while keeping prjs/fizzbuzz?
This is, hopefully, never going to happen.
[+] [-] pornel|3 years ago|reply
For example, on macOS application configuration isn't even supposed to be done directly via application-specific files. macOS has its User Defaults subsystem, with `defaults read`/`defaults write` commands. And of course this isn't usable by typical command-line tools that don't have a Bundle ID.
[+] [-] eliaspro|3 years ago|reply
[1] https://github.com/b3nj5m1n/xdg-ninja
[+] [-] ploum|3 years ago|reply
https://ploum.net/207-modify-your-application-to-use-xdg-fol...
Some things never change…
[+] [-] olalonde|3 years ago|reply
[0] https://en.wikipedia.org/wiki/Freedesktop.org
[+] [-] kelnos|3 years ago|reply
[+] [-] hamdouni|3 years ago|reply
[+] [-] WiSaGaN|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] justeleblanc|3 years ago|reply
[+] [-] CameronNemo|3 years ago|reply
[+] [-] jbaber|3 years ago|reply
So where I never see these things without an `ls -a`, modern linux users are double clicking a folder and have to scroll past hundreds of dotfiles.
Also explains the X in XDG.
[+] [-] voltaireodactyl|3 years ago|reply
[+] [-] Eduard|3 years ago|reply
This statement is misleading/wrong. Like all other XDG stuff, it's not about the machine, it's about the particular user.
Also, why does the author consider the given positive example clean and tidy, when it has files .profile and .bashrc placed directly in the user's home directory? Following the rules, these files should be within the .config/ directory as well.
[+] [-] fiddlerwoaroof|3 years ago|reply
[+] [-] OJFord|3 years ago|reply
You're also making an assumption that the alternative is $HOME/.appconfig, which it might be, but that's not any particular standard. It might just as well end up $HOME/app.config or $HOME/Library/Application Support/MacOs/Resources/App.app/config/Config/Resources/config.
[+] [-] eviks|3 years ago|reply
[+] [-] deadbunny|3 years ago|reply
[+] [-] shmerl|3 years ago|reply
Some projects are stuck for years trying to implement this. Firefox for example.
> .audacity-data
Recent Audacity already fixed this.