joshrandall's dotfiles

Warning

These dotfiles are not directly developed for complete public use. They are designed for newly created users on a Linux system. If you decide to install this on an already established user, you install them at your own risk.

My personal dotfiles for Linux/KDE Plasma and Windows. Meant for bootstraping systems to my configuration quickly.

This repository uses chezmoi templates and conditionals (see .chezmoiignore and the .tmpl files) to keep one source of truth across platforms and machine roles:

• Linux/KDE-only configuration (shell, KDE, kitty, fish, etc.) is skipped when applying on Windows, based on {{ .chezmoi.os }}.
• Windows-only configuration (PowerShell profile, Spicetify under AppData) is skipped when applying on Linux/macOS.
• Shared configuration (nushell, Spicetify theme assets) is templated once and rendered per-OS from .chezmoitemplates.
• On root ({{ .chezmoi.username }}) or any machine with jrh in its hostname ({{ .chezmoi.hostname }}), only shell configuration and starship apply — KDE Plasma configuration and wallpapers are skipped, and .bashrc/.zshrc/nushell render a leaner variant (no conda/bun/fnm/spicetify-PATH, no desktop-only aliases).
• On jrh/jrp-hostname machines, every shell (.bashrc, .zshrc, fish, nushell) exports TERM=xterm-256color so colors render correctly over SSH regardless of which shell is the login shell. This applies even when the user is root, whose branch otherwise takes precedence.

Working with templated files

Everything not listed below behaves exactly as it always has (chezmoi add, chezmoi apply, chezmoi update, chezmoi diff, chezmoi edit, no changes to habits).

The exception is the files that are now templates: nushell's config.nu/env.nu, the Spicetify config-xpui.inis, and .bashrc/.zshrc. Don't run a bare chezmoi add on these again — add overwrites the source with a flattened copy of whatever's on disk, which destroys the {{ if ... }} conditionals (and, for nushell/Spicetify, the {{ template ... }} include) and turns it back into a plain static file.

To edit those specifically:

