I like issues organized. Ideally, my residence listing will solely have a handful of information and directories, and I do know what they’re all about. BUT that is NOT the case 🏝️🚫
Some builders produce other concepts! Their apps plop their configuration and state info into my residence listing. They’re naughty!
I put this apart as one thing to look into after I had time (well-known final phrases). Nicely, its Spring time now, so spring cleansing popped into my head. Let’s look into spring cleansing your own home listing! Is it worthwhile to do?
For those who run the next command, you’ll find out what number of dot information and directories you’ve got in your house listing:
expr $(ls -lA ~ | wc -l | tr -d "[:space:]" ) - $(ls -l ~ | wc -l | tr -d "[:space:]")
And I did a wee little bit of tidy up not so way back! 🙈
These information aren’t in sight except you go on the lookout for them. Nicely, then do not be so anal!
That is true.
The most important gripe might be (internally), “I would like
ls -a to indicate a brief, tidy checklist and a few @#@! has ruined that for me”. It’s an emotional response.
On the finish of the day, this isn’t an vital factor to do. For those who can overlook the information, then it will not have an effect on how you utilize your laptop.
Observe: I’ve stopped caring about holding my residence listing clear. Whereas it could be good to do an
ls -aand see hardly something, it simply wasn’t well worth the continuous effort to wrangle applications into behaving. To not point out, many applications I take advantage of are sufficiently old that they predate the XDG specification and due to this fact do not comply in any case.
There’s worth in backing up your config information. It makes it easy to modify to a different distro, or recuperate from a hard-drive failure. If you’re doing that, I suppose there’s some worth in auditing the information, and understanding what’s what.
For those who put your information in a Git repo, it’s a bit awkward when there are particular person config information that you do not know about, and accumulate somewhere else over time. Like just lately, I noticed
.bogofilter and thought who’s placing stuff in there? 🤨
You’ll be able to skip cleansing up by telling Git to incorporate all information besides X and Y through the use of a
.gitignore to solely goal the information you have an interest in. No matter your backup answer is, you may most likely skip cleansing up by doing a broader backup.
I discover myself resisting the urge to maneuver information. I believe there’s extra worth in spending just a little little bit of time to familiarize myself with my config information, earlier than I implement a backup technique. This fashion I’ve extra readability on what I’m holding onto. I am not taking part in sheriff and reprimanding each single rogue app that dumps information! 🤠
It’s possible you’ll really feel completely different, and that’s high quality!
There’s a specification referred to as the XDG Base Directory Specification created by freedesktop.org, which units out the place apps ought to put their information. Under are some examples of the surroundings variables it makes use of:
export XDG_CONFIG_HOME="$HOME/.config" export XDG_CACHE_HOME="$HOME/.cache" export XDG_DATA_HOME="$HOME/.native/share"
It’s not a proper commonplace, however many apps observe this spec. The Arch Linux wiki has a page on XDG Base Directory Spec that lists the apps that help the spec totally and partially. It additionally lists some apps that dont, which have hardcoded paths as a substitute.
Offending apps fall into 3 broad classes.
The primary class is apps have their very own surroundings variables that they seek the advice of to search out the situation of their configuration information. So, if the title of this variable, you may set it to
$HOME/.config/<app_name> your self in your one in every of your surroundings information (
.bashrc) to get it on monitor with the others.
The second class is apps that don’t have surroundings variables however can nonetheless be informed the place to search out configuration info utilizing a command line change. To repair this for CLI apps, you might add an alias to your shell config to make sure it all the time makes use of this flag. A typical instance is
wget all the time dumps its historical past information within the residence listing. You may make it use the XDG cache residence folder as a substitute with this alias:
alias wget='wget --hsts-file="$XDG_CACHE_HOME/wget-hsts"'
For GUI apps, you’ll need to alter the shortcuts (
.desktop information) to run the the identical command.
The third class is apps which have hardcoded paths. The builders would wish change their code to repair this state of affairs. There are some previous, well-established apps which have builders which might be reluctant to alter something like this for the worry of breaking issues. So, these are those you most likely want to just accept, or you are able to do some sleight of hand trickery to idiot apps into pondering their hardcoded path is similar because the XDG spec.
It appears to me that it’s important to repair these manually, for essentially the most half. There are some instruments folks have written to help with this course of, personally I might be a bit cautious utilizing them. In any case, it all the time greatest to back-up upfront in the event you do that.
You can begin on the guide route by every dot folder and file in your house listing to see in the event you can establish the app. You’ll be able to take a look at the partially supported list talked about within the Arch Linux wiki to see if any apps you’ve got put in are on it.
The instruments I discovered are:
For those who check out apps and instruments right here and there, you may find yourself with information left behind relying on the way you take away them.
For instance, Debian distinguishes between eradicating a package deal (which leaves its config information behind, in case you re-install it later) and purging a package deal (which removes the package deal and its config information).
To purge all information associated to a package deal, you should use:
apt purge --autoremove <package-name>
This may first purge the package deal (i.e. take away it and all its config information), after which purge every other packages that:
- had been put in mechanically as a dependency of a package deal (the package deal you are purging OR another package deal),
- have since been marked as
apt-mark auto <package-name>,
- aren’t required by every other currently-installed package deal(s)
Examine with the package deal supervisor you utilize to see if there’s a related distinction with instructions for eradicating/uninstalling/purging packages.
Whereas it might be good to have your own home listing organized, it most likely isn’t well worth the effort to take action. Relying in your backup technique, it could be worthwhile to audit your config information and make sure that it contains all of them. I believe it’s higher to method it that method, moderately than on the lookout for methods to get applications to observe your desire.
What do you do?