I’m embarking on a long, long over due project to organize my dotfiles, you know, all those files in your home directory that start with “.” and configure your software. (If you don’t then this isn’t the post or the blog for you.)
There are lots of schemes for storing and distributing dotfiles, and I’ll get to that. But first, I need to clean up the mess of living in the UNIX shell for 30 years. Really.
My goals are twofold: 1) Any time I spin up a new server, I want to be able to deploy my preferred configuration out to it. 2) I want a complete copy of my local machine’s config setting to make it (relatively) simple to setup on a new machine.
These goals conflict. There are things on my local machine I don’t want on servers, aliases that don’t make sense, secrets like API keys, configuration for desktop apps (you’d be surprised how many use dotfiles). The simple solution would be to create two sets of files, but that has the downside over time of needing to maintain two sets of files.
So, as a first pass, I’m going to try to create a smart setup that recognize local vs server.
The classic method is to us
uname -s which returns the system
name. I’m on a Mac, so I’m looking for Darwin.
1 2 3 4 5
Another option would be to use BASH’s $OSTYPE, which is automatically
set. However, there’s a fair amount of variation in the value. For
example OS X charges it with every release (darwin15 == El Capitan,
darwin14 == Yosemite) so you need a wildcard match.
uname -s output
is far more consistent.
Now we have a nice automated method, however I’m not going to use it. Basing this logic on my OS falls apart if I ever login to a remote OS X box (it could happen) or switch my computer to Linux (been there, done that.) Nope, there is only one “my computer” and this calls for hardcoding.
Now I could just toss
export LOCAL=1 in my .bashrc and call it
done, but then I have two .bashrc to maintain. Let’s do this in a
1 2 3
then .local-settings the contains:
Now, instead of a hardcoded hack, I have a per computer way to set configuration. In a future post we’ll put this to use.