3 ms·
> $HOME/.local/share Just look at that path: "$HOME": It's my home directory. Cool. ".local": It's in my home directory, but local to it, and not somewhere
by quotemstr 8y ago
> $HOME/.local/share
Just look at that path:
"$HOME": It's my home directory. Cool.
".local": It's in my home directory, but local to it, and not somewhere else? This doesn't make a lot of sense, but er, Okay.
"shared": For Christ's sake, what is this? It's in my home, and local within it, but also shared? With whom? How? Why? I give up.
Why would anyone want to do this? What concrete benefit does this path give us? What specific thing does it let you do that ~/.myprogram doesn't? The article is bad, and the XDG standard is bad. The traditional approach is fine.
- git-pull 8y agoSome things XDG is trying to do that's not readily apparent: ~/.local: It's intended to be /usr/local in the user's home directory. There's a bit of a backstory here though: Linux distros don't follow `/usr/local` as well as BSD's, not much may be there. ~/.local/share: Same idea, for /usr/local/share. But on many linux distros, this is `/usr/share`. XDG is trying to do is mirror the system directories in the user's filespace. Let's assume there's going to be a lot of applications: they won't agree on where cache, config, and data storage is kept at within ~/.myprogram. With XDG, if someone wants to clean out all their cache files? rm -rf ~/.cache. The other thing is: Typically the user won't be looking at ~/.local/share/myprogram - it's for data the application itself is going to use. It doesn't really count against it. What I think we will be looking at though: configuration files. That's where I think XDG is kind of original - but it's really close to what /etc is. As for ~/.myprogram: I'd be okay with that, if it were purely configuration. But XDG serves the article writer's purpose fine: Keeping $HOME clean. I kind of think splitting between ~/.config, ~/.local/share, and ~/.cache ends up feeling more consistent with how linux/bsd organizes files.