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
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.
The best arguments against it that I've seen are "many other projects don't use this spec, so why should we?" (e.g. our project should be the last to adopt it.. but why?) and arguments along the lines of "XDG_BIN_HOME isn't in the spec, therefore we shouldn't use XDG_CONFIG_HOME", which just seems like a lame excuse.
So it's been through some official channels.
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.
Its successor is https://pypi.org/project/platformdirs/
Which makes this less than ideal.
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!)
https://github.com/neovim/neovim/pull/22128
I actually have something similar in some of my old old projects. And I'd expect I ripped the idea off from somewhere. But I don't know who to cite. :(
> 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.
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).
You can set WINEPREFIX to use a non-default prefix path (other than `~/.wine`).
Note that the prefix doesn't contain everything that wine spills all over your home. It adds (XDG `.desktop`) launchers & menu/desktop shortcuts, file type associations, icons, etc. to the usual locations.
find ~ -type d -name "?wine" -exec cp -r "{}" /path/to/my/wine/backup/ \;```
*
!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" :/
But can you? Did you really close all the apps using ~/.cache? What if some app is just doing some cleanup operation, moves a bunch of stuff to cache, and the files are missing now? Did you just delete android studio cache in the middle of a compile?
You can also make a script like your .config, but it's called "clear_cache.sh", where you hardcore a few paths you usually clean manually.
https://github.com/queer/boxxy
[Edit] woops, I didn't notice that it is linked right at the bottom.
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:
cat ~/.config/user-dirs.dirs
XDG_DESKTOP_DIR="$HOME/.Desktop"
XDG_DOWNLOAD_DIR="$HOME/tmp"
XDG_TEMPLATES_DIR="$HOME/tmp"
XDG_PUBLICSHARE_DIR="$HOME/tmp"
XDG_DOCUMENTS_DIR="$HOME/tmp"
XDG_MUSIC_DIR="$HOME/tmp"
XDG_PICTURES_DIR="$HOME/tmp"
XDG_VIDEOS_DIR="$HOME/tmp"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.
What? Just use the environment variable when reading.
"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.
This utility has been a lifesaver to clean up my home directory.
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.
Some examples:
- PowerShell Core's default profile is in $HOME\Documents\PowerShell -- or if you have OneDrive enabled, $HOME\OneDrive\Documents\PowerShell.
- Windows Terminal is $HOME\AppData\Local\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json.
I can feel pretty confident assuming that if Microsoft can place their power users' config files for Microsoft's Terminal and Microsoft's primary shell in seemingly unrelated locations and not get huge complaints, I would imagine that most Windows users are probably not people who would ridicule Microsoft for placing an XML file in their home directory.
EDIT: I used these examples specifically, because a Terminal Emulator and shell profile are the exact kind of apps you would store configs for in a dotfiles repo.
I am fed up by this, and have completely given up on maintaining the tidiness of my %USERPROFILE% and %USERPROFILE\Documents. Almost all video games have absolutely no respect whatsoever for OS norms, and just spew their config and save data all over the damn place in %USERPROFILE%\<game title>, %USERPROFILE%\My Games\<game title>, %USERPROFILE%\<developer or publisher>\<game title>. The worst thing is that Windows has a place specifically for video game saves: %USERPROFILE%\Saved Games, or programmatically in C/C++: `SHGetKnownFolderPath(FOLDERID_SavedGames, ...)`.
To add to the mix, I also have GNU/Linux-first programs like SSH, Gradle, etc that just straight-up create dot-directories and dotfiles in the top level of %USERPROFILE%. Windows is not Unix/Linux; a dot prefix does not mean 'hidden'. Windows has an explicit 'hidden' filesystem metadata tag that programmers need to (and frequently forget to) set: `SetFileAttributesA(filePath, FILE_ATTRIBUTE_HIDDEN)`.
Home, not so sweet home.
desktop.iniSo 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.
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
Where is the config for program X?
It could be in the same directory as X, HKLM\Software\X, HKCU\Software\X, The HKLM\Software\XWOW6432Node\X, AppData\Local\X, AppData\Remote\X, AppData\LocalLow\X, ProgramData\X, USERPROFILE\.X, USERPROFILE\Documents\X, USERPROFILE\Saved Games\X, USERPROFILE\Documents\My Saved Games\X, USERPROFILE\.config\X...
This is the problem with preferences: everyone's preferences are different!
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.
$(infernalpath loc)/version-control/git/path-to-project/name-of-project
$(infernalpath loc)/version-control/fossil/path-to-project/name-of-projectFor 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.
https://ploum.net/207-modify-your-application-to-use-xdg-fol...
Some things never change…
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.
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.
No, it's both. The XDG state dir is for things that are also machine-specific so that, e.g., it doesn't make sense to sync them as part of your dotfiles.
> 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.
They should! Some shells have kindly moved to follow this convention following requests from users who like it for other apps and would prefer more uniformity w/r/t config file location conventions, e.g.: https://github.com/elves/elvish/issues/383
It was probably written back when it was more common to have your home on NFS, although I'm not sure how that would work without needing to use overlayfs per-machine or something.
No, it's correct. "State" data is machine-specific. You might run an application that needs to generate a machine-specific identifier on first run and save it somewhere. For someone who shares their ~/.config among multiple machines, that shouldn't be synced.
> when it has files .profile and .bashrc placed directly in the user's home directory?
There's no other good option, as you may have a chicken-and-egg problem: often people put their definition of XDG_CONFIG_HOME in their .profile or .bashrc. Bash can't know where to find the file if the file tells you where to find it.
Sure, it could just hard-code ~/.config (and that would be correct for most people), but for people who have it set to something else, now they just have an unwanted ~/.config directory. Might as well just stick it in ~/ and live with it.
Of course there are alternatives: someone could set those variables via a PAM module or some other mechanism that might be able to set it before the shell even starts, but I'm not sure we should expect that to be common either. You could also use /etc/profile or /etc/bashrc, but then you have to either set it for all users, or have an if/case statement or user-mapping file that sets things according to each user's preference. If this is a shared machine where most users don't have root access, then you need a mechanism that lets users update their preference.
Yes, I get that those things are not the common case: most people have a single-user desktop/laptop where they have root access. But we need to consider the edge cases too.
I was wondering about that part as well. Then again, I also have high standards for non-hidden stuff as well, and only have ~/Downloads from the ones they list. I do have a ~/Dropbox/home` with `docs` and `images` (as well as "video", but not synced locally), as well as ~/code and ~/dotfiles. If anything, having non-hidden clutter stresses me far more than hidden clutter; I have ~/.scratch for random on-off things I need, and I'll often utilize my disdain for extra stuff in the home directory as a way to make sure that I don't procrastinate something too long (e.g. if I need to make a phone call for some errand or something, I might put `phone.txt` in my home directory with the number I need to call, and seeing that every time I look at my home directory I get a reminder until I do it and delete the file).
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.
But when it comes to a 'well-behaved' Unix program, there used to be one place to look for its configuration, and now there are three.
That is, a program foo could still have its configuration in ~/.foo, but now it can also have it in ~/.config/foo or ~/.local/share/foo. If I don't know where the configuration is already, I have to check all of them.
I know ~/.local/share is supposed to be for "data files" and ~/.config is supposed to be for "configuration files", but in practice the distinction seems to be rather unclear.
Also, ~/.local/share/foo is a lot slower to type than ~/.foo even with tab completion. Why does that path need to be two directories deep? ~/.config/foo is less bad but still slower.
Because it puts them in an overengineered, overly cumbersome hierarchy under that. It reminds me of OSI.
> 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.
Either of the first two is easier to work with than the XDG-compliant way, and the last is no harder.
Is the dotfile now in ~/.local, or ~/.config or what?
If configuration then ~/.config. (which could be empty if you just use the default setup) If for data that the app writes then ~/.local
Some projects are stuck for years trying to implement this. Firefox for example.
> .audacity-data
Recent Audacity already fixed this.
«basedir: support separate (vendor/local) trees and masking for config files» https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_request...
«basedir: support drop-ins for configuration paths» https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_request...
I'm pretty sure I popped a vessel the day these freakin' directories spammed my home directory.
Overall I don't think xdg dirs on Linux are really as amazing as some people think. For example it is said that one can just back up the config dir to carry all the configuration over to the next install, but apps often dump the default configuration into the config dir, which you don't want to carry to the next install (which will have different versions, so probably a different default config) because that might break stuff. In the end you have to carefully look over all the configuration to see what's worthwhile to take with you, and it doesn't really matter if that's in ~/.appname or ~/.config/appname
Depends really what you want. If you want to have a fresh system with some of your config then sure, you need to decide what you want. If you just want to keep the same setup then ... I have been using the same $HOME for over 15 years (same for the rest of the system too). Some big upgrades (e.g. KDE3->4) required some manual intervention but most programs handle old config well enough in my experience.
I am really confused as to how that happened so I will show examples of all the three options I know of and how to use them to get a path of a config to load:
https://pypi.org/project/appdirs/ - simple, even works on windows
from appdirs import user_config_dir
import os
# Company is optional for windows support to work the way windows users expect it.
# You can also specify version to version the dirs.
conf_dir = user_config_dir("program", "company")
conf_path = os.path.join(conf_dir, "config.toml")
from xdg_base_dirs import xdg_config_home
conf_path = xdg_config_home() / "program" / "config.toml"
from xdg.BaseDirectory import load_first_config
import os
conf_dir = load_first_config("program")
# conf_dir will be none if there is no "program" dir/file in any of the paths XDG_CONFIG_HOME or XDG_CONFIG_DIRS
if conf_dir:
conf_path = os.path.join(conf_dir, "config.toml")
from pathlib import Path
import os
conf_home = os.environ.get('XDG_CONFIG_HOME')
conf_home = Path(conf_home) if conf_home else Path.home() / ".config"
conf_path = conf_home / "program" / "config.toml"
> but apps often dump the default configuration into the config dir
This is not an XDG dir related problem, and not even that common of a problem. You are right that it IS a problem (and applications should be encouraged to avoid this, just as they should be encouraged to avoid littering the homedir) but strictly speaking, using .config while littering it with auto-generated configs is better than not using config while doing the same. It really does make life easier when configuration is generally kept separate from other types of data by following the XDG base directory specification.
Only issue with my setup in general is that I can‘t just replicate it for other people. I moved .aws directory in .config/aws and I sometimes forget what the default for most tools is or where I helped the tool out to „find the right path“.
I also make sure when writing scripts/cli tools to use the XDG spec. In rust I use the dirs crate for example. I even go so far to never hardcode it for my own config scripts/files just in case I think about going from ~/.config to ~/.my_configurations or whatever.
This is my launch agent. https://github.com/Larusso/dotfiles/blob/master/.config/yadm... The nice side effect is that Apps launched via Spotlight will also inherit the path etc since they all are owned by launchd in the end.
Or they are a show-off.
ls -A -1 -p
-A is like -a but will not print . and .. directories.
-1 prints one file per line.
-p appends / to directories.
There's a lot more flags in the man page: https://man7.org/linux/man-pages/man1/ls.1.html
GetAppConfigDir() and GetAppConfigFile()
For more details see https://wiki.lazarus.freepascal.org/Multiplatform_Programmin...
Trying to use paths to meaningfully separate data by type is a fool's errand and no one will ever get it "right". It is the primary thing UNIX systems got extremely wrong that not only holds them back in the personal desktop space, but through cultural cross pollination has been ruining other desktop OSs too.
Original single-user desktop OSs had the best solution: keep everything related to the application functionality with the application. The application (in AppDir/file with resource fork/whatever form) itself can be wherever the user feels like putting it, and saved documents go wherever the hell the user feels like putting them. The only exception should be cache and temp data, which should go somewhere global.
This has the benefit of being clear and obvious to the user.
The obvious objections:
> but multiuser!
Is a use case that basically doesn't exist in personal desktop space. To the extent it was ever a useful concept it was during a time when a desktop computer was the only way to access the internet and they were too expensive and bulky to justify more than one in a home. Even then, we managed fine without OS level multiuser support.
To the extent that anything like a multiuser desktop exists it is certainly a niche, and therefore we should handle its problems with virtualization, containerization, filesystem overlay hackery, etc.
> but ease of backup!
Depends entirely on what cross section of things you care about backing up. As it is you already have to search dozens of places for including what you want and have rules for excluding what you don't and no standard is ever going to fix that. Applying those same things to the "everything with the application" model is, at worst, not any worse than things already are.
> but if I copy the application, it also copies the config.
That's a decent point, but I would argue this is the obvious thing and also perhaps what is intended. Solution is to have a standardized mechanism of clearing out the config and other state from the application directory, such that it can be done with a right-click context menu. A factory reset of the application if you will.
> but I never use a mouse and only use the GUI as a really fancy tmux
That's fine, nothing about this model makes your life conceptually any harder. Keep all the applications in directories in your PATH. Factory reset of the application can be just as easily done with a command as a context menu entry. You can still put applications in repos and even overengineer a package manager for them if you really want to.
~/Library/Application Support/AppName
With 3 competing standards it's unlikely that this will ever be resolved.
Android doesn't really do dot files. Or config files that the user can see at all.
(And if you'd like to amend to "the most used desktop OS", this is obviously aimed at unix-likes, but actually Windows does have an equivalent standard and programs targeting that platform really should be following it just like programs targeting unix-likes really should follow this)
Your advice re. Windows is also bad, for example, for a lot of x-platform tools I care more about x-platform consistency and would set the env var to the same ~/.config, e.g., it's much easier to do backup, and I don't care that there is some OS standard (which aren't great to be followed blindly)
But even for non x-platform apps that Windows AppData defaults are a dumping ground for app data (not configs) I don't care about and don't need to backup or anything , so if there is an option to put some configs that are more important in a different folder, that's better
Plus I don't want ~/Videos or ~/Pictures folders. I am not dumb. Let me organize my folders according to my needs and my will.
The first thing I do when I setup a user account is removing those useless XDG folders.
XDG pretend to remove folder clusterfuck then why do they add their crappy folders?
No problems: define the $XDG_CONFIG_HOME to be like so.
> I don't want an additional and confusing ~/.local.
The idea is that data and config are different. Anyway, if you have different taste, that's ok, define $XDG_DATA_HOME to be the same as config.
> I don't want ~/Videos or ~/Pictures folders
That's not in the XDG spec.
The problem with this is that it's all socially enforced, but it's not a social problem, it's a technical problem. The issue isn't that we haven't put enough pressure on developers to read the correct environment variables. It's that we have such a poor isolation story on UNIX that we have to care about where applications read and write from, rather than letting them do whatever they want in a sandbox.
Many of the open source docker images are on the right track here. Where does the persistent state go? /data. Where does the configuration go? /config. Where does the cached data go? /cache. All in the most obvious places right at the filesystem root. Those applications would be considered "badly behaved" outside the container, but inside, it's much easier to predict what they will do.
Technical enforcement is also not free - it has both a performance and usability cost at applies to everyone not just bad actors. One of the things I like about free software is that it allows for high trust environments because you don't need technical restrictions but can instead rely on people not being dicks. I consider this similar to wanting to live in places where I don't have to worry about locking my doors and closing all windows every time I go to the store.
Why must applications incorporate implementation details of the deployment environment? Why does the environment owner not have tooling to control where files are placed?
This trust is in some cases clearly not earned, and so one might consider that some applications are not worthy of having access to these APIs