Live data from Hacker News

Use the XDG Base Directory Specification

xdgbasedirectoryspecification.com

121–130 of 214 posts

Re: Use the XDG Base Directory Specification

#121
post #91

Earlier quoted context omitted.

> That's not in the XDG spec. But it is. In the XDG user dir spec.

Wait, I get to blame XDG for this? I've never cared about dotfiles since they're invisible. But Videos, Pictures, etc. have always been a nuisance.

I shove them all into ~/docs and then edit my ~/.config/user-dirs.dirs file to match.

Re: Use the XDG Base Directory Specification

#123
post #41
post #27

Earlier quoted context omitted.

Yeah, it's a bit alien on macOS. There is no good mapping for some of these folders. For example, on macOS application configuration isn't even supposed to be done directly via application-specific files . macOS has its User Defaults subsystem, with `defaults read`/`defaults write` commands. And of course this isn't usable by typical command-line tools that don't have a Bundle ID.

The system that you mentioned is specifically for macOS Desktop apps. I think even Apple is drawing a line there. I don‘t know of any Apple commandline tool which has a configuration in plist format etc. But I might be wrong.

Apple ships some BSD and Linux tools (openssh, git) without changing how they store configuration, but anything written with macOS in mind has other methods. For example, Apple's command-line build tools for Xcode inherit GUI Xcode's settings and project files that are plists. launchctl uses XML plists in ~/Library instead of /etc. Daemons like Spotlight and Time Machine are configured via plist-editing GUIs or mdutil/tmutil commands.

Re: Use the XDG Base Directory Specification

#124

Yeah, we have a straightforward and widely established standard. Just put the related files in .programname . Now let's bikeshed and scatter them randomly across several places. To make it more fun let's make those locations programmable with environment variables so you won't even know where to start looking for a particular related file. Add lots of categories to create ambiguity. Make some of the default locations…

>let's make those locations programmable with environment variables so you won't even know where to start looking for a particular related file

What? Just use the environment variable when reading.

Re: Use the XDG Base Directory Specification

#125

XDG sucks for the only reason that it is really difficult to configure user directories to one's taste. For instance, to get rid of Download, Templates, Desktop, Public Share, Documents, Music, Pictures, Videos directories I not only have to point them to somewhere else, I also have to make sure Desktop and Download do not point to the same directory, otherwise my config will not be used. Here, after literally hours…

The XDG user dirs are not part of the XDG basedir spec.

Re: Use the XDG Base Directory Specification

#127
post #96

Earlier quoted context omitted.

.gitignore in $HOME/.config: ``` * !nvim/ !dunst/ !i3/ ``` Then you have a whitelist which is clearly not that hard to maintain For the cache, the opposite argument is just as true: If I want to clear cache from everything to save space, I can just `rm -rf ~/.cache` instead. And this case is a lot more common than wanting to "start from a clean profile" :/

> I can just `rm -rf ~/.cache But can you? Did you really close all the apps using ~/.cache? What if some app is just doing some cleanup operation, moves a bunch of stuff to cache, and the files are missing now? Did you just delete android studio cache in the middle of a compile? You can also make a script like your .config, but it's called "clear_cache.sh", where you hardcore a few paths you usually clean manually.

Programs that cannot deal with removing ~/.cache at any point are simply faulty because at that point it is state and not cache which by definition can be recreated at the point of access.

Re: Use the XDG Base Directory Specification

#128

Yeah, we have a straightforward and widely established standard. Just put the related files in .programname . Now let's bikeshed and scatter them randomly across several places. To make it more fun let's make those locations programmable with environment variables so you won't even know where to start looking for a particular related file. Add lots of categories to create ambiguity. Make some of the default locations…

That has never been a standard as many programs have multiple dotfiles in ~. But even if it was, there are still good arguments for the XDG Basedir Spec: common way to change the location via environement variables as well as ability to split cache and non-cache.

Re: Use the XDG Base Directory Specification

#130

I'll take the other side of this. We have this concept of applications being "well behaved" if they only read and write from parts of the filesystem that users expect. The XDG directories are what most linux and macOS users expect, even if they don't know about the standard. This well-behavedness feeds into the larger idea of high quality software. Hiqh quality means users are more likely to recommend it, engineers a…

You can't technically enforce an application to cleanly split cache and configuration data and you will probably already fail to enforce splitting application data and user data for applications that need to access user data.

Technical enforcement is also not free - it has both a performance and usability cost at applies to everyone not just bad actors. One of the things I like about free software is that it allows for high trust environments because you don't need technical restrictions but can instead rely on people not being dicks. I consider this similar to wanting to live in places where I don't have to worry about locking my doors and closing all windows every time I go to the store.

Post reply on HN