macOS dotfiles should not go in –/Library/Application Support • Hacker News Board

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

#191

Post by GoblinSlayer » Tue, Aug 26, 2025, 5:20 PM UTC

re wrote: post #6

JoshTriplett wrote: post #2

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

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

Hidden from the average Joe who will see these unknown files as garbage and delete them, cf Android.

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

#192

Post by soraminazuki » Tue, Aug 26, 2025, 5:21 PM UTC

donatj wrote: post #101

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

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

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

#193

Post by GoblinSlayer » Tue, Aug 26, 2025, 5:24 PM UTC

bayindirh wrote: post #179

GoblinSlayer wrote: post #176

Earlier quoted context omitted.

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

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

#194

Post by soraminazuki » Tue, Aug 26, 2025, 5:34 PM UTC

SulphurCrested wrote: post #47

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

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

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

#195

Post by ndegruchy » Tue, Aug 26, 2025, 5:38 PM UTC

kbolino wrote: post #173

delta_p_delta_x wrote: post #125

Earlier quoted context omitted.

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

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

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.

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

#196

Post by rblatz » Tue, Aug 26, 2025, 5:56 PM UTC

xyst wrote: post #158

orlp wrote: post #3

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(windo…

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.

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

#197

Post by mbreese » Tue, Aug 26, 2025, 6:38 PM UTC

GoblinSlayer wrote: post #184

mbreese wrote: post #25

Earlier quoted context omitted.

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…

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.

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

#198

Post by krackers » Tue, Aug 26, 2025, 6:53 PM UTC

brewmarche wrote: post #183

lukateras wrote: post #110

~/. 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).

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

#199

Post by anon7000 » Tue, Aug 26, 2025, 7:07 PM UTC

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.

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

#200

Post by smcleod » Tue, Aug 26, 2025, 9:06 PM UTC

zahlman wrote: post #149

smcleod wrote: post #132

Earlier quoted context omitted.

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