A looping set of scripts to allow many ... repos to play along nicely.
This should go high up in the
~/.../conf, so that its dot-files take
precedence over the other repos (but, don't worry - the others will still get
sourced. In fact, that's the whole point of boot-dots!)
By convention, repos that are designed to be used after boot-dots are all
[Note: Throughout this document, we refer to the files as being in
but actually it's configurable, becoming
The easiest way to understand how to make your own setup is to mimic http://github.com/ouicode/rkingy-dots-conf
Note that the system is still in flux, and we already have plans on how to make it better. Still, if you copy what is done there, it should continue to work as we revise our process.
There are some ... tools that help
with both scripting and interactive shelling. They are all named
...<something>, so you can tab-complete to see what is available.
These tools are, from the vantage point of
..., all "opt-in" - unless you
~/.../lib/___, they stay out of your way. But, when you're using
boot-dots, you're definitely opted-in (that is, both
Let's look at a few of the functions:
...repos) - cd to the
~/.../srcdirectory for working with the
*-dotsrepos. You can give it an arg that is the name of the repo (and you can even omit the
cdto each repo then eval the given string. It's functional programming for dotfiles! Can I get a w00t-w00t?
- Tracing - There are several handy functions that echo either invariably or
...traceonhas been called. Especially useful are
...traceq) in debugging init processes. The rest are in
...source- Same as the
sourcebuiltin but with trace-awareness.
...source, but only if the file exists. Beware that this can quietly skip over missing parts, so you might have to
...trace*to figure out what's going on, sometimes.
...sourcedircontents- Source all files in the given dir.
~/.../lib/basics ends up making these vars available:
$DOTDOTDOT_ROOT- usually is
$DOTDOTDOT_ORDER- a list of the repos in accordance with
.../confsequence. Remember that, since the lower files in the list are sourced later, their specific parts can override the previous files.
$SHELLNAME- The shortname of a shell, so
bash. Traditionally you have to check
$ZSH_VERSIONin your scripts, but this gives you a handier token.
In zsh, the init sequence is kind of interesting. For the full story try: xterm -e 'man zsh | less -p STARTUP/SHUTDOWN' (And also: the Zsh Startup Files Intro.)
Here is a cheat-sheet:
zsh -l zsh -i zsh -c zsh -f (login shell) (interactive shell) (scripting) (no-rcs) ↓ ↓ ↓ .zshenv .zshenv .zshenv ↓ ↓ .zprofile .zshrc ↓ .zshrc ↓ .zlogin
Now, boot-dots makes this system even more "interesting" by checking for the above files in all -dots repos, plus adding the ~/.zsh dir to facilitate organization (and nice, atomic names).
The following dirs correspond to the above files: ~/.zsh/env/ ~/.zsh/rc/ ~/.zsh/profile/ ~/.zsh/login/
So you can create my-dots/.zsh/rc/my-aptly-named-thing and trust that it gets
sourced as part of boot-dots/.zshrc. If you need something to happen early or
late relative to the others, you can always prefix with
Additionally, there is a .sh/ dir that is similar to .zsh/rc, but is for things that would work in both bash and zsh (which is most things, so it's good to try for that).
... itself comes with some tracing tools to sourt this out, a bit. Look in
~/.../lib/tracefuncs (which is avilable by default if you are using the
boot-dots repo) for the
rking doesn't really care about Bash, so he hasn't set this up in its entirety.
Once you get on board with
boot-dots, you can much more easily work with
other programmers' favorite configs. This is the main reason behind this
system, in fact.
The goal is to make it so you can toss in a buddy's dotfiles repo into your
list, then run
... install -s and (hopefully) away you go!
To pop his stuff back out, run
... remove, take his entry out, then do
install -s again. ¡Muy caliente!
Then, the next level is spinning up VMs using your config.
Check out: http://github.com/PairUp/pairup#readme