Hacker News Reader

Comment by JoshTriplett | Hacker News Reader

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.

View on HN

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]

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

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

How does the XDG spec not apply to macOS, and what "fix" are you proposing? https://specifications.freedesktop.org/basedir-spec/latest/ 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.

Because it was designed for Linux distros, by Linux distros, not UNIX vendors.

Where is XDG on Open Group standards?

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.

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.

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.

> this should be fixed by adding an explicit "I want XDG even though I'm on macOS" setting somewhere. Probably another environment variable.

Why another one? If an XDG env var is set explicitly, that's obviously what the user wants. Just don't (necessarily) use the spec's defaults when it's not set.

The xdg vars only control the location. There’s no var to control that xdg should be used. macOS has a canonical approach, which some tools choose to ignore. I want a flag to make that ignorance correct

I know, but if XDG vars controlling the location exist then obviously 'use XDG' is desired.

No. There are many situations where these are set where that’s not true.

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.

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.

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

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

The best of both worlds is respecting user configuration, not pollution

Reply on news.ycombinator.com