Spring clean your home directory! Or should you? 🌻🧹🤔

I like things organized. Ideally, my home directory will only have a handful of files and directories, and I know what they are all about. BUT this is NOT the case 🏝️🚫

Some developers have other ideas! Their apps plop their configuration and state information into my home directory. They are naughty!

I put this aside as something to look into when I had time (famous last words). Well, its Spring time now, so spring cleaning popped into my head. Let's look into spring cleaning your home directory! Is it worthwhile to do?

How many dot files are in your home directory?

If you run the following command, you can find out how many dot files and directories you have in your home directory:

expr $(\ls -lA ~ | wc -l | tr -d "[:space:]" ) - $(\ls -l ~ | wc -l | tr -d "[:space:]")

I have 43!

And I did a wee bit of tidy up not so long ago! 🙈

Why bother?

These files are not in sight unless you go looking for them. Well, then don't be so anal!

This is true.

The biggest gripe is probably (internally), "I want ls -a to show a short, tidy list and some @#@! has ruined that for me". It is an emotional response.

At the end of the day, this is not an important thing to do. If you can overlook the files, then it won't affect how you use your computer.

Jake Bauer (not to be confused with the counter-terrorist agent Jack Bauer from the American TV show 24) wrote about this topic also, and at a later date he updated the article to say:

Note: I have stopped caring about keeping my home directory clean. While it might be nice to do an ls -a and see hardly anything, it just wasn't worth the continual effort to wrangle programs into behaving. Not to mention, many programs I use are old enough that they predate the XDG specification and therefore don't comply anyways.

There is value in backing up your config files. It makes it simple to switch to another distro, or recover from a hard-drive failure. If you are doing that, I guess there is some value in auditing the files, and knowing what is what.

If you put your files in a Git repo, it is a bit awkward when there are individual config files that you don't know about, and accumulate in different places over time. Like recently, I saw .bogofilter and thought who is putting stuff in there? 🤨

You can skip cleaning up by telling Git to include all files except X and Y by using a .gitignore to only target the files you are interested in. Whatever your backup solution is, you can probably skip cleaning up by doing a broader backup.

I find myself resisting the urge to move files. I think there is more value in spending a little bit of time to familiarize myself with my config files, before I implement a backup strategy. This way I have more clarity on what I am holding onto. I'm not playing sheriff and reprimanding every single rogue app that dumps files! 🤠

You may feel different, and that is fine!

How can you tidy up?

There is a specification called the XDG Base Directory Specification created by freedesktop.org, which sets out where apps should put their files. Below are some examples of the environment variables it uses:

export XDG_CONFIG_HOME="$HOME/.config"
export XDG_CACHE_HOME="$HOME/.cache"
export XDG_DATA_HOME="$HOME/.local/share"

It is not a formal standard, but many apps follow this spec. The Arch Linux wiki has a page on XDG Base Directory Spec that lists the apps that support the spec fully and partially. It also lists some apps that dont, which have hardcoded paths instead.

Offending apps fall into 3 broad categories.

The first category is apps have their own environment variables that they consult to find the location of their configuration data. So, if you know the name of this variable, you can set it to $HOME/.config/<app_name> yourself in your one of your environment files (~/.profile or .bashrc) to get it on track with the others.

The second category is apps that don’t have environment variables but can still be told where to find configuration information using a command line switch. To fix this for CLI apps, you could add an alias to your shell config to ensure it always uses this flag. A common example is wget always dumps its history files in the home directory. You can make it use the XDG cache home folder instead with this alias:

alias wget='wget --hsts-file="$XDG_CACHE_HOME/wget-hsts"'

For GUI apps, you will need to change the shortcuts ( .desktop files) to run the the same command.

The third category is apps that have hardcoded paths. The developers would need change their code to fix this scenario. There are some old, well-established apps that have developers that are reluctant to change anything like this for the fear of breaking things. So, these are the ones you probably need to accept, or you can do some sleight of hand trickery to fool apps into thinking their hardcoded path is the same as the XDG spec.

It seems to me that you have to fix these manually, for the most part. There are some tools people have written to assist with this process, personally I would be a bit cautious using them. In any case, it always best to back-up in advance if you do this.

You can start on the manual route by looking at each dot folder and file in your home directory to see if you can identify the app. You can look at the partially supported list mentioned in the Arch Linux wiki to see if any apps you have installed are on it.

The tools I found are:

• Lewis Cowper has a bash script he calls a dotcrap file (see accompanying blog post) that deals with some of the category 1 and 2 apps. It sets the app-specific environment variables and creates some aliases if you have the app installed. You source it in one of your environment files.
• rehome : This is a C program that persuades badly-behaved programs to obey the XDG Base Directory Specification. This is done by altering the value of HOME that an app sees when they are executed.

Can I prevent files from being left behind when I uninstall apps?

If you try out apps and tools here and there, you can end up with files left behind depending on how you remove them.

For example, Debian distinguishes between removing a package (which leaves its config files behind, in case you re-install it later) and purging a package (which removes the package and its config files).

To purge all files related to a package, you can use:

apt purge --autoremove <package-name>

This will first purge the package (i.e. remove it and all its config files), and then purge any other packages that:

• were installed automatically as a dependency of a package (the package you're purging OR some other package),
• have since been marked as auto with apt-mark auto <package-name>,
• aren't required by any other currently-installed package(s)

Check with the package manager you use to see if there is a similar distinction with commands for removing/uninstalling/purging packages.

Final word

While it would be nice to have your home directory organized, it probably is not worth the effort to do so. Depending on your backup strategy, it might be worthwhile to audit your config files and ensure that it includes all of them. I think it is better to approach it that way, rather than looking for ways to get programs to follow your preference.

What do you do?