The thing that annoys me more than the authors main complaint is when the XDG specs are ignored on windows and macOS (I.e. if XDG vars are set, respect them). I work on all platforms, I have decades old dot files that work on over 9 different operating systems that I have used extensively. Some programs force maintenance work I’d rather not. Another peeve in this space is programs that force absolute paths (worst offenders are the ones doing it for security theater, diaf gpg) or that lack any mechanism for platform or local overrides.
macOS dotfiles should not go in –/Library/Application Support
81–90 of 223 posts
Re: macOS dotfiles should not go in –/Library/Application Support
#82The thing that annoys me more than the authors main complaint is when the XDG specs are ignored on windows and macOS (I.e. if XDG vars are set, respect them). I work on all platforms, I have decades old dot files that work on over 9 different operating systems that I have used extensively. Some programs force maintenance work I’d rather not. Another peeve in this space is programs that force absolute paths (worst off…
I guess while I’m here, please stop putting generated stuff in .config or even worse junk you downloaded, half of you without even checking it’s the right content or having any docs, ui or ux for cleaning up.
Re: macOS dotfiles should not go in –/Library/Application Support
#83Earlier quoted context omitted.
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.
Regardless of the default value, I think we can all agree that supporting XDG_* would be a good start!
Re: macOS dotfiles should not go in –/Library/Application Support
#84> a command-line tool is not the system or an app
Meh. An application is an application.
Re: macOS dotfiles should not go in –/Library/Application Support
#85Wow I never thought about this, but I think I agree. Also Go does ~/Library/Application Support for os.UserConfigDir too [0]
Re: macOS dotfiles should not go in –/Library/Application Support
#86Earlier quoted context omitted.
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.
Regardless of the default value, I think we can all agree that supporting XDG_* would be a good start!
Can't you just std::env::var it? Why need a library? It's not even set on my MacBook though.
Re: macOS dotfiles should not go in –/Library/Application Support
#87I 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…
Why is that soc guy so angry and rude about it?
Imagine having built some software, abiding to a standard that to your understanding is the standard to abide to. Then comes people who ask you to break that standard and change your software. Again and again they come. Others ridicule your stance on social media and forums like these. It's burning out.
It's free and open-source for heaven's sake! If you don't like it, fork it, patch it, make your own custom version. But stop pestering maintainers with demands.
Re: macOS dotfiles should not go in –/Library/Application Support
#88XDG directories for macOS dotfiles is my hill to tilt windmills.
To make it extra fun, my $HOME directory is immutable:
chflags uchg "${HOME}"
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...
Re: macOS dotfiles should not go in –/Library/Application Support
#89XDG 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.
from the article,
> Elsewhere, Reilly Wood rebukes a user asking if there would “be any downside to just not using Application Support ever” by saying that “[Nushell would] no longer be following the macOS Standard Directories guidelines.”
> We’ll read through those guidelines in a minute, but it’s not entirely clear to me that they’re relevant in the first place. The XDG Base Directory Specification mentions Unix a few times but lists no carveouts for macOS or any other operating system. If ~/.config is accepted as the standard location for configuration files on Unix-like operating systems, then surely it would be the standard location on macOS as well, given that macOS is a Unix by way of BSD.
> But suppose we accept that the XDG specification only applies to some Unix operating systems, despite making no mention of this. The macOS Standard Directories documentation starts by stating that “[w]hether provided by the system or created by your app, every file has its place in macOS”, and honestly we could stop reading right there, because a command-line tool is not the system or an app.
Re: macOS dotfiles should not go in –/Library/Application Support
#90I 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?
I have never seen this behavior on macOS and doesn’t make sense. However, some applications will save files by creating a copy and overwriting. Maybe that’s what the author experienced?