I now use a combination of xdg + known-folders manually:
[target.'cfg(windows)'.dependencies]
known-folders = "1.2.0"
[target.'cfg(not(windows))'.dependencies]
xdg = "2.5.2"
use anyhow::{Context, Result};
#[cfg(windows)]
fn get_config_base_dir() -> Result<PathBuf> {
use known_folders::{KnownFolder, get_known_folder_path};
get_known_folder_path(KnownFolder::RoamingAppData).context("unable to get config dir")
}
#[cfg(not(windows))]
fn get_config_base_dir() -> Result<PathBuf> {
let base_dirs = xdg::BaseDirectories::new().context("unable to get config dir")?;
Ok(base_dirs.get_config_home())
}XDG's spec doesn't make such a distinction, so you’re advocating for a new competing standard.
I don't think Apple’s documentation intends to cover command line programs, but… in the absence of any concrete rule, putting your files where most programs on the system do is a reasonable choice, and that place will never be ~/.config/ on macOS.
Apps like homebrew that default to the library but support XDG_CONFIG_HOME if explicitly set, are a decent compromise, though.
But the real distinction is that the "Apple App" manages its preferences in-app. The "CLI app" does not, the user is expected to manage this configuration themselves.
That's why the long-term future of app development is containers. It is not possible, on a human level, to convince people to lift even the lightest of fingers for the common good.
Consider https://specifications.freedesktop.org/basedir-spec/latest/
The XDG specification has been around for 22 years. It has real benefits for users. It's trivial to implement. Yet even in the year of our lord two thousand and twenty five I still see TypeScript developers complain that it's "too hard" to comply with "this BS" and just stick files in $HOME.
I've long given up on solving technical coordination problems by appealing to the universal goodness of humanity. The only thing that works is to sandbox applications at tightly as possible and direct all their access to the external world through narrow interfaces that do their best to limit shenanigans.
I wholeheartedly agree about the containers part though, just have everything within a folder in a container somewhere so I don't have to keep googling where X stores Y and still failing half the time.
That kind of "sweep under the rug" attitude is even more wrong than putting a file to wrong location. Containers are good for some stuff, but duplicating code and letting badly developed software to proliferate in its own enclave is a defeatist approach.
> I still see TypeScript developers complain that it's "too hard" to comply with "this BS" and just stick files in $HOME.
I normally use this phrase sarcastically, but this time they really deserve it. It's a skill issue, moreover, PEBKAC. If there's a standard, you SHALL obey it, esp. if you're a prominent programming language. I mean, even my small utilities obey that. But that's Microsoft...
> I've long given up on solving technical coordination problems by appealing to the universal goodness of humanity.
Thanks for the good fight, we can take the torch from here and continue the challenge. No hard feelings here.
> The only thing that works is to sandbox applications at tightly as possible
Don't be so defeatist, though.
A mature technologist must be pragmatic if he wants to get anything done. Isolation technologies work. Scolding doesn't. We tried.
From what I have seen, not every human being is same. Categorizing them as clones of each other is falling into a false dichotomy.
> they're not about to start now just because you say so.
There's a quote I'm quite fond of: "You don't have to cut with the sword of truth, you can point with it, too". I don't "say what to do" to people and expect them to obey me. I produce examples, and put them out, and tell them politely. If they take the example, that's good. If they leapfrog me and show me a better one, that's great. If they ignore me, that's OK.
Not everyone will follow, and that's OK. Even I get upset by some people who doesn't do the correct thing. That's OK too.
We should be different, try different things, and find the correct way by mistake, or reach dead ends by doing everything right. My experience says both is possible, and even though the process is infuriating, that's OK too. This is called life. We can't control and know everything.
> A mature technologist must be pragmatic if he wants to get anything done.
There are places to be pragmatic, and there are places to experiment. Again, another false dichotomy. I did go great lengths by mixing the two, for example.
> Isolation technologies work.
Yeah, I also use them in various use cases, but never to sweep my incompetence under a proverbial rug. Instead, I skill up, do better. Surpassing myself in every iteration is the best dopamine hit I can get.
> Scolding doesn't.
You shouldn't be scolding anyone over any mortal matter like programming though. There are better ways to communicate, again from my experience. YMMV, IANAL.
> We tried.
You may have tried and I deeply respect that. But I'm a dense person who doesn't understand sometimes and do as I please, and apparently it helped me go places. So, I'll continue to be a dense person.
They do the same on windows. Recent microsoft tools are written linux-first, even dotnet.
That'd be interesting, honestly.
*: I have seen it all. I don't buy the OpenWashed Microsoft of today.
Don't blame people for doing what 90% of apps do and assuming everyone else is correct.
Indeed!
> It has real benefits for users.
I once believed this!
> It's trivial to implement.
Nope!
I ranted about this a while back (https://bsky.app/profile/str4d.xyz/post/3lsjbnpsbh22i) but the tl;dr is that the XDG specification is imprecisely written and internally inconsistent, and there has been confusion since at least as early as 2003 about what kind of data is meant to be stored in $XDG_CONFIG_HOME vs $XDG_DATA_HOME.
A plain reading of the XDG Base Directory Specification implies (but does not explicitly say, which is part of the problem!) that $XDG_DATA_HOME contains read-only user-specific application data files (like documentation).
But the spec is interpreted by many (source: I found a single blog post that seemed to be referenced in a variety of places, such as the Arch Linux wiki) as saying that $XDG_DATA_HOME contains mutable user-generated data (like password vaults).
Those have very different properties, and it's impossible as an app developer for me to predict which of those two directories a user (or the tooling installed on their OS) is assuming can be safely deleted without consequence, and which must always be backed up.
> Yet even in the year of our lord two thousand and twenty five I still see TypeScript developers complain that it's "too hard" to comply with "this BS" and just stick files in $HOME.
My earlier rant arose from me spending several days attempting to follow the XDG specification for an app where I need to store mutable user-generated data, being unable to find any supporting evidence that it was safe to store this in either $XDG_CONFIG_HOME or $XDG_DATA_HOME, and deciding on ~/.appname instead. I do allow all paths to be overridden in the config file, so individual users can use XDG paths at their own risk (and with knowledge of their OS environment's behaviour).
"There is a single base directory relative to which user-specific data files should be written. This directory is defined by the environment variable $XDG_DATA_HOME"
Where are you seeing "read-only"?
And why would it not be safe? What kind of user specific documentation did you think should go there and even if you did, why would you think it could be randomly removed by something else?
> $XDG_DATA_HOME defines the base directory relative to which user-specific data files should be stored.
And really, the difference between XDG_DATA_HOME and XDG_CONFIG_HOME is subjective anyway, each application will have its own requirements, so I'm not convinced it's even possible to define these completely precisely.
Personally, I would pick between XDG_DATA_HOME vs XDG_CONFIG_HOME based on whether the application manages the files, or whether the user is expected to manage the files themself. This isn't based on any wording in the standard, but just a pattern I've commonly seen
$XDG_CONFIG_HOME is clearly meant for data that would otherwise be in a configuration style dotfile. This is the sort of configuration that that users may well want to sync between machines such that a dotfile manager should include them by default. (That said, there may be some data from some of the other XDG directories worth syncing too, but generally a dotfile manager should not include those other folders in full by default.)
Beyond that the spec defines $XDG_DATA_HOME as "base directory relative to which user-specific data files should be stored.". The default path ($HOME/.local/share) might suggest that this should be read-only data, but it actually is read-write.
The description of the $XDG_STATE_HOME makes it quite clear that $XDG_DATA_HOME read-write: "The $XDG_STATE_HOME contains state data that should persist between (application) restarts, but that is not important or portable enough to the user that it should be stored in $XDG_DATA_HOME". This makes it clear that important and portable data should be written to $XDG_DATA_HOME.
And thus we also have $XDG_STATE_HOME. The list of examples that follow the previously quoted sentence make it clear that this is stuff that gets persisted, but if it were omitted from a backup, the user will probably not care too much (i.e. stuff like logs, history, set of open files, undo history, etc.
$CDG_DATA_HOME does also include any read-only reference data, which should be searched for there, and in $XDG_DATA_DIRS (which defaults to "/usr/local/share/:/usr/share/").
It could certainly be argued that read-only reference data and read-write user data should not have been mixed. After all Unix does keep them separate that at the top level `/var` vs `/usr/share`, but the spec authors apparent felt this distinction was not necessary at the user level.
From what I've seen Rust projects seem more or less node-esque in the sense that people just keep pulling all kinds of dependencies, not necessarily even understanding them that much. Like apparently serde the library is responsible for most of the slow compile times people associate with Rust, because deserialization/serialization is kind of a common thing to do in an app.
Happy to be corrected on my statements, not 100% on anything.
edit: apparently the behaviour in Go std library is the same, heh https://news.ycombinator.com/item?id=45022680
The main cost of compile times is Generics. Rust generics use "Monomorphization" which generate different binary code for every use of a generic type.
serde leverages generics everywhere and it generates the serialization code for every type you make serializable. So when you use `serde_json::to_string(MyType::new())` it follows calls a code path just for serializing MyType to a json string.
The upshot: It's incredibly fast, there's a lot of inlining and other compiler optimisations that can used because of it. No runtime reflection (Which is how Go does a lot of it).
The downsides: Takes a long time to compile cause of all the extra it's generating. Also can inflate binary sizes at bit.
Other languages like Go mostly use run time reflection for Json. Rust doesn't have much runtime reflection so doing it here wouldn't be possible
My experiences as well. Try to "cargo build" any projects, and you will immediately see the node-esque problems. It does not fill me with hope.
Building [=> ] 154/1473
Why is this normalized?
In practice, there are a lot of well known and well maintained Rust crates for core functionality. It has also inspired some good competition among different crates to serve different purposes, such as the different command line arg parsing libraries.
I don’t find it to be a problem at all, but I know some people get triggered when they install a package and see it download different dependencies.
It's free and open-source for heaven's sake! If you don't like it, fork it, patch it, make your own custom version. But stop pestering maintainers with demands.
I don’t see any “pestering” in the linked issues. They’re polite and well-written with supporting links.
This is how it’s supposed to be done. Suggestions for improvements or issues noticed go into issue requests for discussion. If the maintainer doesn’t want to do it, a polite and concise explanation is typical.
The refrain of “just fork it!” is a cop-out. Forking software so you can maintain a fork forever isn’t a trivial decision. It’s not helpful to the community to have to choose between a lot of different forks that have minor differences.
I agree that open source maintainers don’t owe anyone anything, but I think this mentality is being taken too far when with the “maintainer is always right” mentality combined with blaming the issue starter for the maintainer’s behavior.
Suggest it once, discuss it, get refused, move on. Instead there are tens of comments and above is a complaint about an additional ticket for the same issue.
I am not saying that maintainers are necessarily right, but they are in their right to build their project how they like it. It is a bad pressure and force if people continue to ask for things that a maintainer has already ruled out. What's the goal otherwise, caving in due to pressure and stress?
Fork and move on with your life.
but CLI tools are applications
CLI tools, including ones that Apple ships or makes, are not apps on macOS.
I’m sorry, this is my pet peeve as well and it’s very frustrating to see this ‘CLI tools are apps’ argument from developers who are not familiar with the Apple guidelines, and then argue about on an ideological basis.
Most libraries that use dirs-rs are doing so because they don't want to have to think about those things. So if there were a library that did it right, you'd probably have decent adoption if it's a simple crate replacement.
When writing the files, check the old location first, fall back to the new one. When reading, check check the new location first, fall back to the old one.
The app does not need to migrate anything. Using the algorithm described above, new installations will automatically use the new paths, old installations will continue using the old paths, but can optionally be migrated at the user’s convenience.
You are really making this more complicated than it needs to be. Just do it yourself, to be honest. It’s like 3–5 lines of code. Introducing a library just complicates it.
> copy the files, delete the old dir, them and then read from the new one. […] What if copying fails mid-way?
As I said: You don’t need to copy, delete, or move any files. Just support both modern and legacy paths, and let the user take care of the migration, if they choose to.
> What if it's a symlink?
Again, why are you making this so complicated? Just try to read the file. If it fails, check the next location.
I'm aware it mentions Linux specifically, but this is golden:
> From this point on, the number of dot-files and dot-directories can only shrink as the remaining applications get fixed and start conforming to the XDG base directory spec, while no new dot-files and dot-directories can be added to your home directory.
As is original reasoning for not using ~/.config from https://github.com/dirs-dev/directories-rs/issues/62#issueco...
> As Apple keeps tightening its after-sale ownership of macOS appliances, it's becoming increasingly unlikely that randomly dumping stuff in $HOME will keep working.
I get the feel he just does not like macOS?
> `choose_base_strategy()` and `choose_app_strategy()` will use the XDG strategy on Linux & macOS, and the Windows strategy on Windows. This is used by most CLI tools & some GUI tools on each platform.
If I ever have time, I would love to fork this repository, patch it to support XDG_*, and actively work to advertise it across the rust ecosystem. If user wants to use different location on file system to store configuration files, then let them. Stop trying to dictate what users want.
I think the Application support people have a stronger argument. Nowhere does it say store it in ~/.config for CLI tools. Also it seems weird to store user preferences in two different locations based on if it’s a CLI app or a GUI app. What if you have both interfaces?
I’m not saying that Application Support is the better solution, and if people feel that there should be a distinction between CLI apps and GUI apps they should push for Apple to update their standards. Repeatedly harassing an open source maintainer to relitigate an issue they’ve already decided on is counter productive and a waste of the maintainer’s time. I would be frustrated if I was him as well.
My configurations are preferences, stored in ~/Library/Preferences.
Even better if you store those as property lists and hook into CFPreferences so I can manage them with configuration profiles and use the defaults command to query and modify my preferences without having to open the app or read some 4000 line long JSONC file with 20 lines of settings and ~4000 lines of bad documentation.
And if you're writing a cross-platform application, it's not necessarily correct to have a completely different file format on different OSes. Not all Windows applications should store all their preferences in the registry, either.
I'd honestly be fine if none of them did.
> This directory contains app-specific preference files. You should not create files in this directory yourself.
Also
> defaults command to query and modify my preferences without having to open the app or read some 4000 line long JSONC file with 20 lines of settings and ~4000 lines of bad documentation.
I'd prefer the convenience of an editor to read the real 5 lines and 5 lines of comments of the settings I've changed (instead of the made up 4000000) and having a diffable config rather than some binary plist nonsense and relying on a clunky defaults cli. I'd even be prepared to shed the complexity of profiles for this basic conveniences
Moreover, most versions of MacOS are certified Unix: https://www.opengroup.org/openbrand/register/
POSIX exists, because out of UNIX System V, every clone went down their own merry way.
On the other hand, you can be more flexible and allow the user to pick how these are determined, as the Rust crate etcetera[1] does. This gives you the best of both worlds.
[1] https://docs.rs/etcetera/latest/etcetera/app_strategy/index....
From my perspective it makes sense as a default for go, which may be used to make either apps (things with bundle identifiers that go in /Applications) or CLI applications (which I wish would use ~/.config, but I understand that that's just my preference)
$ ls -ld ~/go
ls: /Users/mdaniel/go: No such file or directory
$ go install -v "github.com/jmespath/go-jmespath@latest"
go: downloading github.com/jmespath/go-jmespath v0.4.0
package github.com/jmespath/go-jmespath is not a main package
$ ls ~/go
pkg/
$ rm -rf ~/go
rm: /Users/mdaniel/go/pkg/mod/github.com/jmespath/go-jmespath@v0.4.0/.travis.yml: Permission denied
$ rm -rf ~/go 2>&1|grep "Permission denied" | wc -l
686So why is there a problem?
This directory contains app-specific preference files. You should not create files in this directory yourself.
The system provided interface in XDG apps is the XDG path - the Apple code there implies writiing a GUI app as none of the paths it says are not updated by the App ie no manual updates.
I think the exception is app bundles which also include some sort of auxiliary CLI utility that usually gets symlinked from its location in the /Application app bundle onto the PATH. For example the VSCode `code` CLI tool.
Basically anything that's a pure CLI binary would never be in /Applications anyway.
Defaults should go in /usr/. It is package developer / maintainer territory.
System-wide overrides should go in /etc/. It is the purview of the system administrator. Importantly:
> Programs must work correctly if no configuration files are found in /etc/.
User-specific overrides should go in XDG_CONFIG_HOME, with a fallback to ~/.config/.
the very first paragraphs on specifications.freedesktop.org says this:
> Freedesktop.org is a project to work on interoperability and shared base technology for free-software desktop environments for the X Window System (X11) and Wayland on Linux and other Unix-like operating systems. > We are not a formal standards body. The standards published on these pages are active or tentative (if marked as such) specifications which desktop environments may implement to improve mutual compatibility, share code and pool resources.
Deferring to XDG_CONFIG_HOME on MacOS if it exists makes a lot of sense as it conveys a clear intent from the user and the convention has grown popular. I’m not sure that the default ~/.config from the XDG specification is automatically better than ~/Library/Application Support by appeal to freedesktop.org’s authority.
And please don’t move configuration files around between releases without really being intentional about it.
The issue is that often everyone assumes that XDG_CONFIG_HOME is ~/.config
The idea of having a variable is that it could be anywhere,
The default value, when XDG_CONFIG_HOME is not set, is by specification ~/.config. It does not (and should not) default to a different value on OSX.
config_dir="${XDG_CONFIG_HOME:-$HOME/.config}/my-app"
And if you choose to just trust library authors, you are putting their ideas there instead. There’s that Rust crate that uses XDG on macOS, for example.
Why not just CONFIG_DIR?
Doesn't matter. This whole situation is a mess, and it's still a mess in the year 2025. Clearly existing operating systems can't be changed significantly enough to change anything like this.
but we're all still afraid to write new operating systems. We cling to MacOS, FreeBSD, Linux, and Windows as if our lives depend on it. Our lives do not depend on it.
If we want a saner OS, we could have it, but we don't want it bad enough, I think. It's easier to just deal with the piles of horse manure that has been piled on top of everything. So we have a rather active bikeshed discussion on HN about whether or not to use XDG_*.
We want to bikeshed more than we want to fix anything. Like all communities, this one also disappoints me.
This is a recurring pattern that systemd documentation is sold as "neutral" standard. The UAPI group is another example of this.
Also, XDG_RUNTIME_DIR is a just a directory. Since when did directories become a systemd feature?
My personal practice when writing command line utiities for macOS is to use the macOS API to write settings (previously known as “preferences”) into ~/Library/Preferences, so they can interoperate with any GUI versions of them I might like to write, and for the utilities themselves to have command line options to control those settings. As a sibling comment suggests, you do need to avoid name space collisions. You can use a reverse DNS name, or some companies are big enough just to use their company name. They do appear as .plist files but are actually maintained by a daemon – which nicely avoids race problems with multiple processes updating settings.
If I were writing a portable utility which had a dotfile with a documented format the user was expected to edit, I would make it a dotfile under the home directory.
~/Library/Application Support is really more for per-user static data, like presets and templates, things that are known in a GUI by a string in some dialogue but not necessarily thought of by the user as a file.
This would mean that essentially all edits to the configuration must be performed by the CLI tool itself? Because macOS preferences aren't really intended to be edited directly by the user. That feels like a totally different category of configuration than what we're discussing here. Though it certainly provides some nice functionality.
It's a lot worse, IMO. We're all fluent in our text editor of choice, we all know the rough format conventions of dot files.
Whereas I'd certainly have to lookup man page of the defaults tool, and IIRC it only supports editing one-key-at-a-time, which sucks for a dense config file.
If your tool provides a TUI/GUI for editing preferences, that'd be a different story.
> It’s certainly no worse
It's much worse, you don't get persistent undo from previous edits, indication of current changed and committed data, syntax highlighting, regex search, etc, etc.
Don't force your users to go through some custom sequence of CLI commands that they first have to spend 5 minutes learning. There should be no learning curve for a one-time setup.
Vim, Emacs, and Swift Package Manager do in fact support XDG. Also Git as well. But Vim doesn't create config files by itself and Emacs is no longer distributed by Apple.
To this day I still have to find anything that has problems taking a symlink instead of a file.
I am pretty happy with this setup as it means that all my dotfiles are in a single root folder that I manage through a git repo.
So I don't see what the linked articled means when it says that stows "makes (unsurprisingly) no effort to support ~/Library/Application Support.". It is literally a bit of organization from your side and passing a flag.
> […]although macOS will regularly replace your symlinks with copies of the destination files
I’m curious about this claim from the article - to what extent is this true?
Weird.
Perhaps referencing this behaviour where preference files can no longer be symlinks?
> Mackup does not work correctly in macOS Sonoma and all later versions, since it does not support symlinked files for preferences.
> Elsewhere, Reilly Wood rebukes a user asking if there would “be any downside to just not using Application Support ever” by saying that “[Nushell would] no longer be following the macOS Standard Directories guidelines.”
> We’ll read through those guidelines in a minute, but it’s not entirely clear to me that they’re relevant in the first place. The XDG Base Directory Specification mentions Unix a few times but lists no carveouts for macOS or any other operating system. If ~/.config is accepted as the standard location for configuration files on Unix-like operating systems, then surely it would be the standard location on macOS as well, given that macOS is a Unix by way of BSD.
> But suppose we accept that the XDG specification only applies to some Unix operating systems, despite making no mention of this. The macOS Standard Directories documentation starts by stating that “[w]hether provided by the system or created by your app, every file has its place in macOS”, and honestly we could stop reading right there, because a command-line tool is not the system or an app.
I could write a specification that says where files should go on macOS, and I could even get people to agree with me. That doesn't mean macOS or anyone else needs to care what we think
FWIW, it's not what I expect. I used Linux and Solaris extensively between 1995-2005 or so and have been a terminal using Mac user since Mac OS X public beta. My expectation is honestly that CLI programs will do whatever the heck they want and I've never heard of .config. I generally expect both configuration files and application data to reside at the root of my home directory, ideally in a subdirectory if there is more than one file.
If I could choose, I'd prefer for application data (files written by the application for its own use) to go in ~/Library/Application Support, because that's where I expect it to go. For configuration that I would edit by hand, I'm not so sure. Probably would prefer the root of my home directory, where I could at least find it easily without looking it up.
I wish I expected CLI programs to put their config in ~/.config, but I do actually expect them to just dump them into ~ annoyingly
For example, on macOS:
>>> appname = "SuperApp"
>>> appauthor = "Acme"
>>> user_config_dir(appname, appauthor)
'/Users/trentm/Library/Application Support/SuperApp'
>>> user_config_dir(appname, appauthor)
'C:\\Users\\trentm\\AppData\\Local\\Acme\\SuperApp'
https://developer.apple.com/library/archive/documentation/Fi...:
“This directory contains app-specific preference files. You should not create files in this directory yourself. Instead, use the NSUserDefaults class or CFPreferences API to get and set preference values for your app. In iOS, the contents of this directory are backed up by iTunes and iCloud.”
If a tool doesn’t want to use NSDefaults, using ~/.config is way preferable over polluting the user’s home directory, as many tools do.
Meh. An application is an application.
To make it extra fun, my $HOME directory is immutable:
chflags uchg "${HOME}"
Preventing arbitrary writes in $HOME breaks things, but it's actually quite rare.
I should document this setup. Or perhaps it's better to keep the madness to myself...
FWIW I use firejail so applications cannot run anything in $HOME and temporarily (heh) mounted tmpfs (two separate options).
I assume this breaks vscode? Would love a writeup if you have time
No part of macOS's desktop uses or specifies the XDG standard, it's not a POSIX standard nor a standard embraced by the OS. Following it is applying someone else's custom.
As another commenter mentioned though, ~/Library/Preferences is likely the more correct location on macOS.
It really, really isn't. That's where the macOS defaults system stores its data and shouldn't be hijacked for anything else. There's gazillions of files in there, most of which aren't grouped by directories. It's primarily meant to be accessed programmatically. It'll be painful and error-prone to manage CLI configs in there.
macOS is a unix, and there's no reason to make CLIs work partially like a Cocoa application. Breaking compatibility with other unices isn't worth it, especially when dotfiles work on macOS just like it works elsewhere.
The XDG spec is to coordinate the userspace of Linux software, meaning both CLI apps and windowed apps. Linux needs things called standards because Linus has not bothered to write them down himself, so there is no equivalent of Microsoft telling you data goes in AppData and Apple telling you data goes in Library. Identifying it as a standard for CLI tools across OSes is just wrong.
When CLI tools do this on macOS, it is not because anyone thought 'this is a standard for macOS', it is because they thought 'with -target darwin I don't get any compilation errors. ship it!' and frequently use those locations on Windows too where they don't make any kind of sense at all.
The standardized location is Library. If you do not expect it, that is on you; you should expect it, as it is the standardized location. It is only just now that people are starting to catch up with it, instead of blind ports with absolute minimum macOS-specific code, because of libraries like `dirs` which make it easy.
...seems to be a rather popular attitude between mainly-Linux based developers. I get it that it's easier to just read/write from/to "C:\etc\ssh\ssh_config" or "%HOME%\.dotfiles_are_cool_do_you_think_dotfiles_are_cool_no_I_will_not_set_hidden_attribute_on_it_why_would_I" but sometimes it's a bit jarring. Especially when the app doesn't work when placed inside a "Program Files" folder because it has spaces in the path.
Except for Zsh (~/.zshrc), SSH (~/.ssh/config), Vim (~/.vimrc), Curl (~/.curlrc), Git (~/.gitconfig). Apple could have chosen to patch these and move the configuration files into ~/Library if they really wanted.
I think it's entirely OK for long-established programs to adhere to their conventions; it's less surprising for the users. If you're going to change how things work, do so with minimum impact on the UI.
(I wish their GUI teams understood that.)
He's a kernel hacker and a technical leader. He doesn't write specs for the userspace, that's the least of his concerns. Linux has very strong guarantees on syscall backwards compat - Go doesn't even use libc. This is all by design.
Even the name "GNU/Linux" was something FSF tried to impose on distributions. The distributions being distributions, were free to brand themselves as they willed, which is 100% fair under the license terms.
This ecosystem has always been a bazaar, if that's not for you - use a BSD. (e.g. macOS.)
> This is not a judgement
"did not" is not judgemental but "did not bother" strongly implies judgement.
I do think it's true, however, that had Linus expressed an opinion on this it would have been hard to ignore.
Edit to add: Bear in mind that XDG is a relatively new thing compared to Linux (more so compared to Unix).
What are CLI tools that work under macOS but not under Darwin? Shortcuts like `code` or `pycharm` that open graphical apps? CLI tools that come bundled with macOS? Yeah these could use the latter.
Darwin by itself also need not come with CoreFoundation & GCD (although I believe since these are open-sourced the only darwin distribution, PureDarwin does include it).
macOS isn't Linux, and as much as I _absolutely support_ the XDG BaseDir spec, I don't think it's fair to try and apply it to macOS. Linux has no 'proper' directory for storing configuration, cache and application user data. macOS and Windows _do_. It's only proper to support those systems in the way that they intend. I wouldn't put stuff in to `%HOME%\.config` on Windows any more than I would put data in `$HOME/.Application Data/Local/` on Linux. Why would macOS get bundled in with Linux? Because it's a unix? That's silly.
Personally, I have my zsh config repoint those directories into `~/Library/Application Data`, though (as some have pointed out) it's probably better to put some of those folders in `~/Library/Preferences`.
Haha, and yet so many (usually Linux-first) applications do. Here's `gci $env:USERPROFILE -Force` on my computer:
d---- 3/6/2022 04:39 .android
d---- 6/9/2024 18:14 .cache
d---- 31/7/2025 11:10 .claude
d---- 16/8/2024 01:38 .config
d---- 2/3/2022 07:25 .dlv
d---- 7/8/2025 18:20 .dotnet
d---- 19/7/2022 07:15 .eclipse
d---- 1/4/2022 16:29 .fop
d---- 12/10/2024 23:49 .get_iplayer
d---- 26/8/2025 01:07 .gk
d---- 26/8/2025 01:07 .gnupg
d---- 31/12/2022 15:12 .gradle
d---- 30/3/2025 15:10 .ipython
d---- 22/10/2021 07:59 .librarymanager
d---- 9/6/2025 17:53 .local
d---- 26/11/2024 12:58 .lucid
d---- 31/12/2022 15:14 .m2
d---- 3/11/2022 06:14 .matplotlib
d---- 9/10/2024 20:24 .minio
d---- 20/4/2023 13:16 .ms-ad
d---- 4/5/2023 10:48 .nuget
d---- 7/9/2024 02:05 .ollama
d---- 2/9/2021 15:14 .omnisharp
d---- 15/7/2022 06:10 .platformio
d---- 18/6/2024 19:10 .redhat
d---- 7/11/2023 12:49 .runelite
d---- 2/7/2024 11:17 .sonarlint
d---- 10/7/2025 04:42 .ssh
d---- 27/12/2021 14:46 .templateengine
d---- 9/2/2023 11:35 .thumbnails
d---- 10/6/2023 09:15 .vscode
d---- 3/4/2023 11:30 Calibre Library
d---- 12/8/2022 18:56 dotTraceSnapshots
d---- 22/8/2025 22:51 hdos
d---- 9/11/2022 02:27 Heaven
d---- 6/11/2023 17:29 jagexcache
d---- 9/6/2025 17:53 pipx
d---- 1/6/2023 07:52 RenPy
d---- 1/9/2024 13:16 source
d---- 22/8/2021 02:15 Tracing
d---- 26/11/2024 16:31 Zotero
-a--- 9/2/2023 04:13 53 .git-for-windows-updater
-a--- 26/8/2025 00:45 1170 .gitconfig
-a--- 16/8/2023 08:07 2413 .kdiff3rc
-a--- 26/8/2025 00:59 20 .lesshst
-a--- 6/9/2024 18:15 27 .node_repl_history
-a--- 6/11/2023 17:29 90 jagex_cl_oldschool_LIVE.dat
-a--- 22/8/2025 23:49 74 jagex_runescape_preferences.dat
-a--- 22/8/2025 22:51 24 random.dat
-a--- 6/11/2023 17:29 24 random2.dat
-a--- 20/4/2023 13:50 0 Sti_Trace.log
-a--- 22/8/2025 23:49 1 tfa.dat
[1]: https://github.com/MicrosoftDocs/win32/blob/27277910169f4e1b...
What about Android? The only thing Android shares with Linux is the kernel; the entire user mode environment is completely different, and this includes how 'users' and their data are handled. What about automotive stuff like VxWorks?
> I know plenty of engineers (myself included) which have no interest in trying to make things work in the Windows ecosystem.
Good for you; then why even bother releasing stuff for Windows? Because it checks the 'here's your Windows release, now bugger off' box? As a parent commenter says,
> it is because they thought 'with -target darwin I don't get any compilation errors. ship it!'
What happened to actually caring about users, their expectations, and user-friendliness, without worrying about platform dogmas?
As an aside, Windows has the objectively superior filesystem permissions model. It supports a massive variety of access modes, uses ACLs by default, and this is what allows straightforward fleet management with AD. It is easier to map down Windows ACLs to POSIX octal file permissions than to map up the reverse.
I don't 'bother releasing stuff for Windows', as I said - for me it's not worth the pain.
There's nothing 'hidden' about dotfiles on UNIX-likes, unlike on Windows where, as I mentioned, there is such a thing that is exposed by the OS filesystem API (it's a normal attribute and can be straightforwardly set/unset with right-click -> Properties; not an extended attribute which refers to a very specific thing).
That files and directories beginning with a full stop are hidden in `ls` was openly acknowledged as a bug[1] in the original implementation, that gave rise to 'a bad precedent'. Ergo all the repeated gnashing of teeth (see this very article) by UNIX-like consumers who end up noticing the dotfiles anyway, because a significant plurality of people use a variant of `ls -la` for the utility of its tabular output.
[1]: https://web.archive.org/web/20141205101508/https://plus.goog...
What you seem to be confusing it with is file system ACLs, something that *nix for quite some time. In fact it was available on consumer desktop environments in the early 2000s - roughly the same era as Windows (when Microsoft brought their NTFS filesystem to the desktop).
Anyway, don't feed the trolls and all that, you're welcome to enjoy your windows ecosystem - just don't expect all engineers to write their software specifically to cater for it.
Then again, you said 'don't expect all engineers to write their software specifically to cater for it', seemingly ignoring my and essentially every parent commenter's plea for developers targeting non-Linux platforms to be good citizens on that platform, and adopt platform conventions. If you're not writing software for Windows, then sure, no need to think about Windows. If you are, or you are going to, then this platform convention business needs to happen and needs to be done correctly, whatever your thoughts on Windows, or, in the thread's case, macOS, where application data should go in `~/Library/Application\ Support` and not dot-dirs in $HOME.
The conversation digressed into cherry-picking my explanation of 'hidden file'. I'm not sure the troll epithet is fair.
... But it's still much larger than everything else put together, no?
Personally (and most people I know) see windows as user stuff. Not developer stuff. So CLI tools etc are linux/mac-first. Lots of projects I find nowadays don't even have a windows build...
I'm not sure what a reliable way of counting for developer machines would be but I'd doubt it'd be anything like it was in the 90s and early 2000s - as a consultant it's pretty rare that I'd see a developer running windows these days, even big old enterprises like banks and insurance seem to be largely Mac for technical users it seems. I have no doubt that I'll have some folks jump on this comment and disagree stating they see the opposite and I'm in a bubble - but that is the honest truth (at least here in Australia anyway).
%userprofile%\Documents (which used to be called "My Documents")
%userprofile%\Documents\My Games
%userprofile%\Documents\Saved Games
%userprofile%\Documents\SavedGames
%userprofile%\Saved Games
%appdata%
%userprofile%\AppData\LocalLow
%localappdata%
* = I'm well aware of the real history of Windows NT but from the consumer perspective it went from 98/Me -> XP
%APPDATA% is _fairly_ consistent for the past ~20 years. Local and LocalLow are odd distinctions, but have some interesting backgrounds. I don't find many programs abusing them. Roaming being the only real oddball that I find preferences for that aren't overridden by one of the other two folders.
https://learn.microsoft.com/en-us/windows/win32/dxtecharts/g...
> What this means is that you should not place save games in \Program Files, instead they should go in a sub-folder in \My Documents.
I'm a bit old school, I like the XDG standard, but the arguments against "~/Library/Application Support" don't make sense to me.
The people arguing against it are saying that a program that uses the CLI is not an "App". That argument seems wrong. App is short for "application" and I've been using the long form of that term since before the GUI even existed. A command line application is still an App in my mind.
---
It looks like Finder only treats files with an .app extension as "App Bundles" by showing an icon for them. But Apple seems to be careful with their language around macOS and (usually) calls these either "App Bundles" or "Bundles" and not "Apps" or "Applications". That's not always the case though. Here are some quotes from their docs:
> A bundle is a directory with a standardized hierarchical structure that holds executable code and the resources used by that code.
> In this document the term app refers to a main executable packaged in a bundle structure. This encompasses apps, app extensions, App Clips, system extensions...
It was great for local portability: you could put the file wherever you wanted, and it would still be colocated with its stuff. It was bad for network portability, because a lot of transport layers didn't respect the forks.
So Apple migrated to bundles - magic folders that look like a single file in the Finder, but contain all the resources it might need.
I'm somewhat on the fence about this topic in general & I think you've hit upon why. This isn't silly. At all.
Linux & Mac environments are by no means compatible but for anyone who cares about the location of their dotfiles, the two systems have demonstrably been "compatible enough". To the point that having coordinated standards on some aspects of (at the very least cli) applications would invariably be a net positive for users of both systems.
I run a Linux desktop & a Mac laptop between which I sync dotfiles & personal scripts. The scripts I sync work seamlessly on Linux & BSD systems because the incompatibilities are eminently manageable, so the topic of this post is definitely an inconvenience for me. I'm sure I'm not the only one.
Plenty of commenters are using Windows as a comparator stating "you wouldn't expect this in Windows" but in actual fact, I would like to have this in WSL2 (if I ever had a Windows machine). Powershell & CMD have never had anything resembling Unix compat so for those this is irrelevant, but Windows isn't a monolith.
In fact the more I read arguments against this in HN comments, the more I'm being persuaded to come off the fence & argue that XDG should be a *nix standard rather than a Linux one.
Though the flip side of my own subjective take here is that "home directory dotfile vomit" has just never seemed as big an issue to me as many make out.
This is a fair take, and something that I've considered when going down the obsessively organized path.
Does it _ultimately_ matter? No, of course not. A file is a file is a file and if it's located in $HOME or $HOME/.config is immaterial to the OS and, generally, a program. Just so long as it can be read and written to is ultimately what _matters_.
However. Insofar as directories are a construct for humans to mentally parse out and organize data that may be just abstractly written to any number of non-consecutive sectors on a disk, _I'd_ like to at least have a clean mental image of "where" that data is. Apparently, enough people had that same idea and started the excellent XDG spec.
> This isn't silly. At all.
I will grant you that it's pedantic. Both are POSIX-esque systems and to a large degree, talk the same way and expose the underlying infrastructure in a similar manner. However, I think ignoring the platform's preferred organizational methodology is doing a disservice to the end user. If the user wants a vomit of hundreds of .<whatever> files in their home directory, fine, I'm not your mom. You do you, but I think you should follow the law of least surprise and put things where they're _supposed_ to go, first, then if over-riden, then follow the user.
> but Windows isn't a monolith
It is the very definition of said. There is only one version of Windows, and any marketing faff about different editions are just different coats of paint on the same underlying system. Windows is Windows. You don't have Windows on ARM supporting %HOME%\.datadir\local\system\noreally instead of "AppData". You have AppData and that's it. You can bank on it being the same across all versions of Windows that are still in production, even going back a long way.
WSL1/2 are bolt ons that should behave differently. They're emulating a foreign system, configuration should be stored within, to whatever specification that happens to be.
When I first switched from Windows to Ubuntu, I considered it an amazing feature for discoverability, especially since there was a pretty reliable pattern of using the executable's name for the dotfile/dir.
/etc ?
> cache
/var/cache, /var/tmp ?
> and application user data.
/var ?
User data is stored in the user's $HOME, of which none of those locations are, generally, writable to an end-user, and wouldn't be a place to permanently store that data.
I think macOS has the right idea with ~/Library/ though I’m not as sure about the name. Maybe ~/Support/ or ~/System/ or something makes more sense, but whatever the case I’d rather see the dot files/folders swept up into proper unhidden directories under that directory, e.g. ~/Support/Config/, ~/Support/SSH/, etc.
Which really is all the reason more why programs should actually check $XDG_CONFIG_HOME. It’s not good to just assume when a distro or user might have different conventions set up.
Having built apps and CLI tools for macOS, the author's post certainly makes sense to me. Calling something a standard without backing from a standards committee seems odd, however.
For CLI apps, they broadly don’t support Library anyways, so .config is a nice way to organize things in a way that’s easy to access and remember. When was the last time I poked around in Library? I don’t even remember.
And thinking of windows: it’s not like apps use the appdata local/locallow whatever directories in any consistent way.
JoshTriplett•5mo ago
re•5mo ago
> Put app-created support files in the Library/Application support/ directory. In general, this directory includes files that the app uses to run but that should remain hidden from the user. [emphasis added]
JoshTriplett•5mo ago
Many good command-line tools manage their config files automatically, in addition to allowing the user to hand-edit them. I don't think that materially changes this, though: people may still expect to find them in `~/.config`.
joshka•5mo ago
I wrote a top level thread that this should be fixed by adding an explicit "I want XDG even though I'm on macOS" setting somewhere. Probably another environment variable.
re•5mo ago
> Probably another environment variable
Having any of the existing XDG_* environment variables set is an incredibly-clear indication that the user wants the XDG spec followed.
pjmlp•5mo ago
Where is XDG on Open Group standards?
joshka•5mo ago
mbreese•5mo ago
Much like the original author, my opinion is that you should do the least surprising to the user and if that’s not what the spec says, so be it.
GoblinSlayer•5mo ago
mbreese•5mo ago
OJFord•5mo ago
Why another one? If an XDG env var is set explicitly, that's obviously what the user wants. Just don't (necessarily) use the spec's defaults when it's not set.
joshka•5mo ago
OJFord•5mo ago
joshka•5mo ago
JdeBP•5mo ago
re•5mo ago
GoblinSlayer•5mo ago
tux3•5mo ago
Those libraries aren't normally in the business of creating symlinks, and if previous discussions are any indications, convincing them to add XDG support at all - let alone by default - seems on the same level as pleading Vim/Emacs users to just try Emacs/Vim
eviks•5mo ago