> A shell script which checks your $HOME for unwanted files and directories.

IIUC, based on skimming some of the code, this seems to be for people who want to layout their home directory according to the conventions that the XDG group suggested [1], well into the history of Unix-y systems.

For example, a given tool, `foo`, might've originally created a `~/.foo/` directory, which `foo` still supports for backward compatibility, but `foo` now prefers XDG convention `~/.config/foo/`. `xdg-ninja` can inform you of that, and help you move the directory.

For another example, tool `bar` might still default to config file `~/.barrc`, but `xdg-ninja` might advise you to move it to XDG-like `~/.config/bar/rc`, and to set `bar`'s `BARRC` environment variable to point to that, even though `bar` doesn't use XDG conventions directly.

[1] https://specifications.freedesktop.org/basedir-spec/latest/

Yes.

See also: "$HOME, Not So Sweet $HOME" https://gist.github.com/sharadhr/39b804236c1941e9c30d90af828...

> Xdg

This is the crap responsible for poluting $HOME. If the user does not configure anything, just use global defaults.

I'm not sure how you came to that conclusion, but you got everything completely wrong.

First of all, writing state and configuration files in the home directory, without any well thought out structure, has been a common practice since UNIX existed, XDG did not even exist then.

Precisely because this lazy practice causes all sorts of problems, the cross-desktop group (XDG) came up with a standard called the "base directory specification"[1] which proposes to divide applications files into configuration, data, caches and are supposed to be stored in subdirectories named after the application in $XDG_CONFIG_HOME ($HOME/.config if unsed), $XDG_DATA_HOME ($HOME/.local/share if unset), $XDG_CACHE_HOME ($HOME/.cache if unset), respectively.

[1]: https://specifications.freedesktop.org/basedir-spec/latest/

> This is the crap responsible for poluting $HOME.

I think people who wrote software used $HOME for dotfiles way before XDG even existed.

> If the user does not configure anything, just use global defaults.

And if he does, where do you put the dotfiles? $HOME? XDG defines an cleaner hierarchy.

Clean hierarchy? How do I even guess if some config-file is hidden in ~/.config/ or ~/.local/share? I never figured that out. Looking at the contents of those directories here I can't guess better than a coin-toss. Why not just have a single ~/.dotfiles or something (if hidden files in ~/ is somehow a problem that needs to be solved)?

> How do I even guess if some config-file is hidden in ~/.config/ or ~/.local/share

A config file always belongs in ~/.config/PROGRAM. It never belongs in ~/.local/share/PROGRAM.

Data files (e.g. icons) belong in ~/.local/share/PROGRAM.

User-specific state (e.g. window positions) belongs in ~/.local/state/PROGRAM.

Executables belong in ~/.local/bin/.

Cached files (which may be deleted any time for space) belong in ~/.cache.

Source: https://specifications.freedesktop.org/basedir-spec/latest/

> Why not just have a single ~/.dotfiles or something (if hidden files in ~/ is somehow a problem that needs to be solved)?

I believe that the answer is that certain of those directories make sense to share across different hosts (e.g. your laptop and desktop) and others don’t.

> I believe that the answer is that certain of those directories make sense to share across different hosts (e.g. your laptop and desktop) and others don’t.

Also; Some of those directories make sense to flag for backup in your favorite backup software (personal settings, data files, etc), where others (cache) make sense to not waste drive space on backing up.

I believe the point they are making is that for plenty of tools people don't change any configuration settings. If I haven't changed from the application default setting, why is the application creating a configuration file in my home directory hierarchy?

Yes. That's the point. If i didn't ask for (a config) file, don't create one.

As a developer, I would rather have a default configuration file than hardcode the defaults into my own code, but that is just my opinion.

This. Bring back configuration via environment variables

Yes, I'd muuuch rather type `FONT_SIZE=7 FONT_FAMILY='DejaVuSans' FONT_WEIGHT=normal BG=black FG=pink FG_HL=blue BG_VISUAL=green THING='noremapsomething<vimscript>' vim` than polluting my home with a single ~/.config directory in which to put all my config files. And if that gets too long to type every time I start vim I can just make an alias and put it in a file and ..oh

And when I change a setting in a program, where does it set that environment variable?

> when I change a setting

when.

But why? I think a config file is way easier to understand.

RegEdit.exe welcomes you with open arms. It even supports multiple endian mixed encoding strings. Clearly it was designed for galactic scale.

I shall refrain from my usual XDG-hate rant, while still leaving this comment in here to potentially start the usual flamewar.

But why would anyone possibly hate XDG?!

Some people seemingly resent any functionality that wasn't part of V7.

This is one of the reasons I like Flatpak, it can force misbehaving apps to not pollute my home folder with their hidden .folders that never get cleaned up on removal and instead go in a managed directory where it belongs.

Interesting info about Flatpak. I didn't know that!

Unfortunately, conventions and suggestions only sometimes work in software development. There will always be developers who ignore or actively fight the conventions because it's important to them to do everything their way. This is usually the reason behind why we still have Windows applications trying to install themselves under the root C:\ directory and macOS applications that ship with an unnecessary installer rather than using the conventional "drag the app into the Applications folder."

flatpak creates more issues than it solves for me personally

Flatpak leaves stuff behind on uninstallation.

try flatsweep

I wonder if Firefox will ever fix this 20 year old issue https://bugzilla.mozilla.org/show_bug.cgi?id=259356 ?

It got soft-killed 12 years ago, by the looks of the thread[0]. Incredibly, some of the same people are still replying across the decades.

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=259356#c69

This is a tough problem to solve. I currently use NixOS with impermanence [1] which is one way of solving it. Impermanence, in short, allows you to explicitely opt-in the files and directories that are persisted after each reboot.

So while my `~` is not "clean" in the sense that all my config files are in `~/.config`, it is "clean" in the sense that all files in `~` are there for a reason (i.e., `~` is not polluted by the old config/cache of uninstalled packages).

[1] https://github.com/nix-community/impermanence

I'd rather have a polluted $HOME than a polluted env that slows down every fork.

The script should have a --without-env option or similar.