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 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())
}
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
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 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?
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.
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`.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
35 comments
[ 2.5 ms ] story [ 47.1 ms ] threadI now use a combination of xdg + known-folders manually:
to get the config directory: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.
Moreover, most versions of MacOS are certified Unix: https://www.opengroup.org/openbrand/register/
[1] https://pkg.go.dev/os#UserConfigDir
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.
This is a recurring pattern that systemd documentation is sold as "neutral" standard. The UAPI group is another example of this.
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.
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/
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.
For example, on macOS:
or in Windows: https://pypi.org/project/platformdirshttps://developer.apple.com/library/archive/documentation/Fi...:
“This directory contains app-specific preference files. You should not create files in this directory yourself. Instead, use the NSUserDefaults class or CFPreferences API to get and set preference values for your app. In iOS, the contents of this directory are backed up by iTunes and iCloud.”
If a tool doesn’t want to use NSDefaults, using ~/.config is way preferable over polluting the user’s home directory, as many tools do.
Meh. An application is an application.