macOS dotfiles should not go in –/Library/Application Support

XDG directories for macOS dotfiles is my hill to tilt windmills.

To make it extra fun, my $HOME directory is immutable:

   chflags uchg "${HOME}"

(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...

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:

    [target.'cfg(windows)'.dependencies]
    known-folders = "1.2.0"

    [target.'cfg(not(windows))'.dependencies]
    xdg = "2.5.2"

to get the config directory:

    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())
    }

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`.

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 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.

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.

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

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/

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 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

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.

> 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.

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

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 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.

Strongly agree with the authors take. Is anyone aware of an alternative to dirs in the rust universe which follows XDG?

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:

    >>> appname = "SuperApp"
    >>> appauthor = "Acme"
    >>> user_config_dir(appname, appauthor)
    '/Users/trentm/Library/Application Support/SuperApp'

or in Windows:

    >>> user_config_dir(appname, appauthor)
    'C:\\Users\\trentm\\AppData\\Local\\Acme\\SuperApp'

https://pypi.org/project/platformdirs

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.

The hint is in the name. "Application Support" has a space in it, so it's not designed to be used for CLI config.

> a command-line tool is not the system or an app

Meh. An application is an application.

> given that macOS is a Unix by way of BSD.

Moreover, most versions of MacOS are certified Unix: https://www.opengroup.org/openbrand/register/

Yes, they shouldn't, but try to convince people who misunderstood some poorly written Apple spec that they're wrong...

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.