This repo isn't meant to be used by other people. It's just for me to use while letting others "peer over my shoulder" to see how I have things configured.
This is how I get my dotfiles installed in a new /home/am directory,
aka $HOME. I start with cloning this repo:
git init . git remote add -t \* -f origin git@github.com:amontalenti/home.git git checkout master
I may hit conflicts with the existing .bashrc or .profile. Just move those to another directory and let it run.
Once I clone the repo, I'll need to restart the shell. If I'm logged in to a fresh Linux box (e.g. Ubuntu or similar) via ssh, the simplest way to do this is to log off and log back on.
On a freshly bootstrapped Ubuntu machine, I can typically clone this git repo and get going pretty quickly with bash. But, in my day-to-day development, I use zsh. For years, I used bash only, and mostly out of habit. Nowadays, I keep my bash environment around to give me the option to use bash for shell script debugging.
I find it convenient to keep my "basic" bashrc configuration around, and then "layer" my zsh configuration over them. The bash config is summarized here:
| file | description |
|---|---|
| ~/.bashrc | pulls everything together |
| ~/.bash_aliases | handy shortcuts |
| ~/.bash_env | sets up my environment the way I like |
| ~/.bash_functions | when an alias doesn't cut it |
You might wonder why it's handy to keep bash in a working state, and around. Two reasons. First, when you first clone this repo into a fresh Linux box, you'll find that bash is the default shell. It's therefore nice to have it working. Second, sometimes you are working on customizing your shell itself, and you break things. In these scenarios, it's handy to have another "working" shell laying around until you fix things. For me, bash and zsh play this role for one another.
I like to get bash up-and-running fully before zsh. Do this:
- Install pyenv
- Install cargo
- Install nix
- Install uv (experimental)
At this point, my bash should be fully functional. Then, to get zsh:
- Install zsh
- Install oh-my-zsh
- Layer my oh-my-zsh customizations over the fresh install
- Install the p10k theme
- Install an extra oh-my-zsh plugin
We'll follow ALL these steps in turn.
We use pyenv to compile Python and manage Python environments, because some of my helper scripts rely on Python and pyenv, and expect it. The one-liner here should be:
curl https://pyenv.run | bash
To install Rust and cargo, check out this page in the cargo book:
curl https://sh.rustup.rs -sSf | sh
To install nix, check out this download info on the Nix website. If it's a laptop, desktop, or server I fully control, I should do the multi-user install:
sh <(curl -L https://nixos.org/nix/install) --daemon
After you install, you should activate the default nix profile for current user:
nix-env --switch-profile /nix/var/nix/profiles/default
Lately, I've been using uv as an alternative to pyenv and pip. Install:
curl -LsSf https://astral.sh/uv/install.sh | sh
Read more about uv.
To install zsh, I rely on apt. So:
sudo apt install zsh
Because this git repo contributes a ~/.oh-my-zsh directory, you need to do a little dance to setup oh-my-zsh. You need to temporarily move it aside, then run the installer, and then rsync the contents of the original cloned repo back into it. Then you can get rid of the backup. Try this:
mv ~/.oh-my-zsh ~/.oh-bck sh -c "$(curl -fsSL https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)" rsync -Pav ~/.oh-bck/ ~/.oh-my-zsh/ rm -Rf .oh-bck
You need to install the p10k theme via this recipe:
git clone --depth=1 https://github.com/romkatv/powerlevel10k.git ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/themes/powerlevel10k
Similarly, you need to install zsh-better-npm-completion thusly:
git clone https://github.com/lukechilds/zsh-better-npm-completion ~/.oh-my-zsh/custom/plugins/zsh-better-npm-completion
Then, I'll try it out by running zsh before switching shell, by simply running zsh.
With zsh, I took a different approach than bash, but it's unified my bash
setup for common aliases and functions. I have a simple .zshrc that
implements the equivalent of .bash_env.
In bash, my prompt (PS1) is set entirely by the simple bash
environment, and is very basic, optimized for prompt render speed.
In zsh, things are a bit more "souped up", and I have two prompt themes
available:
powerlevel10k/powerlevel10kis the amazing p10k theme that leverages a pure zsh implementation of the fastest and most configurable prompt one could imagine.ampy, short for "Andrew Montalenti Python Prompt"; the prompt is implemented via an oh-my-zsh theme that outsources most of its work to a Python script calledzshprompt, which lives in~/opt/bin/
Thus, my "full" zsh environment is summarized in this table:
| file | description |
|---|---|
| ~/.zshrc | pulls everything together |
| ~/.../custom/themes/powerlevel10k | cloned submodule for powerlevel10k |
| ~/.p10k.zsh | zsh script for the powerlevel10k config |
| ~/.oh-my-zsh/themes/am.zsh-theme | alt theme that provides zshprompt calls |
| ~/opt/bin/zshprompt | Python script to generate prompt |
| ~/.bash_functions | I use these across zsh and bash |
| ~/.bash_aliases | I use these across zsh and bash |
The zshprompt script supports shortened paths, git branches, Python
virtualenvs, and last process exit code, and only when using the am zsh theme.
Here is what it looks like:
Here's the guide:
- path =
~/repos/ptrack/streamparse - virtualenv =
ptrack+streamparse - branch =
feature/visitor-metrics
The right prompt auto-hides when you are writing a long command, and the path
compresses uses a shortening approach (thus ~/r/p/streamparse). You can
also see the exit status of 1 in red of the false command.
As for p10k, examples of that prompt are best covered at the p10k GitHub page.
I found that by customizing .p10k.zsh, I could reproduce all the features
of my zshprompt script, while also having nice support for things that
would be way harder to implement on my own. Also, p10k is super fast to load
through some zsh tricks, so as of 2020, it's preferred.
I use vim for text editing. I tend to use vim for editing all sorts of files, including:
- Python
- JavaScript
- Clojure
- Java
- C
- CSS, LESS, Sass
- HTML, JSON, XML
- reStructuredText
- Markdown
- bash, zsh
- Dockerfile
- configuration files
- Zig, Racket, Scheme, Go, Elixir (for fun)
My vim configuration is a bit customized, as I use vim as a kind of UNIX IDE. However, I don't go overboard remapping things; in general, I'm pretty happy with vim's default mappings and have learned to love them. Most of these customizations are just to make editing typical files for me nicer, and add file-specific or workflow-specific add-ons.
Some nice IDE-like plugins for me include:
- ctrlp, for quick file opening
- dockerfile, for docker support
- fugitive, for git integration
- goyo, for distraction-free writing
- gundo, for undo history
- nerdtree, for file navigation
- parinfer-rust, for speedy indent/dedent of Lisp code
- rainbow_parentheses, for matching parens, especially in Lisp
- repeat, just makes the
.command more flexible and scriptable - simplenote, integrates with Simplenote notes service
- surround, adds a noun to vim for "surroundings", useful for quoting and parens
- syntastic, for syntax checking, mainly Python and JavaScript
- tagbar, for improved code outlines / navigations
- vim-clojure-static, for Clojure basic editing support
- vim-elixir, for Elixir basic editing support
- vim-eslint-compiler, for ESLint :make and quickfix support
- vim-fontsize, for adjusting font size quickly in gVim
- vim-fireplace, for Clojure interaction with nREPL
- vim-flake8, for Python syntax checking
- vim-go, for Go basic editing
- vim-jinja, for enhanced Jinja syntax highlighting
- vim-less, for editing LESS CSS files
- vim-livedown, for live preview of Markdown files
- vim-markdown, improved Markdown syntax handling
- vim-racket, for Racket and Scheme basic editing
- vim-sexp, for Clojure S-expr support
- vim-sexp-ext, for Clojure text motions over S-expressions
- vim-superman: read man pages within vim
- vim-virtualenv, for Python virtualenv support
- vim-yaml, basic YAML file support
- whitespace, to kill trailing whitespace in files
- yajs, yet another Javascript syntax
- zeavim, integrate Zeal documentation lookup
- zig.vim, syntax highlighting for the Zig language
These are referenced via git's submodule facility, because this seemed like the cleanest thing. Therefore, after cloning this repo, make sure you also clone the submodules as such:
git submodule init git submodule update
Then you will have all of the above.
In vim, I use the Mustang color scheme. Yes, I know about Solarized, and yes, I recognize that it is this new hotness with all of its fancy marketing pages, but honestly that color scheme will make me blind or make me want to murder my computer.
Mustang uses nice muted colors while still having enough contrast for scanning big chunks of code. I think it's very zen hacker like.
In tmux and screen, I use a matrix-like green-on-black color scheme. I do this so I can impress Parse.ly engineers and encourage people to learn the joys of UNIX.
Unfortunately, there is some trickery with UNIX color schemes for terminals.
The first thing you have to learn about is that most terminals do not automatically place themselves in 256 color mode -- of course, they should, but this is UNIX. The software is Free and your time is worthless.
The answer is to be very mindful of two parts of your environment that will dramatically affect the way colors display. These are:
TERMenvironmental variable- Color palette of your terminal emulator
Let's cover these in turn. The TERM environmental variable should be
xterm-256color. Except when it shouldn't, which is when it's running under
tmux or screen (of course). In these environments, it should be
screen-256color. If this isn't set appropriately, programs like vim won't
use your fancy color scheme and you will be sad.
Finally, the color scheme will render differently depending on your color palette. What's going on here is that your terminal emulator can translate the colors being generated by vim and other programs, and translates them to actual pixel colors on your screen. (It's just yet another level of indirection.) I find that most of the default palettes are way too bright and loud.
With gnome-terminal (Linux) and other platform-specific terminals across OS X and Windows, you'll want to pick the Tango palettes, which are a tad muted and relatively standard across platforms.
I put some scripts in ~/opt/bin that just make my life easier. Most
of these are bash scripts, some are little Python scripts as well. Some
of these are just meant to work around some UNIX annoyances.
Originally, I used GNU screen for all my terminal management, so my
.screenrc is included here. However, I have now switched to
tmux, since I came across a nice book about it and it convinced me.
Funny enough, I was able to port over most of my customizations of
screen to tmux pretty straightforwardly. See .tmux.conf for that.
I also use a clever little tool called tmuxp, which is a Python frontend on tmux which allows you to save / re-open tmux "sessions".
I primarily use git. I don't customize it too heavily, but my .gitconfig
is included here anyway.