"dotfiles" and system configuration
These dotfiles are affectionately dedicated to the vi editor originally created by Bill Joy, with whom I have spent many pleasant evenings1
— Greg Hurrell, paraphrasing Donald Knuth
- Target platforms: macOS and Linux (see Platform status below).
- Set-up method:
Beautiful and intricate snowflakean incredibly over-engineered custom configuration framework called Fig.
- Visible in the screenshot:
- Sane Vim pasting via bracketed paste mode.
- Write access to local clipboard from local and remote hosts, inside and outside of tmux (via Clipper).
- Full mouse support (pane/split resizing, scrolling, text selection) in Vim and tmux.
- Focus/lost events for Vim inside tmux.
- Cursor shape toggles on entering Vim.
- Italics in the terminal.
- Bundles a (not-excessive) number of useful Vim plug-ins.
- Conservative Vim configuration (very few overrides of core functionality; most changes are unobtrusive enhancements; some additional functionality exposed via
- Relatively restrained Zsh config, Bash-like but with a few Zsh perks, such as right-side prompt, auto-cd hooks, command elapsed time printing and such.
- Unified color-handling (across iTerm2 and Vim) via Base16 Shell.
- Encrypted versioning of files with sensitive content (via git-cipher).
- Comprehensive Hammerspoon config.
- Make Caps Lock serve as Backspace (when tapped) and Left Control (when chorded with another key). When held down alone, Caps Lock fires repeated Backspace events.
- Make Return serve as Return (when tapped) and Right Control (when chorded with another key). When held down alone, Return fires repeated Return events.
- Toggle Caps Lock on by tapping both Shift keys simultaneously.
- Makes the function keys on my external Realforce keyboard behave like the "media" keys on Apple's keyboards.
And these only on macOS:
- Swap Option and Command keys on my external Realforce keyboard.
- Make the "application" key (extra modifier key on right-hand side) behave as "fn" on Realforce keyboard.
- Map Control-I to F6 (only in the terminal) so that it can be mapped independently from Tab in Vim3.
- Make "pause" (at far-right of function key row) behave as "power" (effectively, sleep) on Realforce keyboard.
- Adds a "SpaceFN" layer that can be activated by holding down Space while hitting other keys; I use this to make the cursor keys available on or near the home row in any app.
ag: Transparently wraps the
agexecutable so as to provide a centralized place to set defaults for that command (seeing as it has no "rc" file).
bounce: bounce the macOS Dock icon if the terminal is not in the foreground.
color: change terminal and Vim color scheme.
fd: "find directory" using fast
cds into the selected directory.
fh: "find [in] history"; selecting a history item inserts it into the command line but does not execute it.
history: overrides the (tiny) default history count.
j): to jump to hashed directories.
regmv: bulk-rename files (eg.
regmv '/\.tif$/.tiff/' *).
scratch: create a random temporary scratch directory and
tick: moves an existing time warp (eg.
tick +1h); see
twbelow for a description of time warp.
tmux: wrapper that reattches to pre-existing sessions, or creates new ones based on the current directory name; additionally, looks for a
.tmuxfile to set up windows and panes (note that the first time a given
.tmuxfile is encountered the wrapper asks the user whether to trust or skip it).
tw("time warp"): overrides
Zsh is configured with the following prompt:
Visible here are:
- Concise left-hand prompt consisting of:
- Last component of current directory (abbreviates
- Prompt marker,
❯, the "HEAVY RIGHT-POINTING ANGLE QUOTATION MARK ORNAMENT" (that's
e2 9d afin UTF-8).
- Last component of current directory (abbreviates
- Extended right-hand size prompt which auto-hides when necessary to make room for long commands and contains:
- Duration of previous command in adaptive units (seconds, minutes, hours, days, depending on duration).
- Current version control branch name.
- Current version control worktree status using colors that match those used in
- Green dot indicates staged changes.
- Red dot indicates unstaged changes.
- Blue dot indicates untracked files.
- Full version of current working directory (again, abbreviating
Nested shells are indicated with additional prompt characters. For example, one nested shell:
Two nested shells:
Root shells are indicated with a different color prompt character and the word "root":
Nesting within a root shell is indicated like this:
Two nested shells:
If the last command exited with a non-zero status (usually indicative of an error), a yellow exclamation is shown:
If there are background processes, a yellow asterisk is shown:
- tmux 3.2 or later.
- Neovim v0.5.0 or later.
- Relatively recent Zsh.
- Relatively recent Git.
- Clipper for transparent access to the local system clipboard.
- On macOS, iTerm2 or Kitty. Additionally, only the latest version of macOS (at the time of writing, Monterey) gets actively tested.
- Adobe Source Code Pro or any other fixed-width font that includes the Powerline glyphs.
|Red Hat Linux and related (eg. CentOS)|
Development occurs on the
main branch, but to avoid inconvenience for people who previously cloned the repo when the
master branch was the main line, the legacy branch is kept up-to-date via a pre-push hook (which updates the local branch) and a post-receive hook (which updates the remote).
git clone --recursive https://github.com/wincent/wincent.git
sudo pacman -Syu sudo pacman -S git ruby tmux vim git clone --recursive https://github.com/wincent/wincent.git
git: In order to clone the repo.
ruby: So that git-cipher can run (also used to build Command-T).
tmux: Just for comfort (eg. so you can see scrollback).
vim: Because the
nvimaspect needs Vim (it runs
vimto do a
⚠️WARNING: There are lots of different things that can be installed or configured (see the
aspects/directory). Unless you want your machine to be exactly like mine — which is unlikely — you probably don't want to install everything. Maybe you don't even want everything in the "dotfiles" and "nvim" aspects. Please inspect the contents of each aspect before proceeding to install it; you may even be better off just looking at the configuration files and stealing the bits that you find interesting or useful (everything is in the public domain, unless otherwise indicated).
At the time of writing, these are the aspects, which you can expect to change over time (see the
aspects/ directory for an up-to-date listing):
- On macOS only:
- automator: Scripts for use with Automator
- automount: Sets up macOS's automount facility
- backup: Backup scripts
- cron: Sets up cron files
- defaults: Sets up defaults (ie. preferences) on macOS
- fonts: Installs Source Code Pro font files
- homebrew: Installs and updates Homebrew
- iterm: Dynamic profiles for iTerm
- karabiner: Configures Karabiner-Elements (keyboard customization).
- launchd: Configures launchd
- node: Installs Node.js
- ruby: Installs Ruby gems
- ssh: Manages local SSH config
- tampermonkey: Sets up UserScripts
- On Linux only:
- apt: Installs packages using
- aur: Installs packages from the Arch User Repository.
- avahi: Manages the Avahi zeroconf ("Bonjour") networking daemon.
- codespaces: Custom tweaks for GitHub Codespaces environments.
- interception: Sets up Interceptions Tools (keyboard customization).
- locale: Sets up /etc/locale.conf
- pacman: Installs packages via the Pacman package manager
- sshd: Manages sshd.
- systemd: Set up services that run from systemd
- apt: Installs packages using
- On both macOS and Linux:
- dotfiles: Creates symlinks in $HOME to the dotfiles in this repo
- meta: Tests the configuration framework
- shell: Sets the use shell to zsh
- terminfo: Sets up terminfo database entries for italics and 256-color support
- nvim: Configures Neovim and Vim
./install dotfiles nvim # Just install "dotfiles" and "nvim" stuff. ./install dotfiles # Just install "dotfiles". ./install dotfiles --step # Prompt for confirmation at each step. ./install dotfiles --check # Do a dry-run, showing what would be changed. ./install # Install everything. ./install ^homebrew # Install everything except for the "homebrew" aspect. ./install --help # Lists all aspects, descriptions, options.
Note: Given that
~/.gitconfig is included with these dotfiles, any local modifications or overrides that you apply should be added to
~/.gitconfig.local instead; for example:
git config --file ~/.gitconfig.local user.name "John Doe" git config --file ~/.gitconfig.local user.email email@example.com
As much as I would love this thing to be entirely automated, there are some manual steps that must typically be performed.
- In iTerm, mark the "Wincent" dynamic profile as the default: Preferences → Profiles → Other actions... → Set as Default
- Set up full-disk access for iTerm: As described here, System Preferences → Security & Privacy → Privacy → Full Disk Access (and make sure that iTerm.app is in the list with the checkbox checked).
There are a few useful
# Run in "check" (dry-run) mode. ./install --check # Show debugging information during the run. ./install --debug # Confirm each task before running it (--step), and begin # execution from a specific task (--start-at-task) in a # specific aspect ("dotfiles"). ./install --step --start='make directories' dotfiles
Unless otherwise noted, the contents of this repo are in the public domain. See the LICENSE for details.
The repo is written and maintained by Greg Hurrell <firstname.lastname@example.org>. Other contributors that have submitted patches include, in alphabetical order:
- Anton Kastritskiy
- Hashem A. Damrah
- Joe Lencioni
- Jonathan Wilkins
- Keng Kiat Lim
- Mark Stenglein
- Matthew Byrne
- Michael Lohmann
- Stone C. Lasley
- Victor Igor
- Zac Collier
This list produced with:
:read !git shortlog -s HEAD | grep -v 'Greg Hurrell' | cut -f 2-3 | sed -e 's/^/- /'
As of commit ec49be762ff3 ("feat(dotfiles): automatically sign commits on personal machines", 2022-06-19) and commit 97143b5d7635 ("feat(dotfiles): sign commits everywhere except codespaces", 2022-06-20), I started signing most commits in this and other repos with GPG keys corresponding to my work and personal email addresses.
GitHub will label such commits with a "Verified" badge. In order to see signature information using the
git commandline executable, you would run commands such as
git show --show-signature and
git log --show-signature. Note that in order to be able to actually verify these signatures you need a copy of the corresponding public keys, otherwise Git will show:
gpg: Signature made Mon 11 Jul 2022 11:50:35 CEST gpg: using RSA key B0C9C204D656540BDCDA86229F6B84B5B1E9955E gpg: issuer "email@example.com" gpg: Can't check signature: No public key
You can obtain the public keys with the following:
# Either, download directly given the key fingerprint as shown by Git: gpg --keyserver pgp.mit.edu --recv-key C7C225A18975180C4485A1E070516DBB88E4F779 gpg --keyserver pgp.mit.edu --recv-key B0C9C204D656540BDCDA86229F6B84B5B1E9955E # Or, chose from a list of possible matches returned by searching for an email address: gpg --keyserver https://pgp.mit.edu/ --search-keys firstname.lastname@example.org gpg --keyserver https://pgp.mit.edu/ --search-keys email@example.com
You can also grab the keys from GitHub, if you trust GitHub:
curl https://github.com/wincent.gpg | gpg --import
Once you have those, Git will instead show:
gpg: Signature made Mon 11 Jul 2022 12:28:32 CEST gpg: using RSA key B0C9C204D656540BDCDA86229F6B84B5B1E9955E gpg: issuer "firstname.lastname@example.org" gpg: Good signature from "Greg Hurrell <email@example.com>" [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 2F44 69E0 C1FA 72AA C0A5 60C9 6210 6B56 923F 3481 Subkey fingerprint: B0C9 C204 D656 540B DCDA 8622 9F6B 84B5 B1E9 955E
What's going on here, cryptographically speaking?
- GPG keys consist of public and private parts, often referred to as public keys and private keys (together, a "key pair"). As the names suggest, the owner of key must keep the private part secret, but the public part can be freely shared.
- Roughly speaking, "signing" something means using the private key to encrypt a hash of the contents of the document that is being signed (in this case, the "document" is a commit).
- The public key can be used to decrypt the hash, which can then be compared against the contents to confirm that they match. This is what is happening when we see
gpg: Good signatureabove; it means that the public key for
Greg Hurrell <firstname.lastname@example.org>verifies that the signature was indeed created with the corresponding private key belonging to that address.
- Because only the owner has access to the private key, only the owner can make signatures with it; but conversely, because everybody has access to the public key, anybody can verify those signatures.
- GPG keys have two additional concepts: "subkeys" are keys associated with a primary key; and "usages" describe what role those keys each play (eg. "signing", "encryption").
- In practice, the primary key is always a "signing" key, and GPG will create one "encryption" subkey by default. Users can add/remove additional subkeys and assign them usages.
- I create "signing" subkeys for making signatures and I rotate them once per year (I keep my primary key "offline" so that it can't be hacked if my machine is compromised).
So those are the cryptographic primitives. The signature is "Good" in the cryptographic sense, but why the scary "WARNING"? It's because there's a whole other layer on top of this called the "web of trust". A good signature gives us the mathematical certainty that a particular private key was used to produce a given signature, but that tells us nothing about the human world that exists above and around that crypto. That is, the key was used to make the signature, but was it me who used the key? Am I really the handsome Australian man living in Madrid claiming to be Greg Hurrell, or am I in fact part of a clandestine criminal organization operating from a satellite-connected submarine in the Arctic sea?
The web of trust serves to link your human-level trust relationships to the underlying digital entities. By running
gpg --edit-key $KEY and hitting
trust, you can explicitly record your level of trust in any given key, and you can do things like going to "key signing parties" and such where you can physically meet people, verify their identity by whatever means you deem appropriate, and then sign one another's public keys. The accrued effect of these actions over time is to establish a web of connections where trust is transitively applied: if you trust
B, then you in turn can also trust
B. Having said all that, how to actually go about building a useful web of trust is beyond the scope of this README, and in all my long years on the internet, I've never once gone to a key signing event or otherwise engaged in activity that would help me integrate my keys into a useful web of trust.