Computer Science

What happens when a Windows user tries to use as much CLI as possible

For the past week, I found many CLI replacements for GUI tools that I no longer enjoy.

Lim Xing Zhi

Dec 4, 2021 — 4 min read

For the past week, I found many CLI replacements for GUI tools that I no longer enjoy.

Why suddenly go CLI fanatic

The main git repository I access at work constantly has over a dozen open branches at any given time. Like a frog in boiling water, I didn't notice how slow my GUI git client was slowly getting over time. Maybe it's caused by its ElectronJS nature, or maybe it's the number of new features the devs are stacking in so quickly, idk. But the point is, my GUI git client is slow and closing it releases some negligible space in RAM, but frees up tons of CPU headroom (I use an Intel Core-i5 U series CPU, I need every cycle I can get). So yea, that is how I started my journey to explore how far I can push the CLI experience on Windows.

Why not use WSL?

Because my laptop is slow, and I am not a fan of the experience.

My Setup

I am using the windows terminal program, running Git Bash. Why these two? They are already installed in my machine since the start, so I didn't give it much thought. This is my virtual desktop that holds all my CLI tools. They are labelled so I can talk about them easily.

*It's blurred because its a client's project*

Read: What is bash alias and .bashrc and How to split panels in Windows Terminal

1. Keep Fetching new changes

My GUI git client automatically fetches new updates in the backend. To replace that feature, I wrote a simple loop that does a git fetch --all once every minute. And now my logs will always have the latest changes.

alias spoll='git fetch --all;while sleep 60; do git fetch --all; done'

fetches the git repo once every minute

Usage: cd /project-dir and then spoll

2. Mocking tool

Our custom internal API mocking tool, I don't know much about it other than it's a lot of work to develop by our QA folks and it's super awesome.

3. Build Script

This is where I run npm run start. I also write do commits and git status here, since writing commits and running build scripts will never be concurrent tasks.

4. Git Logs

I print my git logs here. I needed a CLI replacement for me to visualize opened branches and how they related to each other, so I wrote this bash alias

alias graph='git log --pretty="%C(Yellow)%h %C(magenta)%C(italic)%ad%C(auto)%d  %C(reset)(%C(Green)%cr%C(reset))%n%C(Cyan)%an: %C(reset)%C(italic)%s%n" --graph'

I only had to write this once btw

Usage: cd /project-dir and then graph or graph --all

It's a bit long, but this is what it does: It takes the git log and puts all the commits on a visualized graph. The --pretty parameter is just fancy formatting that is custom-defined.

5. GitHub CLI

GitHub provides a CLI interface to interact with its services. From the terminal, I can create pull requests, read comments on the pull requests, look at GitHub build statuses, checkout individual pull requests and have the branch resolved locally in git. It is a rather enjoyable alternative to the web interface.

Usage: gh pr diff 780 to print changes on the pull request, gh pr view 780 --comments to look at the description and comments on a pull request and gh pr list -A limxingzhi to look at all my opened pull requests in the current repository.

Read https://cli.github.com/

Good to haves

There are a list of things that are good to have if you decided to try using the CLI full time.

Many CLI programs use the less command to view and navigate files. Most notably git log. Knowing some basic shortcuts for less and/or vim will be helpful.

Side by side diffing

I found this neat little program called ydiff. It is a program written in python and allows me to read my git diff side by side.

Pipelines

In Unix systems, a key inter-process communication mechanism for passing information from one program to another is pipeline. You can pass the output of one program to another. One example is echo 'hello world' > text.txt. This one-liner allows us to write to a file called "text.txt" with the content "hello world". One usecase I have for this is my PR diffing.

function whatdiff () {
  $@ | ydiff --wrap -s
}

Bash function in my .bashrc file that pipes the output into a diffing program

Usage: whatdiff gh pr diff 780

There are 2 separate things going on there. First, gh pr diff 780 fetches and prints out the changes in a git-diff format. I then pipe it to the ydiff program to display it in a pretty way. So what is actually running behind the scenes is gh pr diff 780 | ydiff --wrap -s. The output of the first command is piped into the second one.