These are brian m. carlson’s dotfiles. Things that may interest you include the configuration files for Vim and Neovim, zsh, and tmux.
GNU Make, Git, a Debian-compatible sh[1], and standard POSIX utilities are required.
Ruby is strongly recommended and a small number of tools require Perl.
If Ruby is installed, some dotfiles can be generated using ERB based on a file called config.yaml.
Examples are in the config directory.
The Makefile is extensible to allow installation of a set of private dotfiles as well by symlinking a separate repository’s rules-overlay.mk into the root of this directory.
This is a good way to include configuration or scripts which may be sensitive or expose internal company information.
For instance, a set of private dotfiles with additional snippets might contain this rules-overlay.mk:
OVERLAY := $(shell perl -MCwd -e '$$d=Cwd::abs_path($$ARGV[0]);$$d=~s!/[^/]+$$!!;print $$d' rules-overlay.mk)
include $(OVERLAY)/snippets/rules.mk
$(OVERLAY)/manifest.mtree: $(OVERLAY_MTREE_SOURCES)
perl -p -e 's/^(?:#|(.*[^\\])#).*$$/$$1/; next if /^\s*$$/; if (m!^(.*)\ssrc=([^ ]+)(\s+.*)?$$!) { $$_ = "$$1 src=$(OVERLAY)/$$2$$3\n"; }' $^ > $@
MTREE_SOURCES += $(OVERLAY)/manifest.mtreeThe Perl script causes OVERLAY to be set to the canonical path of the private dotfiles directory.
Simply clone the dotfiles to a particular location and type make install.
If you wish to install them other than in HOME, set DESTDIR: DESTDIR=/tmp/homedir make install.
The installation is configured by the use of mtree(1)-like files in each directory which can control the permissions and destination of each file.
This is done by bin/dct-mtree.
There are several Ansible playbooks in the playbooks directory that cover bootstrapping a new environment.
First, if root privileges are obtainable, the bootstrap.yaml playbook can be used to bootstrap a new system:
$ ansible-playbook bootstrap.yaml
-e graphical=true can be used to bootstrap a graphical environment on Debian or Ubuntu.
-e development=true can be used to bootstrap a development environment on Debian or Ubuntu.
Second, if a user account needs to be created, such as in a container, the create-account.yaml playbook can be used to create a new account with sudo access:
$ ansible-playbook create-account.yaml
-e user=bk2204 sets a different account name, and -e sudo_with_password=true disables passwordless sudo.
Then, dotfiles can be deployed.
Note that this must be done without privileges unless root is to have the dotfiles.
The easiest and most robust way to do this is to use sudo -u if on localhost.
$ ansible-playbook deploy-dotfiles.yaml
A different branch can be specified with something like -e branch=work and a different checkouts directory with -e checkouts_dir=/workspaces.
By default, a group with the same name as the user is used.
If this is not correct, use -e group=users to correct it.
Note that in all cases, operating on localhost should use --connection=local -i localhost,.
These playbooks have been tested on Debian, Ubuntu, and FreeBSD.
These dotfiles have a variety of tests available in RSpec form.
Most of them can be run simply by invoking rspec.
The tests for the Ansible playbooks operate inside a Docker container to avoid contaminating the system.
They can be run by setting DOCKER_IMAGE to standard Docker image location.
Most files are under the MIT License, but some come from other sources.
There is a Debian machine-readable copyright file in LICENSE that contains copyright and license information.
/bin/sh support POSIX.1-2017, plus some additional features, notably local. Most POSIX-compatible shells on Linux, macOS, and the BSDs comply, with the notable exception of AT&T ksh. (mksh and pdksh derivatives do, however, conform.) See the Debian Policy requirements for more details.