7 ms·

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

• JoshTriplett 1y ago
  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.
  • re 1y ago
    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]
    • JoshTriplett 1y ago
      > 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`.
    • joshka 1y ago
      (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.
      • re 1y ago
        How does the XDG spec not apply to macOS, and what "fix" are you proposing? https://specifications.freedesktop.org/basedir-spec/latest/ https://specifications.freedesktop.org/basedir-spec/latest/ https://www.theregister.com/2024/10/11/macos_15_is_unix/ 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.
        • pjmlp 1y ago
          Because it was designed for Linux distros, by Linux distros, not UNIX vendors. Where is XDG on Open Group standards?
        • joshka 1y ago
          The XDG environment variables only apply to systems where the XDG spec is defined to be in place. You need one extra flag for defining that to be true. Given that macOS isn't a place where XDG is applicable, suddenly making it applicable would break every place that assumes that it's not applicable (e.g. I no longer have configuration for some utility that uses the pre-change value of the AppSupport folders.
      • mbreese 1y ago
        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.
        • GoblinSlayer 1y ago
          Maybe it's because it's not their programs and they want to pull from upstream?
          • 1y ago
    • JdeBP 1y ago
      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.
      • re 1y ago
        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.
    • GoblinSlayer 1y ago
      Hidden from the average Joe who will see these unknown files as garbage and delete them, cf Android.
  • tux3 1y ago
    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
  • eviks 1y ago
    The best of both worlds is respecting user configuration, not pollution
• orlp 1y ago
  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 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()) }
  • CGamesPlay 1y ago
    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".
    • adastra22 1y ago
      A CLI app is an app.
      • CGamesPlay 1y ago
        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.
        • adastra22 1y ago
• jitl 1y ago
  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
• wpm 1y ago
  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.
  • JoshTriplett 1y ago
    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.
    • rezonant 1y ago
      > Not all Windows applications should store all their preferences in the registry, either. I'd honestly be fine if none of them did.
      • LoganDark 1y ago
        Agree. Registry is a fuck.
  • eviks 1y ago
    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
• worthless-trash 1y ago
  [flagged]
• troupo 1y ago
  > given that macOS is a Unix by way of BSD. Moreover, most versions of MacOS are certified Unix: https://www.opengroup.org/openbrand/register/ https://www.opengroup.org/openbrand/register/
• hamandcheese 1y ago
  Strongly agree with the authors take. Is anyone aware of an alternative to dirs in the rust universe which follows XDG?
  • sunshowers 1y ago
    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 https://crates.io/crates/etcetera.
• evanelias 1y ago
  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 https://pkg.go.dev/os#UserConfigDir
  • pjmlp 1y ago
    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.
  • maleldil 1y ago
    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.html https://docs.rs/etcetera/latest/etcetera/app_strategy/index....
  • llimllib 1y ago
    This CL documents the switch of UserConfigDir from ~/Library/Preferences to ~/Library/Application Support: https://go-review.googlesource.com/c/go/+/181177 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)
  • mdaniel 1y ago
    which is some damn irony given: $ 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: $ rm -rf ~/go rm: /Users/mdaniel/go/pkg/mod/github.com/jmespath/go-jmespath@v0.4.0/.travis.yml: Permission denied $ rm -rf ~/go 2>&1|grep "Permission denied" | wc -l 686
• joshka 1y ago
  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.
  • pasc1878 1y ago
    No just accept that XDG_CONFIG_DIR is not always ~/.config
    • freehorse 1y ago
      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.
      • pasc1878 1y ago
        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?
        • chrisweekly 1y ago
          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.
          • pasc1878 1y ago
            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.
• evrennetwork 1y ago
  [dead]
• pjmlp 1y ago
  Ah, after all there aren't only the devs on Windows ecosystem that don't follow the guidelines where to place the configuration files.
• pdpi 1y ago
  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`.
  • varenc 1y ago
    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.
    • OJFord 1y ago
      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.
      • varenc 1y ago
        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
        • pdpi 1y ago
          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.
  • Hendrikto 1y ago
• zarzavat 1y ago
  The hint is in the name. "Application Support" has a space in it, so it's not designed to be used for CLI config.
  • sunaookami 1y ago
    Are there still CLI tools that can't handle spaces in folder names?
    • computerfriend 1y ago
      It's annoying and not ergonomic.
• eviks 1y ago
  Yes, they shouldn't, but try to convince people who misunderstood some poorly written Apple spec that they're wrong...
• sakjur 1y ago
  > 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.
  • pasc1878 1y ago
    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,
    • Ferret7446 1y ago
      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.
      • pasc1878 1y ago
        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.
        • 1y ago
• blueflow 1y ago
  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.
  • soraminazuki 1y ago
    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?
    • deleted 1y ago
      [deleted]
    • blueflow 1y ago
      [flagged]
• SulphurCrested 1y ago
  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.
  • varenc 1y ago
    > 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.
    • SulphurCrested 1y ago
      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.
• marcyb5st 1y ago
  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/ https://www.gnu.org/software/stow/
  • thehours 1y ago
    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?
    • marcyb5st 1y ago
      Personally I never experienced it (to the best of my knowledge). Weird.
    • portaltonowhere 1y ago
      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?
    • jsmeaton 1y ago
      https://github.com/lra/mackup?tab=readme-ov-file#warning 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.