• shared nushell logic → .chezmoitemplates/nushell_config.nu.tmpl / nushell_env.nu.tmpl (the per-OS .tmpl files under dot_config//AppData/ are just one-line includes of these)
• shared Spicetify config-xpui.ini logic → .chezmoitemplates/spicetify_config-xpui.ini.tmpl
• Neovim → edit dot_config/nvim/ directly. On Windows the same files are rendered into %LOCALAPPDATA%\nvim through one-line include stubs under AppData/Local/nvim/; when you add a new file to dot_config/nvim/, add a matching AppData/Local/nvim/<path>.tmpl containing {{- include "dot_config/nvim/<path>" -}}
• .bashrc/.zshrc → edit dot_bashrc.tmpl/dot_zshrc.tmpl directly; each branches inline on root/jrh-hostname/desktop since they only ever target one path (no shared partial needed)

Then just chezmoi apply as usual, no special command needed to re-render. chezmoi edit also still works, just remember you're opening a template, not raw config. If a template ever does get flattened by an accidental add, git checkout the .tmpl file back from the repo and reapply — nothing destructive happens to the actual target files on disk either way.

Dependencies

This is a rough list of dependencies an applications used in the configuration:

DE + Applications

• KDE Plasma 6 (Linux)
• kitty (Linux)
• Visual Studio Code

Deps + Programs

• git
• chezmoi
• zsh (Linux)
• nushell
• fastfetch
• eza, ls replacement (Linux)
• starship
• fish (Linux, optional) — see below
• nix (Linux, optional) — only needed for the dev-init profile
• direnv (optional) — hooked into fish, zsh and bash when installed

fish, zsh, bash and the dev-init nix profile

The fish config checks for its tools at runtime instead of assuming them, so it applies cleanly on a machine that is missing some of them:

• the ls/ll/la/lt/lg helpers are only defined when eza is installed, so ls otherwise falls back to fish's own
• the fastfetch greeting and starship init are each skipped when that binary isn't on PATH

.config/fish/conf.d/dev-init.fish picks up a nix profile named dev-init when one exists, and does nothing at all when it doesn't. It looks in $DEV_INIT_PROFILE, $XDG_STATE_HOME/nix/profiles, ~/.local/state/nix/profiles, ~/.local/share/nix/profiles, /nix/var/nix/profiles/per-user/$USER and /nix/var/nix/profiles, taking the first that actually has a bin/. From that profile it puts bin on PATH, adds share/man to MANPATH, wires up the share/fish/vendor_* directories that NixOS would normally handle itself, and exports DEV_INIT_PROFILE. Since conf.d is read before config.fish, tools that come from the profile (eza, starship, …) satisfy the checks above. If a dev-init binary ends up on PATH it also gets a di shorthand, skipped when something else already owns that name.

The same detection is shared by zsh and bash through the shell_dev-init.sh.tmpl chezmoi template, appended to .zshrc and .bashrc: same candidate list and same bin/ check, exporting DEV_INIT_PROFILE, prepending bin to PATH (only when it isn't already there) and adding share/man to MANPATH. For completions zsh gets share/zsh/site-functions prepended to fpath followed by a single compinit re-run (oh-my-zsh has already run it by that point), and bash gets BASH_COMPLETION_USER_DIR pointed at the profile's share/bash-completion unless it is already set. The di shorthand is an alias there, defined only when dev-init is on PATH and nothing else owns the name.

Both shells also get the direnv hook (eval "$(direnv hook zsh|bash)"), and only when a direnv binary is actually on PATH — including one that came from the dev-init profile, since the profile block runs first.

The zsh and bash configs apply the same runtime checks to the rest of their tools, so a machine that is missing one doesn't error on every new shell: starship init, the fastfetch greeting (with its smallfetch/archbtw aliases), the eza-backed ls alias and fnm env are each skipped when that binary isn't installed, and ls falls back to the real one.

Windows-specific

• nushell and/or PowerShell
• starship installed to C:\Program Files\starship\bin\starship.exe
• Spicetify (theme/marketplace assets applied to %APPDATA%\spicetify)
• Neovim (config applied to %LOCALAPPDATA%\nvim)

Install

The dotfiles can easily be installed using chezmoi. Once all dependencies are installed, there are a few ways to apply the configuration.

1. Quick init

Caution

Please only use this method on a new linux user. Initializing the entire configuration may/will overwrite existing user settings with no way to undo without backups.

The fastest way to get the configuration live with minimal setup.

# Initialize chezmoi to the dotfiles repository, and apply the configuration immediately.
chezmoi init --apply joshrandall8478

# Install the papirus icon pack to /usr/share/icons, and the poppins font to /usr/share/fonts
~/scripts/install-papirus-root.sh
~/scripts/install-poppins-root.sh

Installing the two assets to root will help with SDDM configuration, if you wish to use the breeze theme.

Note

The two root font/icon install scripts can be safely ran regardless of whichever install approach you take. To remove them, check their respective /usr/share folders. Uninstall scripts WIP.

Quick init - chezmoi only

This will only initialize and install the chezmoi configuration:

chezmoi init --apply joshrandall8478

This is if you want to avoid installing the icon/fonts to root. The fonts are already packaged with the chezmoi configuration. To install the icons to KDE plasma only, run this command:

~/scripts/install-papirus-kde.sh

2. Init and modify

The safest way to apply the configuration is to initialize without applying, then either applying the entire config in the next step, or picking which parts to apply.

chezmoi init joshrandall8478
chezmoi apply

or

# Apply only ~/.zshrc
chezmoi apply ~/.zshrc

Windows

The same repository can be applied on Windows; .chezmoiignore automatically skips the Linux/KDE-only files and only applies the Windows-specific ones (nushell, PowerShell profile, Spicetify, Neovim).

chezmoi init --apply joshrandall8478

Visual Studio Code

VS code comes with an extension list, and user settings to mimic close to what I use. To install the extensions, run the install-vscode-extensions.sh script:

~/scripts/install-vscode-extensions.sh