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.
macOS dotfiles should not go in –/Library/Application Support
61–70 of 223 posts
Re: macOS dotfiles should not go in –/Library/Application Support
#62If 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`.
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.
Re: macOS dotfiles should not go in –/Library/Application Support
#63I 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.
No just accept that XDG_CONFIG_DIR is not always ~/.config
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.
Re: macOS dotfiles should not go in –/Library/Application Support
#64Towards 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…
> 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.
Re: macOS dotfiles should not go in –/Library/Application Support
#65I 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…
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?
Personally I never experienced it (to the best of my knowledge).
Weird.
Re: macOS dotfiles should not go in –/Library/Application Support
#66Put 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.
Re: macOS dotfiles should not go in –/Library/Application Support
#67Earlier quoted context omitted.
No just accept that XDG_CONFIG_DIR is not always ~/.config
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.
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?
Re: macOS dotfiles should not go in –/Library/Application Support
#68I 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…
Sounds like it's time to make a fork of dirs-rs that actually follows the rules.
Most libraries that use dirs-rs are doing so because they don't want to have to think about those things. So if there were a library that did it right, you'd probably have decent adoption if it's a simple crate replacement.
Re: macOS dotfiles should not go in –/Library/Application Support
#69Earlier quoted context omitted.
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,
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.
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.
Re: macOS dotfiles should not go in –/Library/Application Support
#70XDG 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]