3 ms·

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 va

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,

Ferret7446 1y ago
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.
- pasc1878 1y ago
  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.
  - notpushkin 1y ago
    Regardless of the default value, I think we can all agree that supporting XDG_* would be a good start!
    - koakuma-chan 1y ago
      Can't you just std::env::var it? Why need a library? It's not even set on my MacBook though.
      - notpushkin 1y ago
        Yeah, the variable is usually unset, so you’ll want to have a default value in your code. Basically something like config_dir="${XDG_CONFIG_HOME:-$HOME/.config}/my-app" Of course, if you decide to account for Windows / macOS conventions, it’ll be a bit trickier, but pulling in a library for that is a bit overkill, yeah.
        pasc1878 1y ago
        Adding a library for that is not overkill but just being polite to your users setting files where the OS suggests and not putting your ideas there,
        notpushkin 1y ago
        Adding a library has nothing to do with that. You can implement it yourself in a few lines of code, especially if you only need one path, like configs. You do need to research for caveats (e.g. check $XDG_CONFIG_HOME on Linux and not just put it into ~/.config) but it’s not rocket science. And if you choose to just trust library authors, you are putting their ideas there instead. There’s that Rust crate that uses XDG on macOS, for example.
    - naikrovek 1y ago
      why are they named XDG_* like XDG_CONFIG_DIR? Why not just CONFIG_DIR? Doesn't matter. This whole situation is a mess, and it's still a mess in the year 2025. Clearly existing operating systems can't be changed significantly enough to change anything like this. but we're all still afraid to write new operating systems. We cling to MacOS, FreeBSD, Linux, and Windows as if our lives depend on it. Our lives do not depend on it. If we want a saner OS, we could have it, but we don't want it bad enough, I think. It's easier to just deal with the piles of horse manure that has been piled on top of everything. So we have a rather active bikeshed discussion on HN about whether or not to use XDG_*. We want to bikeshed more than we want to fix anything. Like all communities, this one also disappoints me.

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,

Ferret7446 1y ago

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.

pasc1878 1y ago
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.
- notpushkin 1y ago
  Regardless of the default value, I think we can all agree that supporting XDG_* would be a good start!
  - koakuma-chan 1y ago
    Can't you just std::env::var it? Why need a library? It's not even set on my MacBook though.
    - notpushkin 1y ago
      Yeah, the variable is usually unset, so you’ll want to have a default value in your code. Basically something like config_dir="${XDG_CONFIG_HOME:-$HOME/.config}/my-app" Of course, if you decide to account for Windows / macOS conventions, it’ll be a bit trickier, but pulling in a library for that is a bit overkill, yeah.
      - pasc1878 1y ago
        Adding a library for that is not overkill but just being polite to your users setting files where the OS suggests and not putting your ideas there,
        notpushkin 1y ago
        Adding a library has nothing to do with that. You can implement it yourself in a few lines of code, especially if you only need one path, like configs. You do need to research for caveats (e.g. check $XDG_CONFIG_HOME on Linux and not just put it into ~/.config) but it’s not rocket science. And if you choose to just trust library authors, you are putting their ideas there instead. There’s that Rust crate that uses XDG on macOS, for example.
  - naikrovek 1y ago
    why are they named XDG_* like XDG_CONFIG_DIR? Why not just CONFIG_DIR? Doesn't matter. This whole situation is a mess, and it's still a mess in the year 2025. Clearly existing operating systems can't be changed significantly enough to change anything like this. but we're all still afraid to write new operating systems. We cling to MacOS, FreeBSD, Linux, and Windows as if our lives depend on it. Our lives do not depend on it. If we want a saner OS, we could have it, but we don't want it bad enough, I think. It's easier to just deal with the piles of horse manure that has been piled on top of everything. So we have a rather active bikeshed discussion on HN about whether or not to use XDG_*. We want to bikeshed more than we want to fix anything. Like all communities, this one also disappoints me.