None of the tools the author mentions as following XDG, actually follow XDG. No default tools shipped with macOS place files under .config or anything like that. There is a bunch of dotfile vomit in $HOME and that's it. Every tool that uses .config is one you manually install from an external source.
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.
> [...] Linus has not bothered to write them down himself [...]
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 judgment. It is simply a fact. Linux uses cross-distribution standards, because of this fact; these standards should not be misidentified as cross-platform standards - which I believe TFA was doing - as that's not the purpose they exist for.
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.
Apple rarely edits how big open source tools work in such a blunt way. I am not saying these tools' behavior is blessed by Apple. I'm just saying that TFA's assertion that 'these tools use .config so it's already standard' is not true - they don't. Unless you are saying that Apple is endorsing dotfile vomit outside of any particular folder.
Apple is quite happy to patch & extend stuff. Their ssh-add(1) accepts --apple-use-keychain, --apple-load-keychain; vanilla OpenSSH doesn't even know what long flags are.
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.
It will load config from there, if you manually create it there. If on a freshly initialized system you say `git config --global push.autoSetupRemote true`, it will write it to .gitconfig; it will not use .config unprompted.
What, there are other OSes that are not Linux? But why would you use them, just use Linux instead? Okay, fine, we'll pretend they're kinda Linux anyway and build the binaries for you. "Wrong paths"? Okay, patch it yourself then or something, idgaf about your weird non-Linux.
...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.
I and others have brought this up with the dirs Rust crate maintainer but they refuse to see it this way: https://codeberg.org/dirs/dirs-rs/issues/64. It's very frustrating.
I now use a combination of xdg + known-folders manually:
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())
}
> `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.
Sounds like it's time to make a fork of dirs-rs that actually follows the rules.
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.
This has been a solved problem forever. It is very simple, very easy, very short, extremely maintainable code.
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.
But how do you find the old location? Do you need to build against both libraries, call old_lib.get_path(), check if it exists, then call new_lib.get_path(), copy the files, delete the old dir, them and then read from the new one. What if it's a symlink? What if copying fails mid-way? Does the library or the program handle all of this? Can you even compile against both libraries if one is a fork of the other (namespace issues)?
The app doesn't migrate the files, so no worrying about copying. Don't bother even checking if it's a symlink. A symlink is a file. Just open it and read it.
> But how do you find the old location? Do you need to build against both libraries, call old_lib.get_path(), check if it exists, then call new_lib.get_path() […] Can you even compile against both libraries if one is a fork of the other (namespace issues)?
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.
From my previous recollection, there's an issue for this in just about every rust crate that handles these dirs. The right way to fix this is fix the spec, then make the libs adhere to the spec.
How would you fix the spec? Add a line explicitly stating the /Library/Application Support dir is only for applications with a bundle ID, instead of just implying it?
No the xdg base directories spec. If you want to be able to opt in to dry on a system which doesn’t canonically use xdg vars, then you need some config.
The maintainer's advice is correct, on mac you should store configs and other stuff in Library/Application Support, that's the mac convention to use on mac, just like xdg is linux convention to use on linux.
I think there should be two crates in rust-land. The answer by @soc makes sense for apps, as the article discusses. Many (most?) people building Rust programs aren't making apps and so shouldn't be using this crate, which clearly and definitively only supports MacOS "Apps".
What does making a different choice for GUI and CLI apps achieve, other than making it impossible to ever have a single coherent place to look/synchronise/etc?
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.
Not in Apple's nomenclature, it isn't. An App specifically refers to a folder named ".app" with an info.plist and a binary inside of it. It can also contain a bunch of other metadata and application data. To apple, a "CLI app" as you call it is just the binary (a single file).
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.
Imagine having built some software, abiding to a standard that to your understanding is the standard to abide to. Then comes people who ask you to break that standard and change your software. Again and again they come. Others ridicule your stance on social media and forums like these. It's burning out.
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.
I used pestering for OP's "I and others have brought this up (...) but they refuse to see it this way (...). It's very frustrating."
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?
dirs is a library project not part of Rust the language’s stdlib. You’ll find just as surly responses in many libraries across many languages. It feels a bit absurd to judge the language ecosystem by the maintainer of a single library.
I've also been eyeing Rust, but coming from Go where you can build more or less complete cli tools with just the standard library I'm not overtly exited by occurrences like this.
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.
It doesn't have very large standard library. It's just running on a different philosophy on not making the Standard Library "Batteries included".
But I find you get less dependencies than npm. Not so many tiny left-pad like microlibraries.
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
If you’re allergic to external dependencies then one of the batteries-included languages is better for you.
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.
> 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.
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.
No, they are not. Those two are very different in macOS, where the word ‘app’ means an Application Bundle, which is a directory with a .app extension, Info.plist file, a bundle identifier, have an expected directory structure per Apple guidelines, should be installed in /Applications or ~/Applications, and so on and so forth.
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.
dirs maintainer is bit unhinge, maybe the high usage of crate has gotten to their head.
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.
The spec from Apple could be clearer, you have to read the tea leaves and both sides have enough ammo to argue for their interpretation. But as someone who doesn’t care either way where these are stored I think that makes me a bit more objective than people who strongly have an opinion that they are looking to justify.
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.
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 Apple keeps tightening its after-sale ownership of macOS appliances, it's becoming increasingly unlikely that randomly dumping stuff in $HOME will keep working.
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.
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.
> That's why the long-term future of app development is containers.
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
> If people have refused to do the right thing for 20 years...
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.
How is it even common good though? The articles main argument is that the author didn't expect the files there, not that it was causing any kind of issue. The problem is that people disagree where a config file should go, and there's no compelling reason why either of them are right or why it even matters.
I have absolutely no opinion on "common good" or "standard" here.
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.
I've been using macos for years, I just learned .config was a standard in this thread, because damn nearly everything shoves files in ~ so I just assumed that is where config files go.
Don't blame people for doing what 90% of apps do and assuming everyone else is correct.
> The XDG specification has been around for 22 years.
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).
$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.
I'm not sure where you got that XDG_DATA_HOME has to be read-only, I couldn't find anything like that
> $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
"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?
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`.
I kinda wonder if this is an age thing as the English language morphs over time.
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's even in the name: a command line application. The disconnect comes from Apple adopting the term "app" when they launched the App Store in 2008. And the aggressive marketing campaign with phrases like "there's an app for that". The word changed (in some minds) from meaning "any executable" to one that is on a phone.
Before they rebased onto UNIX, Mac files had two parts: a data fork and a resource fork. Data had the binary. Resource had strings, images, and other assets that the binary needed.
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.
> Why would macOS get bundled in with Linux? Because it's a unix? That's silly.
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.
> 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.
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.
> 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.
It's a stretch to say /var is for application _user_ data. For a certain value of "user" sure, like MariaDB or Redis. They're "users", and have data in /var but it's a non-interactive session.
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.
Had a chuckle at "classic Linux-first development", it's every OS except Windows - Windows is the outlier here, and I know plenty of engineers (myself included) which have no interest in trying to make things work in the Windows ecosystem. So I guess in the same way that roads are "classic wheel-first infrastructure", you don't try to pave a swamp.
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.
You must be aware that ACLs are well supported by all major UNIX operating systems (yes, Linux is UNIX, there are/were two general-purpose Linux distributions certified as UNIX). It's just that basically nobody is using them because they're rarely necessary, and there are easier ways to implement access control if you want something simpler, and also far more powerful mechanisms for when that's needed.
It's hard to tell how your commment was a sincere response rather than derision for anyone using or targeting Windows. There was nothing technical. Here's a technical response:
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.
It's standard convention for (mostly GUI) applications to visually hide files and directories that start with a ., I don't know what you think a hidden folder is if it's not this and it has been widely accepted in the industry as a whole (except in Windows) for a very long time.
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.
I am confused. My point was that if engineers target Windows at all, they ought to do it properly, but you retorted with 'I don't target Windows'. Okay, well and good, then my advice isn't for you and developers like you.
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.
> Windows is the outlier here, and I know plenty of engineers (myself included) which have no interest in trying to make things work in the Windows ecosystem.
... But it's still much larger than everything else put together, no?
Not for servers, containers, embedded or IoT devices which is the vast majority of the internet.
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).
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...
On the other end, when Windows first started having multiple users and locking down write access to system directories (*), lots of video games (and some other programs besides) decided to just dump their files anywhere. Just looking at my own system, I see all of the following used:
%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%
As far as I can tell, there's no rhyme or reason to any of this. I know the three AppData folders have distinct meanings, but I don't think video game developers are using them according to their proper meanings. Also, I'm being generous with my use of variables above. Some programs have hardcoded the drive letters and paths.
* = I'm well aware of the real history of Windows NT but from the consumer perspective it went from 98/Me -> XP
Unfortunately, there is a reason. During the Vista timeframe, Microsoft published guidance recommending that game developers use the Documents folder for save games, as part of the push to make games compatible with UAC and non-elevated user accounts.
Yeah, the Windows directory story is a mess. Of all the vaunted backwards compatibility they offer, there are some very strange user-facing breaks that don't make much sense. The Home directory structure being one of them.
%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.
Free software developers are rarely interested in spending time on supporting unusual proprietary operating systems. You should be grateful all this software works there at all — some Windows users did not just moan on internet forums, but actually went and implemented support for their OS of choice in all these packages.
Oh, I'm well aware of this on Windows. It's stupid and easy enough to fix for the developer, but I'm also aware there is virtually no desire to implement.
If your binary is supposed to live in `/Applications`, by all means put its config in `~/Application Support`. If it lives in `/bin` or somewhere similar, or if its default or system-wide configuration go in `/etc`, config goes in `~/.config`.
Agreed! but mostly moot. As a general rule, CLI utilities which are just single binaries should not go in /Applications. That folder is for app bundles which are folders with a .app extension, an Info.plist file, etc. And its not on the PATH used in the shell (by default).
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.
It's not moot though, because this whole thing is about the CLI binaries (usually because of a decision made by a framework like dirs-rs) using 'Application Support' et al.
I meant to say that 'If your binary is supposed to live in `/Applications`, by all means put its config in `~/Application Support`' is moot because CLI binaries aren't in /Applications ever
That's what I was hinting at. MacOS is kind of split into two personalities, and the way to be a good citizen in the system is to respect the boundaries between those two personalities. CLI tools are definitely part of the Unix personality and should follow its conventions.
Towards the end TFA claims that Apple’s bundled command line utilities, including zsh and vim, put their dotfiles in ~/.config. They don’t. They put them in the traditional BSD place, the user’s home directory ~/. Looking at mine now, I see .bash_login, .emacs (wow! that’s old), .lldb, .lldbinit, .vimrc, .swiftpm, .z{profile,env,rc} and a few others. I see no ~/.config directory.
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.
> 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
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.
Yes, ideally the tool should edit its own preferences. A quick and dirty tool might leave the user to run the macOS "defaults" command line utility themselves. It’s certainly no worse than looking up the dotfile format and firing up vi.
In what world is this user hostile behavior ideal? There is no way you can write a cli tool that is more ergonomic in editing plain-texty config format than a good code editor!
> 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.
> It’s certainly no worse than looking up the dotfile format and firing up vi
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.
Yeah nah. If your configuration has a schema (e.g. JSON schema), AI tools can do a magnificent job turning free-form requests in natural language to valid configuration. Even if your configuration does not have a schema, people can refer to snippets of configuration made by other people on the internet.
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.
As a decades long time Mac user, when I see something show up in ~/.config it just feels like a maladapted port. It's a similar feel to seeing .dotfiles that are not actually hidden on Windows. Like, whelp, they didn't even bother.
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.
> ~/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.
I agree with “should not go in ~/Library/Application Support”, but why would anybody put them there? The Mac way is ~/Library/Preferences, or, system-wide /Library/Preferences, and the use of NSDefaults.
“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.
Put me in the disagree camp. The XDG spec seems like it is for X windowing-based systems, not the Mac, so that's not a reason to adopt. The author asserts what users expect, but without any evidence.
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 expect _applications_ to put their config there, as the author says; something that lives in /Applications or ~/Applications and has a bundle specifier.
I wish I expected CLI programs to put their config in ~/.config, but I do actually expect them to just dump them into ~ annoyingly
No, I think you should write more about it. Motivations, what about programs or scripts that require writing or at least modifying files in $HOME, etc.? You say it is rare, but is it really? Also what is your way when you want to communicate between two programs? What is your preferred method of IPC? I will check how much my system works if I do the same thing as you, on Linux. :D
FWIW I use firejail so applications cannot run anything in $HOME and temporarily (heh) mounted tmpfs (two separate options).
honestly as long as they don’t use the home directory ill survive. vscode and similar apps not offering any alternative to home directory pollution kills me.
I assume this breaks vscode? Would love a writeup if you have time
It seems like the best of both worlds, here, would be to put the files in ~/.config/yourprogram, and symlink that to `~/Library/Application Support/org.example.yourprogram`. That would satisfy folks expecting to find it in either place. The only folks it wouldn't satisfy would be those complaining about the files being present in one of those places at all, and that seems like the least of the concerns compared to making sure people find it.
I doubt anyone running Unix-style command-line/TUI tools where the config files are expected to be edited by hand by the user is expecting to find it in the Application Support directory; that directory is not a directory that Apple intends for users to ever interact with directly:
> 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]
> where the config files are expected to be edited by hand by the user
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`.
Missing from the "hidden from the user" argument is the fact that .config, and dotfiles in general, are also hidden from the user. It's not the defining distinction that one may think it to be.
Command-line binaries are also typically installed at locations hidden from the user (/bin, /opt/homebrew, ~/.bin, ~/.cargo/bin). Further indication that the "app"-oriented Apple documentation is intended only to apply to "apps", which are installed at /Applications or ~/Applications.
(I maintain a fairly popular TUI library), and as a CLI/TUI user on macOS, I dislike the App Support folder a lot. But even though I dislike it, I'd expect that apps for mac should put their files there because the XDG spec doesn't apply to macOS. It's the wrong place, but the technically correct one. The right thing to do is fix the spec, and then fix the apps / libs to follow that.
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.
And I’d also argue that the App Support folder doesn’t apply to CLI/TUI config files either. Apple doesn’t force CLI programs it distributes from storing files in App Support. If this were the case, wouldn’t you also expect the .ssh folder to be relocated from $HOME to App Support on a Mac?
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.
I completely expect for that to be the case. My point is, there are already programs distributed with macOS that don’t put config in the ~/Library/Application Support folder. Knowing this, I don’t see a good argument for (especially portable) CLI/TUI programs for keeping user editable config data in the App Support folder.
> this should be fixed by adding an explicit "I want XDG even though I'm on macOS" setting somewhere. Probably another environment variable.
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.
The xdg vars only control the location. There’s no var to control that xdg should be used. macOS has a canonical approach, which some tools choose to ignore. I want a flag to make that ignorance correct
It seems like the roadblock is that most cli tools don't want to think too hard about XDG in the slightest, and they delegate to standard directory libraries.
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
XDG is a Linux-centric spec. If we the people want it to be OS-agnostic, it needs to be vetted and designed for that. Until then I don’t see why macOS applications must adopt XDG, despite it being my preference.
> 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.
> The XDG Base Directory Specification mentions Unix a few times but lists no carveouts for macOS or any other operating system.
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
The Go standard library uses ~/Library/Application Support as well [1]. Given the Unix credentials of Golang's top folks, I would assume there's a good argument in favor of this decision?
The argument is that there are two separate ideas: configuration for macOS apps (i.e., .app bundles) should be placed in Application Support (a platform standard), while CLI tools should be placed in .config (not a standard, but common practice). If you're going to have a single function that returns a path, you have to pick one, and Go picked the platform standard.
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.
$ 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/
And, while not _exactly_ related to this topic, this has also always rubbed me the wrong way:
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)
I don’t think I’ve ever encountered a command line tool that makes this mistake, hooray for me. On the other hand lots more today support XDG_CONFIG_* and don’t litter ~ with random .dir stuff. I really like the new era of CLI tools that’s trying to be excellent in every dimension. Hopefully whoever needs to see this does and gets with the program! Although if it puts this much bee in your bonnet you can always open a pr
> But suppose we accept that the XDG specification only applies to some Unix operating systems, despite making no mention of this.
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.
Why should it not.
The easier case for me to defend is XDG_CACHE_HOME - if it defaults to ~/.Library/Caches then it makes life simpler on macOS as it means that you don't have to add other directories to be removed from your backups.
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.
Of course, if you decide to account for Windows / macOS conventions, it’ll be a bit trickier, but pulling in a library for that is a bit overkill, yeah.
Adding a library has nothing to do with that. You can implement it yourself in a few lines of code, especially if you only need one path, like configs. You do need to research for caveats (e.g. check $XDG_CONFIG_HOME on Linux and not just put it into ~/.config) but it’s not rocket science.
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.
I put them in a dotfiles directory and use `stow`[1] to symlink the contents to where applications expect them to be. Under that root I have a home folder that it is symlinked to `~/`, and I have and applications one that is symlinked to `Applications Support` through the `-T` argument of stow.
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.
I have never seen this behavior on macOS and doesn’t make sense. However, some applications will save files by creating a copy and overwriting. Maybe that’s what the author experienced?
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.
The semantic distinction you're trying to make is artificial, but also explicitly against Apple spec, so no, your approach is the wrongest as no-one would expect you edit configs there
> 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
To the best of my knowledge, it's incorrect to store anything other than plists in that directory.
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.
When I last encountered this (agreeing with the article author about the correct location for CLI tools being XDG_CONFIG_HOME), I found https://crates.io/crates/etcetera.
I wrote elsewhere that I think the solution to this is to add another variable to the XDG Base Directory Specification to explicitly opt into using XDG variables, and then to support that flag on libraries that target Windows / MacOS and which would otherwise choose mac Application Support / Windows AppData folders.
Where did OP said that "XDG_CONFIG_DIR is always ~/.config"? You can of course set it to another directory, if you wish so, and that should be respected.
Provide the whole quote.
Contains the user’s preferences. You should never create files in this directory yourself. To get or set preference values, you should always use the NSUserDefaults class or an equivalent system-provided interface.
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.
Somewhat related, a few weeks ago on Python Bytes I learned that there is a python module that abstracts various directory locations per-platform. For instance, you can use this module to find the location of the Movies directory, or the cache directory.
The thing that annoys me more than the authors main complaint is when the XDG specs are ignored on windows and macOS (I.e. if XDG vars are set, respect them). I work on all platforms, I have decades old dot files that work on over 9 different operating systems that I have used extensively. Some programs force maintenance work I’d rather not. Another peeve in this space is programs that force absolute paths (worst offenders are the ones doing it for security theater, diaf gpg) or that lack any mechanism for platform or local overrides.
I guess while I’m here, please stop putting generated stuff in .config or even worse junk you downloaded, half of you without even checking it’s the right content or having any docs, ui or ux for cleaning up.
Has the XDG Base Directory Specification been adopted by an official standards committee? In my previous life, calling something a standard carried a great deal of weight. For example, contracts could mandate compliance with standards.
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.
Yeah, I broadly agree — even if I am primarily a Mac user, I am constantly annoyed by the odd tool that does that. SimonW’s “llm” tool is one of the offenders.
Follow the link to the XDG spec, look who is the 3rd author. There is no reason for MacOS or the BSDs to implement a systemd spec. A specific example: XDG_RUNTIME_DIR is a feature of pam_systemd and nothing else.
This is a recurring pattern that systemd documentation is sold as "neutral" standard. The UAPI group is another example of this.
Unpopular opinion maybe, but even under Linux and BSDs I’ve felt that dot folders/files in home are poor practice. Hiding them was a band-aid for bringing *nixes into the GUI era and just adds an extra hurdle outside of the CLI, and many of them are overly specific compared to the other standard user folders.
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.
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.
Possibly anything that makes use of Cocoa (this need not imply that it's a GUI tool) or other system frameworks like IOKit, CoreBluetooth, or CoreAudio.
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).
For everyone against .config on mac: who cares? I, for one, don’t want to deal with or remember different patterns across different OSes as much as possible. So I’ll install gnu coreutils on Mac, and I’ll use .config.
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.
None of the tools the author mentions as following XDG, actually follow XDG. No default tools shipped with macOS place files under .config or anything like that. There is a bunch of dotfile vomit in $HOME and that's it. Every tool that uses .config is one you manually install from an external source.
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.
> [...] Linus has not bothered to write them down himself [...]
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.)
As a “BSD” even MacOS seems to be the odd one unlike the others.
This is not a judgment. It is simply a fact. Linux uses cross-distribution standards, because of this fact; these standards should not be misidentified as cross-platform standards - which I believe TFA was doing - as that's not the purpose they exist for.
> has not bothered
> 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).
Who writes .gitconfig?
> The standardized location is Library.
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.
Apple rarely edits how big open source tools work in such a blunt way. I am not saying these tools' behavior is blessed by Apple. I'm just saying that TFA's assertion that 'these tools use .config so it's already standard' is not true - they don't. Unless you are saying that Apple is endorsing dotfile vomit outside of any particular folder.
Apple is quite happy to patch & extend stuff. Their ssh-add(1) accepts --apple-use-keychain, --apple-load-keychain; vanilla OpenSSH doesn't even know what long flags are.
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.)
git supports XDG - its config lives in `$XDG_CONFIG_HOME/git/config`. Though a lot of people still use the older location of ~/.gitconfig
It will load config from there, if you manually create it there. If on a freshly initialized system you say `git config --global push.autoSetupRemote true`, it will write it to .gitconfig; it will not use .config unprompted.
As does vim (e.g. $XDG_CONFIG_HOME/vim/vimrc and $XDG_CONFIG_HOME/vim/pack/...)
What, there are other OSes that are not Linux? But why would you use them, just use Linux instead? Okay, fine, we'll pretend they're kinda Linux anyway and build the binaries for you. "Wrong paths"? Okay, patch it yourself then or something, idgaf about your weird non-Linux.
...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.
I and others have brought this up with the dirs Rust crate maintainer but they refuse to see it this way: https://codeberg.org/dirs/dirs-rs/issues/64. It's very frustrating.
I now use a combination of xdg + known-folders manually:
to get the config directory:It seems like `etcetera` has better defaults: https://docs.rs/etcetera/latest/etcetera/#native-strategy
> `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.
Sounds like it's time to make a fork of dirs-rs that actually follows the rules.
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.
The maintainer of dirs-rs IS the one following the rules here…
Where do I store my files is never a simple replacement. At the very least you need to write a migration routine and maintain it for a very long time.
This has been a solved problem forever. It is very simple, very easy, very short, extremely maintainable code.
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.
But how do you find the old location? Do you need to build against both libraries, call old_lib.get_path(), check if it exists, then call new_lib.get_path(), copy the files, delete the old dir, them and then read from the new one. What if it's a symlink? What if copying fails mid-way? Does the library or the program handle all of this? Can you even compile against both libraries if one is a fork of the other (namespace issues)?
The app doesn't migrate the files, so no worrying about copying. Don't bother even checking if it's a symlink. A symlink is a file. Just open it and read it.
> But how do you find the old location? Do you need to build against both libraries, call old_lib.get_path(), check if it exists, then call new_lib.get_path() […] Can you even compile against both libraries if one is a fork of the other (namespace issues)?
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.
From my previous recollection, there's an issue for this in just about every rust crate that handles these dirs. The right way to fix this is fix the spec, then make the libs adhere to the spec.
How would you fix the spec? Add a line explicitly stating the /Library/Application Support dir is only for applications with a bundle ID, instead of just implying it?
For clarity, is this what you're referring to as "the spec"? https://developer.apple.com/library/archive/documentation/Fi...
No the xdg base directories spec. If you want to be able to opt in to dry on a system which doesn’t canonically use xdg vars, then you need some config.
XDG is cross-distribution for Linux, but it's not cross-platform. MacOS doesn't use XDG.
The maintainer's advice is correct, on mac you should store configs and other stuff in Library/Application Support, that's the mac convention to use on mac, just like xdg is linux convention to use on linux.
I think there should be two crates in rust-land. The answer by @soc makes sense for apps, as the article discusses. Many (most?) people building Rust programs aren't making apps and so shouldn't be using this crate, which clearly and definitively only supports MacOS "Apps".
What does making a different choice for GUI and CLI apps achieve, other than making it impossible to ever have a single coherent place to look/synchronise/etc?
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.
It sounds like https://docs.rs/etcetera/0.3.2/etcetera/index.html provides sufficient flexibility for apps that want this.
A CLI app is an app.
Not in Apple's nomenclature, it isn't. An App specifically refers to a folder named ".app" with an info.plist and a binary inside of it. It can also contain a bunch of other metadata and application data. To apple, a "CLI app" as you call it is just the binary (a single file).
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.
What you are talking about is an application bundle.
Why is that soc guy so angry and rude about it?
I assume they've made up their mind and are now just tired of discussing it. I don't know why they refuse to even consider an option for it.
The library addresses your use case: provides location to store configs. You're asking for your personal feature.
Imagine having built some software, abiding to a standard that to your understanding is the standard to abide to. Then comes people who ask you to break that standard and change your software. Again and again they come. Others ridicule your stance on social media and forums like these. It's burning out.
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.
> 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.
I used pestering for OP's "I and others have brought this up (...) but they refuse to see it this way (...). It's very frustrating."
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?
Then maintainer will stop maintaining and you will have to fork anyway. So it's lose-lose for everybody.
Fork and move on with your life.
I don’t think it’s unreasonable to be demanding when this refusal negatively affects a lot of other rust software
It's not an official package. Developers of other Rust software can always build the same functionality on their own or fork.
But the effect trickles down to many end users
[flagged]
It's unkind to publicly speculate on this in this particular way, IMO.
Kindness is reciprocal, IMO. But I will concede speculation is unproductive.
Certainly doesn't make me want to become a Rust contributors.
dirs is a library project not part of Rust the language’s stdlib. You’ll find just as surly responses in many libraries across many languages. It feels a bit absurd to judge the language ecosystem by the maintainer of a single library.
I've also been eyeing Rust, but coming from Go where you can build more or less complete cli tools with just the standard library I'm not overtly exited by occurrences like this.
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
It doesn't have very large standard library. It's just running on a different philosophy on not making the Standard Library "Batteries included". But I find you get less dependencies than npm. Not so many tiny left-pad like microlibraries.
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
If you’re allergic to external dependencies then one of the batteries-included languages is better for you.
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.
> 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.
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.
Oh yes... I am building Zed.
Amazing, 1473 dependencies!Why is this normalized?
1968 dependencies when building with --release. :|
> I'm not writing an app, just a CLI tool
but CLI tools are applications
No, they are not. Those two are very different in macOS, where the word ‘app’ means an Application Bundle, which is a directory with a .app extension, Info.plist file, a bundle identifier, have an expected directory structure per Apple guidelines, should be installed in /Applications or ~/Applications, and so on and so forth.
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.
That is covered in the article. An “App” on Mac is a specific thing with certain characteristics that CLI tools don’t have.
dirs maintainer is bit unhinge, maybe the high usage of crate has gotten to their head.
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.
The spec from Apple could be clearer, you have to read the tea leaves and both sides have enough ammo to argue for their interpretation. But as someone who doesn’t care either way where these are stored I think that makes me a bit more objective than people who strongly have an opinion that they are looking to justify.
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.
From the same person: https://soc.me/standards/defending-home
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?
That hyperlink redirects back to HN. There's JS on the site that redirects 'undesirables' like HN, formerly Reddit, and lobste.rs.
> they refuse to see it this way
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.
> That's why the long-term future of app development is containers.
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.
If people have refused to do the right thing for 20 years, they're not about to start now just because you say so.
A mature technologist must be pragmatic if he wants to get anything done. Isolation technologies work. Scolding doesn't. We tried.
> If people have refused to do the right thing for 20 years...
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.
>But that's Microsoft.
They do the same on windows. Recent microsoft tools are written linux-first, even dotnet.
Do they started to respect the standards and lore of the operating system they used to loathe*?
That'd be interesting, honestly.
*: I have seen it all. I don't buy the OpenWashed Microsoft of today.
Including the standard of little knowledge of windows.
How is it even common good though? The articles main argument is that the author didn't expect the files there, not that it was causing any kind of issue. The problem is that people disagree where a config file should go, and there's no compelling reason why either of them are right or why it even matters.
I have absolutely no opinion on "common good" or "standard" here.
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.
I've been using macos for years, I just learned .config was a standard in this thread, because damn nearly everything shoves files in ~ so I just assumed that is where config files go.
Don't blame people for doing what 90% of apps do and assuming everyone else is correct.
It's a shame that MacOS doesn't have an equivalent for Boxxy.
> The XDG specification has been around for 22 years.
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).
I'm confused.
$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.
I'm not sure where you got that XDG_DATA_HOME has to be read-only, I couldn't find anything like that
> $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
The spec says
"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?
Just dumping everything in ~/.config instead of home will be a good start. It can be improved incrementally from there.
I disagree with this.
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`.
I kinda wonder if this is an age thing as the English language morphs over time.
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's even in the name: a command line application. The disconnect comes from Apple adopting the term "app" when they launched the App Store in 2008. And the aggressive marketing campaign with phrases like "there's an app for that". The word changed (in some minds) from meaning "any executable" to one that is on a phone.
Before they rebased onto UNIX, Mac files had two parts: a data fork and a resource fork. Data had the binary. Resource had strings, images, and other assets that the binary needed.
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.
On the 68K Mac applications, the executable code was also a resource ('CODE'). When they switched to PPC, PPC code went into the data fork.
> Why would macOS get bundled in with Linux? Because it's a unix? That's silly.
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.
> 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.
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.
> 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.
> Linux has no 'proper' directory for storing configuration,
/etc ?
> cache
/var/cache, /var/tmp ?
> and application user data.
/var ?
It's a stretch to say /var is for application _user_ data. For a certain value of "user" sure, like MariaDB or Redis. They're "users", and have data in /var but it's a non-interactive session.
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.
Those aren’t writable for users.
~/.var is writable for users, which leads to ~/.var/app/$APP/cache per app.
In my 40 years on this planet I have never once seen a ~/.var directory.
You only really see ~/.var for flatpaks.
> I wouldn't put stuff in to `%HOME%\.config` on Windows
Haha, and yet so many (usually Linux-first) applications do. Here's `gci $env:USERPROFILE -Force` on my computer:
Observe how not a single dot-directory has the hidden attribute set[1]. This is classic Linux-first development.[1]: https://github.com/MicrosoftDocs/win32/blob/27277910169f4e1b...
Had a chuckle at "classic Linux-first development", it's every OS except Windows - Windows is the outlier here, and I know plenty of engineers (myself included) which have no interest in trying to make things work in the Windows ecosystem. So I guess in the same way that roads are "classic wheel-first infrastructure", you don't try to pave a swamp.
> Windows is the outlier here
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.
You must be aware that ACLs are well supported by all major UNIX operating systems (yes, Linux is UNIX, there are/were two general-purpose Linux distributions certified as UNIX). It's just that basically nobody is using them because they're rarely necessary, and there are easier ways to implement access control if you want something simpler, and also far more powerful mechanisms for when that's needed.
I was responding to your comment about hidden (.) files vs extended attributes. As much as I do not like Android - it does respect hidden files.
I don't 'bother releasing stuff for Windows', as I said - for me it's not worth the pain.
It's hard to tell how your commment was a sincere response rather than derision for anyone using or targeting Windows. There was nothing technical. Here's a technical response:
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...
It's standard convention for (mostly GUI) applications to visually hide files and directories that start with a ., I don't know what you think a hidden folder is if it's not this and it has been widely accepted in the industry as a whole (except in Windows) for a very long time.
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.
I am confused. My point was that if engineers target Windows at all, they ought to do it properly, but you retorted with 'I don't target Windows'. Okay, well and good, then my advice isn't for you and developers like you.
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.
> Windows is the outlier here, and I know plenty of engineers (myself included) which have no interest in trying to make things work in the Windows ecosystem.
... But it's still much larger than everything else put together, no?
Not for servers, containers, embedded or IoT devices which is the vast majority of the internet.
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).
Is it? Remember servers exist.
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...
On the other end, when Windows first started having multiple users and locking down write access to system directories (*), lots of video games (and some other programs besides) decided to just dump their files anywhere. Just looking at my own system, I see all of the following used:
As far as I can tell, there's no rhyme or reason to any of this. I know the three AppData folders have distinct meanings, but I don't think video game developers are using them according to their proper meanings. Also, I'm being generous with my use of variables above. Some programs have hardcoded the drive letters and paths.* = I'm well aware of the real history of Windows NT but from the consumer perspective it went from 98/Me -> XP
Unfortunately, there is a reason. During the Vista timeframe, Microsoft published guidance recommending that game developers use the Documents folder for save games, as part of the push to make games compatible with UAC and non-elevated user accounts.
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.
Yeah, the Windows directory story is a mess. Of all the vaunted backwards compatibility they offer, there are some very strange user-facing breaks that don't make much sense. The Home directory structure being one of them.
%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.
Free software developers are rarely interested in spending time on supporting unusual proprietary operating systems. You should be grateful all this software works there at all — some Windows users did not just moan on internet forums, but actually went and implemented support for their OS of choice in all these packages.
Oh, I'm well aware of this on Windows. It's stupid and easy enough to fix for the developer, but I'm also aware there is virtually no desire to implement.
Are you playing runescape at work? Or developing at home?
Developing at home.
If your binary is supposed to live in `/Applications`, by all means put its config in `~/Application Support`. If it lives in `/bin` or somewhere similar, or if its default or system-wide configuration go in `/etc`, config goes in `~/.config`.
Agreed! but mostly moot. As a general rule, CLI utilities which are just single binaries should not go in /Applications. That folder is for app bundles which are folders with a .app extension, an Info.plist file, etc. And its not on the PATH used in the shell (by default).
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.
It's not moot though, because this whole thing is about the CLI binaries (usually because of a decision made by a framework like dirs-rs) using 'Application Support' et al.
I meant to say that 'If your binary is supposed to live in `/Applications`, by all means put its config in `~/Application Support`' is moot because CLI binaries aren't in /Applications ever
That's what I was hinting at. MacOS is kind of split into two personalities, and the way to be a good citizen in the system is to respect the boundaries between those two personalities. CLI tools are definitely part of the Unix personality and should follow its conventions.
I prefer https://uapi-group.org/specifications/specs/configuration_fi...
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/.
uapi-group is systemd/linux specific and does not apply to MacOS or Windows.
Towards the end TFA claims that Apple’s bundled command line utilities, including zsh and vim, put their dotfiles in ~/.config. They don’t. They put them in the traditional BSD place, the user’s home directory ~/. Looking at mine now, I see .bash_login, .emacs (wow! that’s old), .lldb, .lldbinit, .vimrc, .swiftpm, .z{profile,env,rc} and a few others. I see no ~/.config directory.
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.
> 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
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.
Yes, ideally the tool should edit its own preferences. A quick and dirty tool might leave the user to run the macOS "defaults" command line utility themselves. It’s certainly no worse than looking up the dotfile format and firing up vi.
In what world is this user hostile behavior ideal? There is no way you can write a cli tool that is more ergonomic in editing plain-texty config format than a good code editor!
> 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.
> It’s certainly no worse than looking up the dotfile format and firing up vi
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.
Yeah nah. If your configuration has a schema (e.g. JSON schema), AI tools can do a magnificent job turning free-form requests in natural language to valid configuration. Even if your configuration does not have a schema, people can refer to snippets of configuration made by other people on the internet.
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.
> I see no ~/.config directory.
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.
As a decades long time Mac user, when I see something show up in ~/.config it just feels like a maladapted port. It's a similar feel to seeing .dotfiles that are not actually hidden on Windows. Like, whelp, they didn't even bother.
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.
> ~/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.
I agree with “should not go in ~/Library/Application Support”, but why would anybody put them there? The Mac way is ~/Library/Preferences, or, system-wide /Library/Preferences, and the use of NSDefaults.
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.
Put me in the disagree camp. The XDG spec seems like it is for X windowing-based systems, not the Mac, so that's not a reason to adopt. The author asserts what users expect, but without any evidence.
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 expect _applications_ to put their config there, as the author says; something that lives in /Applications or ~/Applications and has a bundle specifier.
I wish I expected CLI programs to put their config in ~/.config, but I do actually expect them to just dump them into ~ annoyingly
XDG directories for macOS dotfiles is my hill to tilt windmills.
To make it extra fun, my $HOME directory is immutable:
(Simply setting it read-only would work too.)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...
No, I think you should write more about it. Motivations, what about programs or scripts that require writing or at least modifying files in $HOME, etc.? You say it is rare, but is it really? Also what is your way when you want to communicate between two programs? What is your preferred method of IPC? I will check how much my system works if I do the same thing as you, on Linux. :D
FWIW I use firejail so applications cannot run anything in $HOME and temporarily (heh) mounted tmpfs (two separate options).
I want this, but also a LuLu firewall style permissions prompt to accept or decline writes to my ~
I'm curious if you make your home directory immutable, where do you store your files like pdfs etc?
honestly as long as they don’t use the home directory ill survive. vscode and similar apps not offering any alternative to home directory pollution kills me.
I assume this breaks vscode? Would love a writeup if you have time
It seems like the best of both worlds, here, would be to put the files in ~/.config/yourprogram, and symlink that to `~/Library/Application Support/org.example.yourprogram`. That would satisfy folks expecting to find it in either place. The only folks it wouldn't satisfy would be those complaining about the files being present in one of those places at all, and that seems like the least of the concerns compared to making sure people find it.
I doubt anyone running Unix-style command-line/TUI tools where the config files are expected to be edited by hand by the user is expecting to find it in the Application Support directory; that directory is not a directory that Apple intends for users to ever interact with directly:
> 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]
> where the config files are expected to be edited by hand by the user
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`.
Missing from the "hidden from the user" argument is the fact that .config, and dotfiles in general, are also hidden from the user. It's not the defining distinction that one may think it to be.
Command-line binaries are also typically installed at locations hidden from the user (/bin, /opt/homebrew, ~/.bin, ~/.cargo/bin). Further indication that the "app"-oriented Apple documentation is intended only to apply to "apps", which are installed at /Applications or ~/Applications.
(I maintain a fairly popular TUI library), and as a CLI/TUI user on macOS, I dislike the App Support folder a lot. But even though I dislike it, I'd expect that apps for mac should put their files there because the XDG spec doesn't apply to macOS. It's the wrong place, but the technically correct one. The right thing to do is fix the spec, and then fix the apps / libs to follow that.
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.
And I’d also argue that the App Support folder doesn’t apply to CLI/TUI config files either. Apple doesn’t force CLI programs it distributes from storing files in App Support. If this were the case, wouldn’t you also expect the .ssh folder to be relocated from $HOME to App Support on a Mac?
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.
Maybe it's because it's not their programs and they want to pull from upstream?
I completely expect for that to be the case. My point is, there are already programs distributed with macOS that don’t put config in the ~/Library/Application Support folder. Knowing this, I don’t see a good argument for (especially portable) CLI/TUI programs for keeping user editable config data in the App Support folder.
> this should be fixed by adding an explicit "I want XDG even though I'm on macOS" setting somewhere. Probably another environment variable.
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.
The xdg vars only control the location. There’s no var to control that xdg should be used. macOS has a canonical approach, which some tools choose to ignore. I want a flag to make that ignorance correct
I know, but if XDG vars controlling the location exist then obviously 'use XDG' is desired.
How does the XDG spec not apply to macOS, and what "fix" are you proposing? https://specifications.freedesktop.org/basedir-spec/latest/ https://www.theregister.com/2024/10/11/macos_15_is_unix/
> 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.
Because it was designed for Linux distros, by Linux distros, not UNIX vendors.
Where is XDG on Open Group standards?
Hidden from the average Joe who will see these unknown files as garbage and delete them, cf Android.
It seems like the roadblock is that most cli tools don't want to think too hard about XDG in the slightest, and they delegate to standard directory libraries.
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
The best of both worlds is respecting user configuration, not pollution
XDG is a Linux-centric spec. If we the people want it to be OS-agnostic, it needs to be vetted and designed for that. Until then I don’t see why macOS applications must adopt XDG, despite it being my preference.
from the article,
> 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.
> The XDG Base Directory Specification mentions Unix a few times but lists no carveouts for macOS or any other operating system.
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
The Go standard library uses ~/Library/Application Support as well [1]. Given the Unix credentials of Golang's top folks, I would assume there's a good argument in favor of this decision?
[1] https://pkg.go.dev/os#UserConfigDir
The argument is that there are two separate ideas: configuration for macOS apps (i.e., .app bundles) should be placed in Application Support (a platform standard), while CLI tools should be placed in .config (not a standard, but common practice). If you're going to have a single function that returns a path, you have to pick one, and Go picked the platform standard.
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....
which is some damn irony given:
And, while not _exactly_ related to this topic, this has also always rubbed me the wrong way:This CL documents the switch of UserConfigDir from ~/Library/Preferences to ~/Library/Application Support: https://go-review.googlesource.com/c/go/+/181177
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)
UNIX, Plan 9 and Inferno, aren't exactly the same as macOS, even if macOS is a certified UNIX.
POSIX exists, because out of UNIX System V, every clone went down their own merry way.
I don’t think I’ve ever encountered a command line tool that makes this mistake, hooray for me. On the other hand lots more today support XDG_CONFIG_* and don’t litter ~ with random .dir stuff. I really like the new era of CLI tools that’s trying to be excellent in every dimension. Hopefully whoever needs to see this does and gets with the program! Although if it puts this much bee in your bonnet you can always open a pr
> But suppose we accept that the XDG specification only applies to some Unix operating systems, despite making no mention of this.
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 XDG_CONFIG_HOME should point to ~/Library/Preferences.
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,
XDG_CONFIG_HOME points to wherever you set it; that is up to the user to decide.
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.
Why should it not. The easier case for me to defend is XDG_CACHE_HOME - if it defaults to ~/.Library/Caches then it makes life simpler on macOS as it means that you don't have to add other directories to be removed from your backups.
Regardless of the default value, I think we can all agree that supporting XDG_* would be a good start!
why are they named XDG_* like XDG_CONFIG_DIR?
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.
Can't you just std::env::var it? Why need a library? It's not even set on my MacBook though.
Yeah, the variable is usually unset, so you’ll want to have a default value in your code. Basically something like
Of course, if you decide to account for Windows / macOS conventions, it’ll be a bit trickier, but pulling in a library for that is a bit overkill, yeah.Adding a library for that is not overkill but just being polite to your users setting files where the OS suggests and not putting your ideas there,
Adding a library has nothing to do with that. You can implement it yourself in a few lines of code, especially if you only need one path, like configs. You do need to research for caveats (e.g. check $XDG_CONFIG_HOME on Linux and not just put it into ~/.config) but it’s not rocket science.
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.
I put them in a dotfiles directory and use `stow`[1] to symlink the contents to where applications expect them to be. Under that root I have a home folder that it is symlinked to `~/`, and I have and applications one that is symlinked to `Applications Support` through the `-T` argument of stow.
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.
[1] https://www.gnu.org/software/stow/
I also use stow on MacOS and have been pretty happy with it.
> […]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?
I have never seen this behavior on macOS and doesn’t make sense. However, some applications will save files by creating a copy and overwriting. Maybe that’s what the author experienced?
https://github.com/lra/mackup?tab=readme-ov-file#warning
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.
Personally I never experienced it (to the best of my knowledge).
Weird.
Both options are wrong on macOS.
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.
The semantic distinction you're trying to make is artificial, but also explicitly against Apple spec, so no, your approach is the wrongest as no-one would expect you edit configs there
> 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
To the best of my knowledge, it's incorrect to store anything other than plists in that directory.
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.
> Not all Windows applications should store all their preferences in the registry, either.
I'd honestly be fine if none of them did.
Agree. Registry is a fuck.
Strongly agree with the authors take. Is anyone aware of an alternative to dirs in the rust universe which follows XDG?
When I last encountered this (agreeing with the article author about the correct location for CLI tools being XDG_CONFIG_HOME), I found https://crates.io/crates/etcetera.
I wrote elsewhere that I think the solution to this is to add another variable to the XDG Base Directory Specification to explicitly opt into using XDG variables, and then to support that flag on libraries that target Windows / MacOS and which would otherwise choose mac Application Support / Windows AppData folders.
No just accept that XDG_CONFIG_DIR is not always ~/.config
Where did OP said that "XDG_CONFIG_DIR is always ~/.config"? You can of course set it to another directory, if you wish so, and that should be respected.
So set it to ~/Library/Preferences and no one should be complaining - Apple see configs in the correct place and XDG see it correct as well.
So why is there a problem?
Apple's docs have this to say about ~/Library/Preferences/:
This directory contains app-specific preference files. You should not create files in this directory yourself.
Provide the whole quote. Contains the user’s preferences. You should never create files in this directory yourself. To get or set preference values, you should always use the NSUserDefaults class or an equivalent system-provided interface.
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.
Somewhat related, a few weeks ago on Python Bytes I learned that there is a python module that abstracts various directory locations per-platform. For instance, you can use this module to find the location of the Movies directory, or the cache directory.
For example, on macOS:
or in Windows: https://pypi.org/project/platformdirsIf any Windows users are interested in this, you could help fix the linked PRs that will close this issue once the Windows aspects are addressed:
https://github.com/tox-dev/platformdirs/issues/368
The thing that annoys me more than the authors main complaint is when the XDG specs are ignored on windows and macOS (I.e. if XDG vars are set, respect them). I work on all platforms, I have decades old dot files that work on over 9 different operating systems that I have used extensively. Some programs force maintenance work I’d rather not. Another peeve in this space is programs that force absolute paths (worst offenders are the ones doing it for security theater, diaf gpg) or that lack any mechanism for platform or local overrides.
I guess while I’m here, please stop putting generated stuff in .config or even worse junk you downloaded, half of you without even checking it’s the right content or having any docs, ui or ux for cleaning up.
Has the XDG Base Directory Specification been adopted by an official standards committee? In my previous life, calling something a standard carried a great deal of weight. For example, contracts could mandate compliance with standards.
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.
Yeah, I broadly agree — even if I am primarily a Mac user, I am constantly annoyed by the odd tool that does that. SimonW’s “llm” tool is one of the offenders.
Ah, after all there aren't only the devs on Windows ecosystem that don't follow the guidelines where to place the configuration files.
Follow the link to the XDG spec, look who is the 3rd author. There is no reason for MacOS or the BSDs to implement a systemd spec. A specific example: XDG_RUNTIME_DIR is a feature of pam_systemd and nothing else.
This is a recurring pattern that systemd documentation is sold as "neutral" standard. The UAPI group is another example of this.
3rd author? Wow, I respect the effort you went through to find that one connection to systemd, however faint it may be.
Also, XDG_RUNTIME_DIR is a just a directory. Since when did directories become a systemd feature?
[flagged]
Wow I never thought about this, but I think I agree. Also Go does ~/Library/Application Support for os.UserConfigDir too [0]
[0]: https://pkg.go.dev/os#UserConfigDir
> given that macOS is a Unix by way of BSD.
Moreover, most versions of MacOS are certified Unix: https://www.opengroup.org/openbrand/register/
Unpopular opinion maybe, but even under Linux and BSDs I’ve felt that dot folders/files in home are poor practice. Hiding them was a band-aid for bringing *nixes into the GUI era and just adds an extra hurdle outside of the CLI, and many of them are overly specific compared to the other standard user folders.
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.
The hint is in the name. "Application Support" has a space in it, so it's not designed to be used for CLI config.
Are there still CLI tools that can't handle spaces in folder names?
It's annoying and not ergonomic.
~/. for Darwin, ~/Library/Application Support for macOS. That simple.
That sounds like a good distinction.
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.
Possibly anything that makes use of Cocoa (this need not imply that it's a GUI tool) or other system frameworks like IOKit, CoreBluetooth, or CoreAudio.
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).
For everyone against .config on mac: who cares? I, for one, don’t want to deal with or remember different patterns across different OSes as much as possible. So I’ll install gnu coreutils on Mac, and I’ll use .config.
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.
> a command-line tool is not the system or an app
Meh. An application is an application.
Nope. In macOS, "app" has specific meaning -- implying plist file, etc. See discussion elsewhere in the comments above.
[flagged]
[dead]
Yes, they shouldn't, but try to convince people who misunderstood some poorly written Apple spec that they're wrong...