Nice! Was able to clean up lots of files that can live under ~/.config.
However, the very first thing this prints is
The $XDG_RUNTIME_DIR environment variable is not set, make sure to add it to your shell's configuration before setting any of the other environment variables!
⤷ The recommended value is: /run/user/$UID
Is this applicable to macOS? Some quick searching didn’t really give a definitive answer…
“Applicable” is very debatable. The XDG Base Directory Specification is in theory applicable to any POSIX-like system. But it is most “at home” on Linux and other systems that follow a more traditional Unix filesystem layout than MacOS offers.
If you mean, “can I use it on MacOS?” the answer is yes, with some caveats:
If you install an application (say, from brew) that uses the XDG Base Directory Specification for its file locations, then you may not have a choice but to create/manage XDG directories on MacOS.
Some XDG variables default to values that MacOS either doesn’t use or doesn’t have. For example, XDG_CONFIG_DIRS defaults to /etc/xdg which is not present on MacOS.
MacOS has its own application file organization system, mostly under ~/Library. If you want to use XDG-compatible apps, the “philosophically correct” thing to do is set the XDG base directories to their respective locations under ~/Library via shell environment variables yourself, as Apple does not do this for you. (Although I don’t know how you’d set environment variables for a GUI app in MacOS.) This gist may provide some guidance, although I am not convinced about all of their choices.
I version control my dotfiles, and I have a pet peeve of some cross-platform(!) *nixy terminal software that decides to use folders in ~/Library for macOS, in a misguided attempt to be more ‘native’ to the platform or something.
macOS is a certified UNIX, and a comfortable UNIX environment at that, there’s no need for a *nixy terminal program that uses all of macOS’ *nixy affordances and almost entirely works on its UNIX compatibility to try to be more native on macOS by putting its configuration somewhere I have to symlink them.
It’d be more native to just stick with the *nix conventions entirely instead of half-*nix–half-Aqua conventions. The UNIX side is just as much (modern) macOS as the Aqua side, even if it’s not the (especially) unique part about macOS. In fact, the Maccy parts are built on the UNIX foundation, the UNIXy stuff isn’t some separate compatibility layer on top of a Maccy foundation.
As for configuring XDG directories to be under ~/Library as a user, I’ve considered it before, but I think it’s better to maintain a separation between *nixy configuration which tends to have edited by hand, version controlled, and have their own config DSLs or use some simple config language, and configuration of macOS Aqua apps, which are machine-generated and -edited plist (i.e. XML) files that aren’t version controlled.
I just checked and I have an mpv.plist and io.mpv.plist in ~/Library/Preferences (I’m guessing one for mpv run from a terminal and the other for the mpv macOS application bundle). I was curious if the GUI mpv bundle had created an mpv directory in ~/Library/Application Support, like a lot of apps do for themselves, and it hadn’t, but if it had, and I’d set XDG_CONFIG_DIR="$HOME/Library/Application Support", the $XDG_CONFIG_DIR/mpv directory would have been an interesting conflict between the GUI bundle.
Even on Linux I don’t bother setting most of these if I’m happy with the defaults. Why clutter my profile script with setting XDG_CONFIG_HOME="$HOME/.config" when the spec says tools should use that value anyway when that variable is unset? Though maybe I really should set them all, since “explicit is better than implicit” as Pythonistas like to say.
Nice! Was able to clean up lots of files that can live under ~/.config.
However, the very first thing this prints is
Is this applicable to macOS? Some quick searching didn’t really give a definitive answer…
“Applicable” is very debatable. The XDG Base Directory Specification is in theory applicable to any POSIX-like system. But it is most “at home” on Linux and other systems that follow a more traditional Unix filesystem layout than MacOS offers.
If you mean, “can I use it on MacOS?” the answer is yes, with some caveats:
XDG_CONFIG_DIRSdefaults to/etc/xdgwhich is not present on MacOS.MacOS has its own application file organization system, mostly under
~/Library. If you want to use XDG-compatible apps, the “philosophically correct” thing to do is set the XDG base directories to their respective locations under~/Libraryvia shell environment variables yourself, as Apple does not do this for you. (Although I don’t know how you’d set environment variables for a GUI app in MacOS.) This gist may provide some guidance, although I am not convinced about all of their choices.I version control my dotfiles, and I have a pet peeve of some cross-platform(!) *nixy terminal software that decides to use folders in
~/Libraryfor macOS, in a misguided attempt to be more ‘native’ to the platform or something.macOS is a certified UNIX, and a comfortable UNIX environment at that, there’s no need for a *nixy terminal program that uses all of macOS’ *nixy affordances and almost entirely works on its UNIX compatibility to try to be more native on macOS by putting its configuration somewhere I have to symlink them.
It’d be more native to just stick with the *nix conventions entirely instead of half-*nix–half-Aqua conventions. The UNIX side is just as much (modern) macOS as the Aqua side, even if it’s not the (especially) unique part about macOS. In fact, the Maccy parts are built on the UNIX foundation, the UNIXy stuff isn’t some separate compatibility layer on top of a Maccy foundation.
As for configuring XDG directories to be under
~/Libraryas a user, I’ve considered it before, but I think it’s better to maintain a separation between *nixy configuration which tends to have edited by hand, version controlled, and have their own config DSLs or use some simple config language, and configuration of macOS Aqua apps, which are machine-generated and -edited plist (i.e. XML) files that aren’t version controlled.I just checked and I have an
mpv.plistandio.mpv.plistin~/Library/Preferences(I’m guessing one formpvrun from a terminal and the other for the mpv macOS application bundle). I was curious if the GUI mpv bundle had created anmpvdirectory in~/Library/Application Support, like a lot of apps do for themselves, and it hadn’t, but if it had, and I’d setXDG_CONFIG_DIR="$HOME/Library/Application Support", the$XDG_CONFIG_DIR/mpvdirectory would have been an interesting conflict between the GUI bundle.Even on Linux I don’t bother setting most of these if I’m happy with the defaults. Why clutter my profile script with setting
XDG_CONFIG_HOME="$HOME/.config"when the spec says tools should use that value anyway when that variable is unset? Though maybe I really should set them all, since “explicit is better than implicit” as Pythonistas like to say.This suggests a few possible ways to handle this though nothing I would call “definitive.”
https://stackoverflow.com/q/14237142/26702