In your $HOME, do this:
git init .
git remote add -t \* -f origin git@github.com:amontalenti/home.git
git checkout masterYou may hit conflicts with your existing .bashrc or .profile. Just move those to another directory and let it run.
Once you clone the repo, you'll need to restart your shell. If you're 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.
To get zsh up-and-running takes a few more steps than bash. We need to:
- Install pyenv
- 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 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 | bashTo install zsh, I rely on apt. So:
sudo apt install zshBecause 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-bckYou 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/powerlevel10kSimilarly, 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-completionThen, 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
- 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
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 updateThen 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.