• cedws 1y ago
  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.
  • deleted 1y ago
    [deleted]
  • sebws 1y ago
    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.
    • dwattttt 1y ago
      > 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
• rcarmo 1y ago
  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.
• nickm12 1y ago
  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.
  • llimllib 1y ago
    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
    • nickm12 1y ago
      We have different expectations I guess. I think of CLI as applications, even though they aren't "Mac Apps". I don't see what is gained applications putting their files in different places based on how I interact with them.
• hoherd 1y ago
  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 https://pypi.org/project/platformdirs
  • esafak 1y ago
    If 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 https://github.com/tox-dev/platformdirs/issues/368
• Someone 1y ago
  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/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html#//apple_ref/doc/uid/TP40010672-CH2-SW1 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.
• raggi 1y ago
  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.
  • raggi 1y ago
    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.
• dClauzel 1y ago
  > a command-line tool is not the system or an app Meh. An application is an application.
  • chrisweekly 1y ago
    Nope. In macOS, "app" has specific meaning -- implying plist file, etc. See discussion elsewhere in the comments above.
• camgunz 1y ago
  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 https://pkg.go.dev/os#UserConfigDir
• watersb 1y ago
  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...
  • johnisgood 1y ago
    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).
  • dkmar 1y ago
    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
  • vinnymac 1y ago
    I want this, but also a LuLu firewall style permissions prompt to accept or decline writes to my ~
  • qyckudnefDi5 1y ago
    I'm curious if you make your home directory immutable, where do you store your files like pdfs etc?
• donatj 1y ago
  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.
  • soraminazuki 1y ago
    > ~/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.
• pie_flavor 1y ago
  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.
  • Joker_vD 1y ago
    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.
  • judofyr 1y ago
    > 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.
• lukateras 1y ago
  ~/. for Darwin, ~/Library/Application Support for macOS. That simple.
  • brewmarche 1y ago
    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.
    • lukateras 1y ago
      CLI shortcuts are bridges from Darwin to macOS. I agree, ~/Library/Application Support.
    • krackers 1y ago
      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).
• ndegruchy 1y ago
  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`.
  • delta_p_delta_x 1y ago
    > 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: d---- 3/6/2022 04:39 .android d---- 6/9/2024 18:14 .cache d---- 31/7/2025 11:10 .claude d---- 16/8/2024 01:38 .config d---- 2/3/2022 07:25 .dlv d---- 7/8/2025 18:20 .dotnet d---- 19/7/2022 07:15 .eclipse d---- 1/4/2022 16:29 .fop d---- 12/10/2024 23:49 .get_iplayer d---- 26/8/2025 01:07 .gk d---- 26/8/2025 01:07 .gnupg d---- 31/12/2022 15:12 .gradle d---- 30/3/2025 15:10 .ipython d---- 22/10/2021 07:59 .librarymanager d---- 9/6/2025 17:53 .local d---- 26/11/2024 12:58 .lucid d---- 31/12/2022 15:14 .m2 d---- 3/11/2022 06:14 .matplotlib d---- 9/10/2024 20:24 .minio d---- 20/4/2023 13:16 .ms-ad d---- 4/5/2023 10:48 .nuget d---- 7/9/2024 02:05 .ollama d---- 2/9/2021 15:14 .omnisharp d---- 15/7/2022 06:10 .platformio d---- 18/6/2024 19:10 .redhat d---- 7/11/2023 12:49 .runelite d---- 2/7/2024 11:17 .sonarlint d---- 10/7/2025 04:42 .ssh d---- 27/12/2021 14:46 .templateengine d---- 9/2/2023 11:35 .thumbnails d---- 10/6/2023 09:15 .vscode d---- 3/4/2023 11:30 Calibre Library d---- 12/8/2022 18:56 dotTraceSnapshots d---- 22/8/2025 22:51 hdos d---- 9/11/2022 02:27 Heaven d---- 6/11/2023 17:29 jagexcache d---- 9/6/2025 17:53 pipx d---- 1/6/2023 07:52 RenPy d---- 1/9/2024 13:16 source d---- 22/8/2021 02:15 Tracing d---- 26/11/2024 16:31 Zotero -a--- 9/2/2023 04:13 53 .git-for-windows-updater -a--- 26/8/2025 00:45 1170 .gitconfig -a--- 16/8/2023 08:07 2413 .kdiff3rc -a--- 26/8/2025 00:59 20 .lesshst -a--- 6/9/2024 18:15 27 .node_repl_history -a--- 6/11/2023 17:29 90 jagex_cl_oldschool_LIVE.dat -a--- 22/8/2025 23:49 74 jagex_runescape_preferences.dat -a--- 22/8/2025 22:51 24 random.dat -a--- 6/11/2023 17:29 24 random2.dat -a--- 20/4/2023 13:50 0 Sti_Trace.log -a--- 22/8/2025 23:49 1 tfa.dat 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/27277910169f4e1bfc81fe6edaccab50464bb4d8/desktop-src/FileIO/file-attribute-constants.md?plain=1#L54 https://github.com/MicrosoftDocs/win32/blob/27277910169f4e1b...
• cosmic_cheese 1y ago
  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.
• SquibblesRedux 1y ago
  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.
• anon7000 1y ago
  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.