Hacker News Reader

Comment by sph | Hacker News Reader

The worst offenders are CLI tools written by people on Macs that do not respect XDG, because it's not a thing over there. So every tool gets to pollute your dotfiles with its own stupid directory. .rustup, .mix, .npm, .yarn, etc.

But polluting your home directory like ~/go, without even the decency to hide it, is extremely rude and offensive.

View on HN

Weirdly, enough, golang is one of the only programming languages that actually has built-in support for a cross-OS config dir location: [os.UserConfigDir()][1].

I don't really ever program in golang, but whenever I write a Node.JS/Python tool that does need a user-global config file, I just write my own implementation of it:

  function userConfigDir() {
    switch (process.platform) {
      case 'darwin':
        return `${os.homedir()}/Library/Application Support`;
      case 'win32':
        if (process.env['APPDATA']) {
          return process.env['APPDATA'];
        } else {
          throw new Error('%APPDATA% is not set correctly');
        }
      case 'aix':
      case 'freebsd':
      case 'openbsd':
      case 'sunos':
      case 'linux':
        return process.env['XDG_CONFIG_HOME'] || `${os.homedir()}/.config`;
      default:
        throw new Error(`The platform ${process.platform} is currently unsupported.`);
    }
  }

[1]: https://pkg.go.dev/os#UserConfigDir

os.UserConfigDir was added in Go 1.13, which explains why it wasn’t used earlier.

.NET has it as well:

Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData)

> people on Macs

> pollute

gah, reminds me of my pet peeve.

Insert a drive, it gets .Trashes ._Trashes .DS_Store .fseventsd .Spotlight-V100 and other nonsense everywhere.

And if you are ever trying to recover a failing drive, do not mount it on a mac.

>But polluting your home directory like ~/go, without even the decency to hide it, is extremely rude and offensive.

Counterpoint:

I actually like having visible directories, versus having to figure out where in /usr/share or /usr/local/ or ~/.local or /var an installer chose to sneak their files in.

I got used to it and in HOME I put some of my manually installed tools like `AMD_AOCL` for the AMD AOCL libraries, `Android/android-studio` for Android Studio, `intel` for IPP/OpenAPI, etc.

Don't want it anymore? Easy rm -rf, no need to go digging for where it could be hidden.

The point of XDG is to take the guesswork out of it by having applications follow your stated preferences.

  "I actually like having visible directories, versus having to figure out where in /usr/share or /usr/local/ or ~/.local or /var an installer chose to sneak their files in."

You seem to be mixing together two concepts here:

1. The files created by the installer, which are handled by the package manager. I can consult my package manager for files created by a specific package: pacman -Ql package_name.

2. The files created after installation (user preferences, plugins). The program should follow the XDG specification.

I don't worry about where my distro package manager installs files.

Some install methods are outside of your package manager, but try to touch /usr or /opt or /var, like NVIDIA sh scripts and the likes.

And those should be avoided as much as possible because they're always problematic and break randomly. How could they not break, when the package manager doesn't even know they exist or what they depend on?

Well now we're going around in circles:

1. External install scripts that put stuff in system directories are sloppy and we don't like them

2. External install scripts that put stuff clearly-named non-hidden directory in your $HOME are better than the above

In theory, all applications following XDG would also solve the problem, as it has only 1 configuration directory. (Although I admit some apps use the data directory which brings it up to 2)

XDG isn't enforced, it's voluntary. So there will always be lots of applications not following it.

Reply on news.ycombinator.com