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

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

#121

Post by maleldil » Tue, Aug 26, 2025, 12:26 PM UTC

evanelias wrote: post #16

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

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

#122

Post by vinnymac » Tue, Aug 26, 2025, 12:28 PM UTC

watersb wrote: post #88

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 want this, but also a LuLu firewall style permissions prompt to accept or decline writes to my ~

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

#123

Post by rollcat » Tue, Aug 26, 2025, 12:30 PM UTC

pie_flavor wrote: post #113

judofyr wrote: post #109

Earlier quoted context omitted.

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

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

#124

Post by llimllib » Tue, Aug 26, 2025, 12:34 PM UTC

evanelias wrote: post #16

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

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)

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

#125

Post by delta_p_delta_x » Tue, Aug 26, 2025, 12:39 PM UTC

ndegruchy wrote: post #120

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

> 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/27277910169f4e1b...

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

#126

Post by blueflow » Tue, Aug 26, 2025, 12:40 PM UTC

Hendrikto wrote: post #103

pdpi wrote: post #29

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

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.

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

#127

Post by codazoda » Tue, Aug 26, 2025, 12:43 PM UTC

ndegruchy wrote: post #120

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

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

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

#128

Post by delta_p_delta_x » Tue, Aug 26, 2025, 12:44 PM UTC

soni96pl wrote: post #76

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…

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

That hyperlink redirects back to HN. There's JS on the site that redirects 'undesirables' like HN, formerly Reddit, and lobste.rs.

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

#129

Post by franga2000 » Tue, Aug 26, 2025, 12:47 PM UTC

Hendrikto wrote: post #100

franga2000 wrote: post #93

Earlier quoted context omitted.

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…

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

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

#130

Post by linkage » Tue, Aug 26, 2025, 12:48 PM UTC

SulphurCrested wrote: post #72

varenc wrote: post #64

Earlier quoted context omitted.

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

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.

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.