dotfiles
rice 🍚 custom linux config files. as seen on r/unixporn #noricenolife neovim cultist. dotfiles are perpetual wip
Quick Overview
The xero/dotfiles repository is a collection of configuration files and scripts for setting up a development environment on various operating systems. It includes configurations for popular tools and applications such as Vim, Git, Zsh, and more.
Pros
- Comprehensive Configuration: The repository provides a wide range of configuration files for various tools and applications, making it easier to set up a development environment.
- Cross-Platform Compatibility: The dotfiles are designed to work across different operating systems, including macOS, Linux, and Windows.
- Customizable: Users can easily customize the configurations to suit their individual preferences and needs.
- Active Development: The project is actively maintained, with regular updates and improvements.
Cons
- Learning Curve: Setting up the dotfiles may require some initial effort and understanding of the various tools and configurations.
- Potential Conflicts: Integrating the dotfiles with an existing development environment may lead to conflicts with other configurations or settings.
- Dependency on External Tools: The dotfiles rely on several external tools and applications, which may need to be installed separately.
- Limited Documentation: While the repository provides some documentation, it may not cover all the details or edge cases that users might encounter.
Getting Started
To get started with the xero/dotfiles repository, follow these steps:
- Clone the repository to your local machine:
git clone https://github.com/xero/dotfiles.git
- Navigate to the cloned repository:
cd dotfiles
- Run the installation script:
./install.sh
This script will symlink the configuration files to the appropriate locations on your system.
- Customize the configurations as needed:
The repository includes various configuration files for different tools and applications. You can modify these files to suit your preferences and needs.
- Enjoy your new development environment!
Competitor Comparisons
@holman does dotfiles
Pros of holman/dotfiles
- More comprehensive and well-organized structure with topic-specific directories
- Includes a bootstrap script for easy installation and setup
- Larger community and more frequent updates
Cons of holman/dotfiles
- More complex and potentially overwhelming for beginners
- Less focus on minimalism and customization compared to xero/dotfiles
- May include unnecessary components for some users
Code Comparison
dotfiles:
# xero/dotfiles
alias ls='ls --color=auto'
alias ll='ls -la'
# holman/dotfiles
alias l="ls -lAh"
alias la="ls -AF"
alias ll="ls -lFh"
Both repositories provide customized aliases for common commands, but holman/dotfiles offers more granular options for listing files and directories.
Summary
holman/dotfiles is a more comprehensive and well-maintained repository with a larger community, making it suitable for users who want a robust, ready-to-use configuration. However, it may be overwhelming for beginners or those seeking a minimalist setup. xero/dotfiles, on the other hand, offers a more streamlined and customizable approach, which might appeal to users who prefer a simpler configuration or want to build their dotfiles from scratch.
My dotfiles (deployed by LARBS)
Pros of voidrice
- More comprehensive configuration, covering a wider range of tools and applications
- Regularly updated with frequent commits, ensuring compatibility with latest software versions
- Includes custom scripts and utilities for enhanced functionality
Cons of voidrice
- More complex setup and potentially overwhelming for beginners
- Heavily opinionated configurations may require significant customization for personal preferences
- Larger repository size due to extensive configurations and additional scripts
Code Comparison
voidrice (config.def.h):
static const char *colors[][3] = {
/* fg bg border */
[SchemeNorm] = { col_gray3, col_gray1, col_gray2 },
[SchemeSel] = { col_gray4, col_cyan, col_cyan },
};
dotfiles (.Xresources):
*.foreground: #d8dee9
*.background: #2e3440
*.cursorColor: #d8dee9
*fading: 35
*fadeColor: #4c566a
Summary
Both voidrice and dotfiles offer extensive configuration options for Unix-like systems. voidrice provides a more comprehensive set of configurations and custom scripts, making it suitable for users who want a fully-featured setup out of the box. However, it may be more complex to set up and customize. dotfiles, on the other hand, offers a simpler and more minimalistic approach, which might be preferable for users who want a basic starting point for their own customizations.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
ââ ââ ââââ ââ ââ
âââ âââ ââââ ââ âââ
âââ ââââââ ââââââ ââââââ ââ âââ âââââ ââââââ
ââââââ ââââââââââââââ ââââââ âââ âââ âââââââ ââââââ
ââââââââââ âââ âââ âââ âââ ââââââââââââââââââ
âââ ââââââ âââ âââ âââ âââ ââââââââââ âââââââ
ââââââââââââââââ ââââ âââ âââ âââââââââââ ââââââ
ââââââ ââââââ ââ ââ ââ âââ ââââââ ââââââ
ââââââââââ
ââ about â custom linux config files
ââ author â xero <x@xero.style>
ââ code â http://code.x-e.ro/dotfiles
ââ mirror â https://git.io/.files
âââââââââââ
ââââââââââ
NOTE: if you are looking for my linux wm configs like 2bwm, windowchef, etc. they now live in the classic branch and are not actively maintained since i live in the tty, xorg free, these days.
table of contents
- introduction
- managing
- installing
- how it works
- tl;dr
- terminal emulator
- vps & local clipboard
- shell
- clean home
- neovim
- license
dotfiles
in the unix world programs are commonly configured in two different ways, via shell arguments or text based configuration files. programs with many options like text editors are configured on a per-user basis with files in your home directory ~
. in unix like operating systems any file or directory name that starts with a period or full stop character is considered hidden, and in a default view will not be displayed. thus the name dotfiles.
it's been said of every console user:
"you are your dotfiles".
since they dictate how your system will look and function. to many users (see ricers and beaners) these files are very important, and need to be backed up and shared. people who create custom themes have the added challenge of managing multiple versions of them. i have tried many organization techniques. and just take my word for it when i say, keeping a git repo in the root of your home directory is a bad idea. i've written custom shell scripts for moving or symlinking files into place. there are even a few dotfile managers, but they all seem to have lots of dependencies. i knew there had to be a simple tool to help me.
managing
i manage mine with gnu stow, a free, portable, lightweight symlink farm manager. this allows me to keep a versioned directory of all my config files that are virtually linked into place via a single command. this makes sharing these files among many users (root) and computers super simple. and does not clutter your home directory with version control files.
installing
stow is available for all linux and most other unix like distributions via your package manager.
apt install stow
brew install stow
dnf install stow
pacman -S stow
yum install stow
or clone it from source and build it yourself.
how it works
by default the stow command will create symlinks for files in the parent directory of where you execute the command. since i keep my dots in: ~/.local/src/dotfiles
and all stow commands should be executed in that directory and suffixed with -t ~
to target the home directory. otherwise they will end up in ~/.local/
. if you wanna make things easier on yourself you can clone the repo to ~/dotfiles
then run commands with no flags. but who likes things easy in the unix world ;P
to install configs execute the stow command with the folder name as the first argument, then target your home directory (or wherever you like).
to install my zsh configs use the command:
stow zsh -t ~
this will symlink files like .zshrc
to ~/.config/zsh
to install the fun scripts to /usr/local/bin
execute the command:
stow fun -t /usr/local/
this will symlink the fun scripts like food
to /usr/local/bin
. notice that the location of the scripts has appended a bin folder? that's b/c stow creates or uses the exact folder structure of the repo. and the food script is located at /fun/bin/food
in this repo.
note: stow can only create a symlink if a config file does not already exist. if a default file was created upon program installation you must delete it first before you can install a new one with stow. this does not apply to directories, only files.
more notes on using/understanding stow in this github issue.
my dotfiles setup
to fully "install" and setup this repo run the setup script or something like this:
# clone and stow
git clone git@github.com:xero/dotfiles.git ~/.local/src/dotfiles &&
cd ~/.local/src/dotfiles &&
stow bin fun git gpg ssh tmux neovim zsh -t ~
# tmux
mkdir ~/.config/tmux/plugins &&
git clone --depth=1 https://github.com/tmux-plugins/tpm ~/.config/tmux/plugins/tpm &&
~/.config/tmux/plugins/tpm/scripts/install_plugins.sh &&
cd ~/.config/tmux/plugins/tmux-thumbs &&
expect -c "spawn ./tmux-thumbs-install.sh; send \"\r2\r\"; expect complete" 1>/dev/null
# nvim
mkdir ~/.local/nvim &&
git clone --filter=blob:none --single-branch https://github.com/folke/lazy.nvim.git ~/.local/share/nvim/lazy
nvim --headless "+Lazy! sync" +qa
nvim --headless "+MasonUpdate" +qa
# creating ~src and ~dotfiles aliases"
sudo useradd -g src -d ~/.local/src src
sudo useradd -d ~/.local/src/dotfiles dotfiles
tl;dr
navigate to your home directory
cd ~
clone the repo:
git clone git@github.com:xero/dotfiles.git
enter the dotfiles directory
cd dotfiles
install the zsh settings
stow zsh
install zsh settings for the root user
sudo stow zsh -t /root
uninstall zsh
stow -D zsh
etc, etc, etc...
terminal emulator
recently i've been using an 11" m1 ipad pro and a bluetooth 68% mechanical keyboard, usually on my lap, as my main computer. i use the community edition of the blink shell connected to a vps.
when it comes to fonts i've been using hack (i use a mod w/ extra icons for extended unicode and emoji support.) it's included in base64 encoded css form, along with color schemes, in the blink
directory.
run blink config
under appearance, set the screen mode set to cover
then setup your server identity and keys. beyond that the only command i ever run in blink is mosh x
. x being my server alias.
vps & local clipboard
idk why, but i chose debian 11 on aws for some reason. there's a setup script for a fresh vps to install all the packages, tools, & services, create my user, setup keys, etc... that i use, my way. but you the reader don't need them all to run my dots, this is for me. beware there be dragons here.
it builds mosh-server from this pr for osc 52 clipboard support.
i use xvfb to create a headless xorg enviroment for the clipboard. you can then use tools like xsel and xclip to pipe {in/out}
of it in the tty. i have a personal fork on clipmenu that uses fzf and a an osc52 yank script to syncromize the x and ipad clipboards. there are other osc52 plugins for neovim and tmux included in these dotfiles to bring the whole thing together.
here's an abbreviated aws ec2 launch template for my arm64 graviton instance:
{
"LaunchTemplateName": "debian11_dev_box",
"LaunchTemplateData": {
"ImageId": "ami-038e5cbebf3138c24",
"InstanceType": "c6g.medium",
"EbsOptimized": true,
"BlockDeviceMappings": [{
"DeviceName": "/dev/xvda",
"Ebs": {
"Encrypted": true,
"Iops": 8000,
"VolumeSize": 80,
"VolumeType": "gp3",
"Throughput": 125
}
}],
"NetworkInterfaces": [{
"SecuityGroups": {
"IpPermissions": [
{ "protocol": "tcp", "port": 0 },
{ "protocol": "tcp", "port": 1723 },
{ "protocol": "tcp", "port": 22 },
{ "protocol": "tcp", "port": 443 },
{ "protocol": "tcp", "port": 60806 },
{ "protocol": "tcp", "port": 80 },
{ "protocol": "udp", "port": 1701 },
{ "protocol": "udp", "port": 4500 },
{ "protocol": "udp", "port": 500 },
{ "protocol": "udp", "port": 61000 }
]
}
}]
}
}
shell
i prefer a minimal setup, and choose to interact with my operating system via the so-called "terminal" or "command line", (read that quoting sarcastically). with the web browser and video player among the noted outliers. in my opinion, using your computer should be a very personal experience. your colors, aliases, key-bindings, etc meticulously crafted to your exacting specifications. so for me, the unix shell is the most important part of my environment.
i use zsh as my interactive shell. it's an extensible, bash like shell with awesome completion and correction engines. i manage multiple shell sessions with tmux. it's a feature packed terminal multiplexer with support for buffers, split windows, detached local and remote sessions, etc. i use neovim and a member of the cult of vi. sing phrases to the third reincarnation of the glorious ed! lel.
clean home
i'm all about living a comfy and clean digital life, so that means a tidy and organized home directory. my ~
and this repo, follow the XDG spec. here's a generalized breakdown:
.
âââ .config/ $XDG_CONFIG_HOME --> app specific configs
â âââ nvim
â âââ tmux
â âââ zsh --> each app has a folder
â â âââ zshrc --> config files
â âââ etc...
âââ .local/
â âââ bin/ $PATH --> my scripts
â âââ cache/ $XDG_CACHE_HOME --> runtime files
â âââ docs/ ~docs --> my documents
â âââ lib/ $pkgManger_HOME --> app libraries
â âââ share/ $XDG_DATA_HOME --> shared app files
â âââ src/
â â âââ dotfiles/ --> this repo
â â âââ other_code/
â âââ state/ $XDG_STATE_HOME --> app state files
â âââ zsh/
â âââ history --> app created files
âââ .ssh/
â âââ authorized_keys
â âââ config
â âââ known_hosts
âââ âââ ââ¬â â âââ
to make this all work, (esp ~/.local/lib
) i have a ton of XDG directives in my zsh environment file. the one tricky bit it getting your zshrc outta home. you need to export the ZDOTDIR globally somewhere like /etc/zsh/zshenv
or /etc/zlogin
that is globally sourced. other options like using systemd discussed here. i suggest running these two commands from my setup script to get things ready:
# create directory skeleton
mkdir -p ~/.local/{bin,docs,cache,lib,share,src,state} ~/.local/state/zsh
# export ZDOTDIR globally
echo 'export ZDOTDIR="$HOME"/.config/zsh' >>/etc/zsh/zshenv
i like to run these before cloning my dotfiles and using stow, to prevent these dirs from being symlinks.
neovim
with it's tight integration to the unix shell, vim has been my editor of choice for years. once you start to grok movements and operators you quickly begin manipulating, not just editing text files. and in the shell, everything is just text ;D these days i'm a full time neovim user. it's just better than normal vim at this point imho. using a community built embedded language like lua5 makes way more sense than a custom/proprietary one.
with my asliases e
is $EDITOR
and se
is sudo $EDITOR
e ~dotfiles/README.md
is nvim ~/.local/src/dotfiles/README.md
se /etc/hosts
is sudo nvim /etc/hosts
you can also start neovim using ec
or editor clean, to run nvim --cmd ":lua vim.g.noplugins=1"
. which is kinda like nvim --clean
with the added bonus of still loading some sane defaults. i use this as my MANPAGER with +MAN!
as well.
my neovim setup is written in lua, uses lazy.vim, and a bunch of plugins. you can enable/disable them selectivly from plugins.lua. here's the structure of configs:
~/.config/nvim
âââ lua/
â âââ utils/i --> shared helper functions
â âââ plugins/
â â âââ alpha.lua --> each plugin has it's own config
â â âââ cmp.lua
â â âââ lsp/
â â â âââ init.lua --> main lsp setup logic
â â â âââ remaps.lua --> lsp key-bindings
â â â âââ servers/
â â â âââ bashls.lua --> language server specific configs
â â â âââ luals.lua
â â â âââ etc...
â â âââ mason.lua
â â âââ etc...
â âââ ui.lua --> ui related options
â âââ commands.lua --> custom commands and key-bindings
â âââ general.lua --> general settings
â âââ lazy-plugins.lua --> lazy.nvim entrypoint
âââ nvim-logo* --> k-rad ansi art
âââ eva-logo* --> evangeion ansi art
âââ init.lua --> calls other files
as of writing this, i use ~50 plugins and an average startup time of 80-125ms. plugin highlights include:
- lazy - the chillest package manager
- lspconfig - native language server protocol
- gitsigns - subtle git diffs in the gutter
- cmp - completion engine
- surround - motions to surround objects w/ characters
- comments - toggle comments with motion
- flog - visually explore your git history
- lualine - customized status bar for the rice factor
- tint - desaturate inactive panes for visual cues
- indent_blank_line - eyecandy for indentation whitespace
- telescope - extensible fuzzy finder with native floating windows
- telescope-undo - view your undo history as a tree of diffs
- telescope-live-grep-args - ripgrep powered fuzzy search
- telescope-file-browser - file browser, for when you need it
- lush - interactive colorscheme development tool
- evangeion - my own colorscheme
- alpha - hipster splashscreen with awesome text art
- which-key - help define and display key-bindings
my leader key is set to ,
and you can checkout all my custom key-bindings by calling :WhichKey
previews
more at https://lab.x-e.ro/rice/
license
all files and scripts in this repo are released CC0 / kopimi! in the spirit of freedom of information, i encourage you to fork, modify, change, share, or do whatever you like with this project! ^c^v
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot