If something is worth doing, it is worth overdoing. The first part of this series dealt with getting basic dot file automation up and running, as well as letting the script recognize what system they were running on. https://hackernoon.com/dot-files-automation-c29bf63d765c This article will go further and dig into a modular, per system dot file structure that gains benefits from nested inheritance.
TLDR link to the repo if reading files is easier.
ridingintraffic/dotfile-automation_Contribute to ridingintraffic/dotfile-automation development by creating an account on GitHub._github.com
How does this work? There is a simple enough flow.[OS symlink] →[common_profile] → [os release profile] →[host profile]The complexity was needed because my work and personal laptops are both mac, then I work on four varieties of linux: Raspbian, ubuntu, centos, and kali. Therefore different needs for different systems. The detection function be found below
The meat of the script is identifying which machine I am working on and then either creating the proper symlinks, or loading the proper profiles. I understand that it might be less complex if that logic was simply in the dot file. However, the security minded might enjoy not having all of the dotfile information on every computer they are working on. Also if one is a work computer it might be a confidentiality issue if the dotfiles are doing some more “delicate” work, and therefore leaving work at work is beneficial. The symlink script that is used for this is below. There is some nice added safeguards to back up the old dot files before creating the new symlinks.
Next, one major annoyance I have when hopping from one machine to another is that my plain text notes don’t stay updated. Unfortunately the network where I spend many hours a day has evernote blocked and expose github. The wonderful workaround for this is to keep to some notes in git repos. However remembering to update them can be a pain, theres a function for that.
Finally, at work there is always the discussion of where we want to eat, and in order to help choose for us theres a function for that too. Some sleeps were added for suspense.
Hopefully the usefulness of a per system configuration can be seen. I also like to back up my configurations to ensure that when I break my system, or when it crashes I can recover quickly. The intent is to have a little bit of initial work when I created the system but then I should never have to worry about losing my work, ever again. Finally this all relies on the golden rule, in case of fire git commit, git push, leave building…. there is a function for that.