Tag: iterm2

Intro

Having realized that I’d been spending more and more time in an ssh shell in the last year or two, I decided that I needed to up my terminal game. I’d been using bash and vim for a while now, but wanted to fine-tune my developer experience by:

• giving zsh a try,
• improving my vim setup,
• being able to split up my terminal window, and
• enabling myself to get productive quickly on new machines.

This last point is key. I often find myself on new systems and hate not having all of my configurations available. So I decided that I would set up a github repo that I could quickly call from anywhere to provision all of my favorite tools and settings (env vars, paths, aliases, functions, config files, executables, etc.).

This turned out to be a heftier project than I expected, so I won’t take you through step-by-step everything I did, but I will describe the overall approach, share my code, and encourage you to embark on your own workflow-revamping project.

Choosing Technologies

iTerm

I’ve been using a MacBookPro for many years now with iTerm2 as my terminal of choice. It’s overall a more complete/customizable application than the native Terminal App, and has some great additional features such as “profile switching”^​*​ and the ability to print images directly in the terminal, even if you’re on a remote machine (without X-forwarding, etc.). If you’re on a Mac, then take the time to set up iTerm2.

Bash & Zsh

I’d been a bash-only guys for many years, but heard good things about zsh, especially powerlevel10k and ohmyzsh, so figured I’d make the switch for my everyday shelling. My scripts will remain in bash, of course, but I want to be able to have a decent bash experience as soon as possible on any machine, as well as the ability to install zsh with minimal additional effort if I expect to use that machine repeatedely.

Vim

Every IT person, it seems, has to choose between vim and emacs. I like keeping my fingers on the home keys, and so I concluded long ago that emacs wasn’t for me (due its dependence on the ctrl key). If I had to recommend vim or emacs to a beginner, I would say vim mainly because I like that it makes you think about editing in a whole new way (viz. modally).

In any case, Vim has been my go-to terminal editor for some years, but I didn’t use it for any serious editing, and that left me frustrated at times when I was on a remote server and wanted to dig through some code for a quick fix. My goal here was therefore to improve my speed, learn more tricks, and set things up so that I could do proper IDE-like editing in the terminal on any machine.

One thing I’ve come to accept in using vim is that it just sucks without a ton of plugins and settings in your .vimrc file. (E.g. I consider the Esc key unusable on my Mac keyboard, especially since Apple made it part of the prone-to-crash power bar). I also can’t stand vim’s default copy/paste system, so I have to employ a lot register logic to make items available to the system clipboard. In short, I gave up long ago of trying to use vim’s ‘out-of-the-box’ settings, which made my need to easily ship my .vimrc around the internet all the more pressing.

Tmux

Before I set myself this project I had never bothered using a mutliplexer. That meant that if I wanted to have multiple ssh shells available at one time, I’d have to create separate tabs in iTerm2 and initiate multiple ssh tunnels. Not only was this slow and inefficient, but it meant that I simply couldn’t have multiple shells running if, for example, I was working on a machine’s boot terminal. So I decided that I would learn a multiplexer.

The toughest call I had was choosing tmux or screen for my terminal multiplexing. My main concern was choosing the one that was more commonly pre-installed on linux distros (in case I find myself wanting to be quickly productive on a system without root privileges). I could not get a definitive answer to this question, but the impression I got was that although screen is historically the more commonly pre-installed multiplexer, tmux is on the rise (the most notable case being RHEL/Centos 8 dropping screen in favor of tmux). So, for better or for worse, I went with tmux.

Note: iTerm2 has tmux sort of built into it, but I did not want to use that since I wanted to get used to standard tmux for use on any system.

Result: myconfig

The result of my workflow revamping was a repo called myconfig. Now, all I have to do is copy and paste the command in this repo’s Quick Start section into the shell of a Mac, RHEL/Centos or Debian machine that already has git. This command will clone/update the myconfig repo to /tmp/myconfig, and then source /tmp/myconfig/tmp_install.sh, which leaves you in a bash shell on the new machine that (i) detects whether I’m on a Mac, Debian or RHEL/Centos machine, and (ii) accordingly sets paths, functions, etc. to leave me within a productive state within seconds! (It even initiates a background installation of vim plugins if vim is detected on the system!)

This “temporary” installation of myconfig and its contents is kept entirely within /tmp so that I don’t muddy whatever person’s account I might be using. However, the shell is endowed with a function myconfig_full_installation that I can run if I want to install myconfig to the account’s home directory, as well as key config files such as .tmux.conf, .vimrc, .bashrc, and .zshrc.

Myconfig also provides me with scripts to build the latest, feature-complete vim, tmux, zsh and git executables (in case I find myself on a machine with outdated software).

In summary, I can now have most of my settings/config established on any of my target machines with just a single copy/paste command.

Building vim and tmux from source

One of the trickier parts of creating myconfig was enabling me to access a high-feature build of vim and tmux on my target machines without sudo permissions.

Not all installations of vim are born equal. To examine the features available on your installation, you can type vim --version and examine the items prefixed with ‘+’ or ‘-‘. The two features I need for my vim usage is +clipboard and +python3. These features are not available on the default vim installation on Centos 7 or even Ubuntu 18. So I had to create scripts to install vim from source code with these features on my two flavors of linux, which you can see here and here.

In the case of Centos 7, I needed to be able to build it from source without sudo permissions. To develop that script, I found it very helpful to simulate my target machine using the docker image from yamamon/centos7-minimal, and installing only those packages that had been made available to me by that machine’s admin (viz. using `yum list installed | grep ABC` ).

Summary

Ever since investing in my workflow I not only feel like my efficiency has increased, and I learned a surprising amount of devops/admin stuff by having to research these various technologies. I also just enjoy my ssh-ing a lot more now. The combination of tmux, iTerm2, zsh (along with oh-my-zsh and powerlevel10k), has turned my boring old shell into power-zone work of art.

So if you haven’t got your own system sorted out for quickly transferring your workflow to new machines, then I recommend it and hope that myconfig can give you some helpful tips along the way.