[halostatue]

And yet you impose XDG (originally a GNOME specification) on macOS (completely unrelated to GNOME or Linux). On macOS, you should be looking in ~/Library/Application\ Support/op and ~/Library/Preferences/op/config.

I’ve got a script that I’m making conform to XDG, and it's a lot of work to make it work well because I have to know about three different roots for different things (configuration, temporary files, and persistent files). I’m not convinced that it's worth it, because it is no longer as easy as telling someone "uninstall this by doing `rm -rf ~/.PROGRAM`", but instead I have to say `PROGRAM self destruct` or something like that to clean up all the detritus (and what if it fails in the middle?).

[seanhunter]

I'm pretty sure the XDG base directory spec was not specifically a gnome thing. It came from freedesktop.org[1] if I remember correctly, and in fact gnome was not compliant to begin with[2]. That gnome wiki page references that the recommendation (which turned into the spec) came from freedesktop and documents the gnome "initiative" to become compliant. Freedesktop was focussed on compatibility between desktop environments and systems, so isn't just a linux thing.

[1] https://specifications.freedesktop.org/basedir-spec/latest/ [2] https://wiki.gnome.org/action/show/Initiatives/GnomeGoals/XD...

[halostatue]

Thank you for the information.

[maleldil]

As macOS user, I'd rather they use XDG than the "standard" macOS directories. Maybe there's a point to be made to use the standard if the XDG variables aren't set, but I'd generally avoid that for CLI apps. Having everything under ~/.config is more convenient.

[b0afc375b5]

Agreed. "Application\ Support" looks subjectively disgusting to me. It's the only path on my configuration with spaces. I have to use it because that's where vscode settings.json is placed.

[easton]

If it helps, it may have been for a good reason. Microsoft used to name the folder that stored user directories "Documents and Settings" so developers would be forced to make sure they could handle paths with spaces in them. Now, they call that folder "Users", and I had to make sure when I set up my Windows install that my name didn't have spaces in it so a bunch of apps didn't get screwy.

[moe]

Rest assured this is not subjective. It is objectively disgusting.

[halostatue]

I agree, but in the context of the original complaint — not respecting user and operating system locations — following XDG is anti-user.

I prefer `~/.config`, but it’s not where such configurations go on the Mac (and there are multiple applications that do it differently).

[dividedbyzero]

Big +1, macOS has a lot of UX wins, but their config directories aren't one. Also XDG allows me to have at least some things in the same place on Linux and macOS, which may be a very niche need, but still something I appreciate.

[soraminazuki]

I second this. There's no reason unix tools should follow convention designed for macOS GUI applications.

I also prefer XDG because it separates between XDG_DATA_HOME, XDG_STATE_HOME, and XDG_RUNTIME_DIR. The macOS convention does not.

[otikik]

+1 to this. I have been a MacOS-exclusive user for more than a decade now and `~/Library/Application\ Support/` is simply ugly and, dare I say, un-Apple like. It has a Window's "My Documents" vibe going on.

[anthk]

Not Apple, but that comes from NeXTStep. GNUStep users under Linux/BSD will have it too. And, OFC, WindowMaker users.

[otikik]

Interesting, I had no idea.

[fjfuvucucuc]

Xdg isnt just config. Using .config (xdg config) on Mac is super weird.

Xdg is also, .cache (xdg cache dir) for data that can be cleared on reboot allowing you to use tempfs for it (of course you can't because a bunch of shit uses it as a persistent cache for things they should be putting in .local/share/. (Xdg data dir).

This whole mess is so utterly fucked I gave up caring and just let the mess be.

[maleldil]

> Using .config (xdg config) on Mac is super weird.

Why? Using it makes macOS more similar to Linux, which I think is a good thing. It surely makes it easier to share configuration files between Macs and Linux machines.

Honestly, I don't see a single upside to using macOS's specific directories over .config/.cache/.local.

[halostatue]

There are operating system processes in place to help keep `~/Library/Caches` smaller (or at least somewhat constrained). They are not there for `~/.cache`.

[yencabulator]

I don't see anything saying that clearing ~/.cache on every boot is expected behavior. I see lots of real world behavior of using ~/.cache as a multi-gigabyte download cache you would not want to lose regularly.

[fjfuvucucuc]

Cache is for user specific, non essential data.

I'd prefer a multigigabyte download went in state or data dirs if you don't want to lose it regularly.

[eternityforest]

Most prsistent files should never be cleaned on uninstall, you don't know why they're uninstalling, it could just be a reinstall to fix something. Configuration might not need cleanup either.

Temporary files often shouldn't exist. If it's less that a few megabytes why is it touching disk unless it will be needed persistently? In any case the detritus doesn't matter, if it's big enough to care I'll see the disk space is low and find it with baobab at some point.

It's not perfect, but it's not a major nightmare.

For my part, I don't always follow XDG specs, I often just create ~/AppName, but sometimes I'll make more than one to keep features within one app separate. I put IP cam recordings in ~/NVR by default, and stuff like that, because the main app dir is all stuff you would backup and restore, which probably doesn't include NVR recordings for a home user.

[ClikeX]

Has a MacOS dev, I'd prefer config like this in my home directory so I can easily access it between MacOS and Linux. My expectation for CLI tools is that config is in $HOME/.config/.

[josephd79]

I agree, as of right now all my CLI tools are in $HOME/.config. Do you have some that are not?

[saagarjha]

~/Library/Application Support is typically used for GUI applications. Using XDG seems reasonable for CLI tools?

[RamblingCTO]

And who's using that? You'd break user expectations with that. Sometimes it's not about being most correct.

[halostatue]

Yet…that is exactly the argument of the original post. The banner argument is that VIM is wrong because it doesn’t use `~/.config/vim` and instead uses `~/.vim` … which it has used since before XDG was created. Vim also doesn’t use ~/.vim` on Windows (and the files aren't `.vimrc` and `.gvimrc`, but `_vimrc` and `_gvimrc`.

User expectations differ. The correct place to put application detritus is `~/Library` on macOS (`/Library` if it’s system-level with no user-level). I am surprised when a cross-platform library uses `~/Library` instead of XDG, but I am not unhappy with it.

Frankly, most programs should have a command like `show-config-paths` (`--show-config-paths`) so that you can see where the configuration, caches, etc. are on the platform you’re on, and possibly be told (a) whether they are overridden from default and (b) how to override them. It would be useful to have that output for both human and machine reading.

[IggleSniggle]

I agree 100% on having a command to this effect. I always make sure that there is a command to show the currently resolved configuration location, as well as printing out configuration (minus secrets) when the application starts in debug mode.

Furthermore, when you do '--help', whenever it's half-way reasonable, I will show you what your currently resolved settings are for any flags/variables/configs next to the corresponding flag, as well as the default value. I actually don't know why this isn't common.

[JoBrad]

Sounds like they have a single place to fix it, though, which is nice.

[halostatue]

Yes. I think that the plugins should probably not be in $XDG_CONFIG_HOME, but in $XDG_DATA_HOME, if I’m reading correctly.

But in part my point is that there's virtually no one who gets this correct either with Linux systems or macOS, which is what makes rants like the parent article so annoying.

[account42]

Plenty of programs get $XDG_CONFIG_HOME and $XDG_DATA_HOME.

The ones that don't are mainly lazy ports from Windows where that speration doesn't exist.