https://github.com/b3nj5m1n/xdg-ninja
This utility has been a lifesaver to clean up my home directory.
Use the XDG Base Directory Specification
61–70 of 214 posts
Re: Use the XDG Base Directory Specification
#62Somebody should tell that to the Rust people. They have a .cargo and a .rustup folder in ~, plus an extra heavy target folder for every project. Would be much nicer if they put the cache one .cache But they don't seem to care https://github.com/rust-lang/cargo/issues/1734 https://github.com/rust-lang/rfcs/pull/1615 https://github.com/rust-lang/cargo/pull/9178
I put it in another comment, but if you are Rusting on Linux, you can use boxxy to fix bad behaving applications.
Re: Use the XDG Base Directory Specification
#63It's important on any system, not just XDG. The OS will assume you do, and offer features based on it, such as cleaning cache dirs, emptying temp dirs, etc.
It's not just about being tidy, although it's important.
But remembering all that stuff is annoying.
If you use Python, the wonderful "appdirs" package will make using the best dir for the job on Windows, Mac and Linux, easy and transparent: https://pypi.org/project/appdirs/
I wish it was part of the stdlib.
Another thing that grind my gears is people putting files inside their code project folder for development.
It should be something configurable, that by default use the OS dir for prod, and "../var" dir with everything on it in dev.
Less gitignore trouble, let's watcher overhead, less indexing for nothing, less clutter in file explorers, less possibility for errors.
But you need to provide an easy way to locate those files, such as a cmd line entrypoints, otherwise it's painful.
Re: Use the XDG Base Directory Specification
#64Earlier quoted context omitted.
FYI, and nothing personal, but your comment is more or less coming across to me as "whelp, the inflexible delegation has spoken". I go to great lengths to maintain a flexible mindset, to try to get the best out of a new approach. Hearing/reading someone trying to throw a shallow take-down of something they haven't tried doesn't read as "ooh that person is so cool I'm super convinced"... it comes across more like "oh,…
> Hearing/reading someone trying to throw a shallow take-down of something they haven't tried I mean, I've lived with XDG messing up where my config files are for several years at this point. How much "trying it" do I have to do to be allowed to have an opinion?
> I mean, I've lived with XDG messing up where my config files are for several years
Why don't you set your XDG vars to where you want to put them then?
What's your alternative? Force everyone to follow your preference instead of having it configurable?
Re: Use the XDG Base Directory Specification
#65In case anyone else was wondering, XDG stands for X Desktop Group, an older name for freedesktop.org[0]. [0] https://en.wikipedia.org/wiki/Freedesktop.org
Oh huh, I was always under the impression that "X" meant "Cross", as in "Cross-Desktop Group", since they were working on standardizing things across different desktop environments. But I guess the "X" was just a reference to X11? I guess today it encompasses a lot more than X11-based stuff, though...
Re: Use the XDG Base Directory Specification
#66Earlier quoted context omitted.
If everything honored this spec, including the part where it reads environment variables to see where the different directories are, you could do that by sticking the right variables in your environment. I think the one legitimate exception to the rule is profile, because you need that in order to set the variables in the first place. So that one would somehow have to be hard coded to at least have a wider search pat…
Maybe your profile location ought to be something that you're able to set through chsh
There is a system-wide /etc/profile or /etc/profile.d/
Likewise, zsh will look for /etc/zshrc
And zsh will actually look at
$ZDOTDIR/.zshenv
$ZDOTDIR/.zprofile
$ZDOTDIR/.zshrc
$ZDOTDIR/.zlogin
$ZDOTDIR/.zlogout
https://eng.libretexts.org/Bookshelves/Computer_Science/Oper...
https://bash.cyberciti.biz/guide/Setting_system_wide_shell_o...
Re: Use the XDG Base Directory Specification
#67> ... State :... if the data is unique for a given machine, the file belongs [to $XDG_STATE_HOME / $HOME/.local/state] This statement is misleading/wrong. Like all other XDG stuff, it's not about the machine, it's about the particular user. Also, why does the author consider the given positive example clean and tidy, when it has files .profile and .bashrc placed directly in the user's home directory? Following the ru…
> This statement is misleading/wrong. Like all other XDG stuff, it's not about the machine, it's about the particular user.
No, it's correct. "State" data is machine-specific. You might run an application that needs to generate a machine-specific identifier on first run and save it somewhere. For someone who shares their ~/.config among multiple machines, that shouldn't be synced.
> when it has files .profile and .bashrc placed directly in the user's home directory?
There's no other good option, as you may have a chicken-and-egg problem: often people put their definition of XDG_CONFIG_HOME in their .profile or .bashrc. Bash can't know where to find the file if the file tells you where to find it.
Sure, it could just hard-code ~/.config (and that would be correct for most people), but for people who have it set to something else, now they just have an unwanted ~/.config directory. Might as well just stick it in ~/ and live with it.
Of course there are alternatives: someone could set those variables via a PAM module or some other mechanism that might be able to set it before the shell even starts, but I'm not sure we should expect that to be common either. You could also use /etc/profile or /etc/bashrc, but then you have to either set it for all users, or have an if/case statement or user-mapping file that sets things according to each user's preference. If this is a shared machine where most users don't have root access, then you need a mechanism that lets users update their preference.
Yes, I get that those things are not the common case: most people have a single-user desktop/laptop where they have root access. But we need to consider the edge cases too.
Re: Use the XDG Base Directory Specification
#68> ... State :... if the data is unique for a given machine, the file belongs [to $XDG_STATE_HOME / $HOME/.local/state] This statement is misleading/wrong. Like all other XDG stuff, it's not about the machine, it's about the particular user. Also, why does the author consider the given positive example clean and tidy, when it has files .profile and .bashrc placed directly in the user's home directory? Following the ru…
It doesn't feel tidy to have .cache or .config out at the root of home folder either. IMO, those should be pushed down into .local. At least with the xdg base spec you can do that!
That's the thing I always thought was weird: why isn't the default value for XDG_CONFIG_HOME ~/.local/etc, and XDG_CACHE_HOME ~/.local/var/cache? I guess they wanted to make it easier to find for people who wouldn't be familiar with the spec (i.e., most regular users).
Re: Use the XDG Base Directory Specification
#69One of the things that changed my life recently, that I hadn't seen before: NeoVim has a NVIM_APPNAME variable that lets you change the app name. So when I wanted to try AstroVim, I just set NVIM_APPNAME=astrovim, and dropped the files in ~/.config/astrovim instead of blowing up my existing (shitty) ~/.config/nvim. I really wish the idea of configurable appnames was a part of the spec! (or a well-known extension!)
It's a very recent neovim feature, so it has not been around to discover for that long
Re: Use the XDG Base Directory Specification
#70There is a changed version that includes drop-in config files, masking, and loading defaults from /usr/ instead of requiring full config files to live under /etc: https://uapi-group.org/specifications/specs/base_directory_s...
There is work going on at freedesktop to standardize drop-in config files:
«basedir: support separate (vendor/local) trees and masking for config files» https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_request...
«basedir: support drop-ins for configuration paths» https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_request...