DEV Community: Goran Vasic

Using Zsh and zsh-autosuggestions on Windows Terminal with Oh My Posh theme

Goran Vasic — Sat, 08 Jun 2024 18:05:05 +0000

This article contains unstructions on how to configure Windows Terminal to use Oh My Posh with Zsh and zsh-autosuggestions.

This approach is not relying on WSL, it is utilizing existing Git installation on Windows. This way, you can have fully functional Zsh shell with autocomplete natively on Windows, just like you would on Mac.

Some people recommend using ble.sh – Bash Line Editor, a command line editor written in pure Bash which replaces the default GNU Readline (mentioned in Bash vs ZSH vs Fish: What's the Difference?). However, on Windows I still prefer using Zsh with zsh-autosuggestions.

Configuration Instructions

Download and install Git from git-scm. Make sure to uncheck suggested options for Git Bash (e.g. the 2 options under "Windows Explorer integration"). You can select the option to add a Git Bash Profile to Windows Terminal, we will modify it manually later. When asked about adjusting your PATH environment, I like to use the Recommended setting, and I also like to enable symbolic links. I usually keep everything else on default.
From Microsoft Store, install Windows Terminal and winget App Installer. Check if everything has been installed properly by opening a new Windows Terminal session and typing winget --version.
Open your Windows Start menu, and search for "PowerShell".
Run Windows PowerShell as Administrator, then install Oh My Posh using winget, for example:
```
winget install JanDeDobbeleer.OhMyPosh -s winget
```
Close PowerShell, then add oh-my-posh path to your Windows environment variables (User):
1. Press Win + r.
2. Type in control and hit ENTER.
3. Navigate to "User Accounts".
4. Click on "User Accounts" one more time, then click the "Change my environment variables" link on the left side to open the "Environment Variables" window.
5. In the upper (User) part of the window, scroll down and select Path, then click the Edit... button.
6. Depending on the way your variables are displayed, either click New to add a new variable, or add a ; at the end of the line, then type in %LOCALAPPDATA%\Programs\oh-my-posh\bin for the value. It might be that this value already exists, in which case you don't need to edit anything.
7. Press OK, then confirm every previously opened window by clicking OK.
Run PowerShell one more time with Administrator privileges, then install either the FiraCode Nerd Font or SauceCodePro Nerd Font (I prefer SourceCodePro) from Nerd Fonts using the following command (follow their instructions in order to select the desired font):
```
oh-my-posh font install
```
Start a new Git Bash terminal by double-clicking on git-bash.exe located under C:\Program Files\Git\.

Download the Zsh for Windows package zsh~x86_64.pkg.tar.zst by executing the following command:

curl -fsLo $HOME/zsh-5.9-2-x86_64.pkg.tar.zst https://mirror.msys2.org/msys/x86_64/zsh-5.9-2-x86_64.pkg.tar.zst

In Windows Explorer, locate the downloaded .zst file in your home directory and extract it either using:
- PeaZip, which can be installed using the winget install -e peazip command, or
- 7-Zip (I prefer this option, since I already have it installed).
You only need the etc and usr directories, so copy these two directories from the extracted folder into C:\Program Files\Git and when prompted, select the option to overwrite all existing files – don't worry, these two directories (etc and usr) contain completely new files, no existing files will be overwritten.
Open %PROGRAMFILES%/Git/etc/profile in your text editor as Administrator (because you might need elevated privileges in order to save the changes) and:
- Comment out the entire block near the bottom of the file that starts with line if [ ! "x${BASH_VERSION}" = "x" ]; then and ends with line fi. At the moment of writing the article, I commented out lines 111-133. We don't need all of this code since we know we will be using Zsh.
- Below the commented out block, add the following 3 lines:
```
HOSTNAME="$(exec /usr/bin/hostname)"
profile_d zsh
SHELL='/usr/bin/zsh'
```
- Save the changes.
Open the Windows Start menu, search for "Terminal" and start it.

Open Windows Terminal's settings using the Ctrl + Shift + , keyboard shortcut, then under the profiles > list array modify the existing Bash profile, or add a new profile:

{
  "name": "Git Bash",
  "guid": "{12398ec4-4e3d-5e58-b989-0a998ec441b1}",
  "commandline": "%PROGRAMFILES%/git/usr/bin/zsh.exe -il",
  "icon": "%USERPROFILE%/git.ico",
  "startingDirectory": "%USERPROFILE%",
  "colorScheme": "VibrantInk",
  "font": 
  {
    "face": "SauceCodePro NFM"
  },
  "useAcrylic": true,
  "opacity": 70,
  "adjustIndistinguishableColors": "always",
  "bellStyle": "none",
  "hidden": false
}

HINT: For the code mentioned above, make sure to add the , character after the closing curly brace, if needed, so that the settings file syntax is valid.
The profile above uses a custom ~/git.ico icon, so you can either reference the default git-for-windows.ico icon file under C:\Program Files\Git\mingw64\share\git or find another one you like.
If you wish, you can also set the above profile to be your default Windows Terminal profile by setting the same guid as the defaultProfile value in the settings JSON.
Restart Windows Terminal and verify that everything is working (configure zsh using the interactive menu).
Execute the following command from any location to install Oh My Zsh under your $HOME/.oh-my-zsh directory:
```
sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"
```

Clone zsh-autosuggestions using the following command:

git clone https://github.com/zsh-users/zsh-autosuggestions.git $ZSH_CUSTOM/plugins/zsh-autosuggestions

Open ~/.zshrc file, comment out the line that sets ZSH_THEME on line 11 (we will be using Oh My Posh theme, not Oh My Zsh), then below on line 73, add the zsh-autosuggestions plugin to oh-my-zsh plugins:
```
plugins=(
  git
  zsh-autosuggestions
)
```
Save the changes and verify that autosuggestions are working (you need to have something in your history first, so type a couple of commands in Windows Terminal, exit with logout, then start the Terminal again). NOTE: On first run, ~/.zcompdump file will be created, so it is normal for Terminal to start a bit slower.

Grab the Gocilla theme for Oh My Posh and save the file under oh-my-posh themes:

curl -fsLo $HOME/AppData/Local/Programs/oh-my-posh/themes/gocilla.omp.json https://raw.githubusercontent.com/goranvasic/gocilla-oh-my-posh/main/gocilla.omp.json

Navigate to your Windows %USERPROFILE% directory, and open the .zshrc file one more time.

Add the following line below the source $ZSH/oh-my-zsh.sh line:

eval "$(oh-my-posh init zsh --config $HOME/AppData/Local/Programs/oh-my-posh/themes/gocilla.omp.json)"

Restart Windows Terminal and verify that everything is working properly.

That's it. Hopefully this works on your side. You can run this customized Zsh in IntelliJ or VS Code by setting the built-in terminal to open "C:\Program Files\Git\usr\bin\zsh.exe" -il.

You can find the latest version of these instructions on my GitHub repo here. Any comments or suggestions for improvement will be much appreciated.

Python Exceptions

Goran Vasic — Sat, 27 Apr 2024 16:39:09 +0000

An Exception is a special type of object in Python, and Python has many built-in exception types. All exceptions must be instances of a class that derives from BaseException, which means that Python exceptions form a hierarchy.

To raise an exception, means to start an exception event flow. Exception handling is interacting with an exception flow in some manner. An unhandled exception is an exception flow that is not handled by your code, and generally it means that your program will terminate abruptly.

There are several built-in functions you can use to inspect the exceptions:

# Create an exception object
ex = ValueError("An unexpected value has been provided.")

# Inspect an exception
type(ex) # -> ValueError
print(ex) # -> An unexpected value has been provided.
repr(ex) # -> ValueError("An unexpected value has been provided.")

# Raise an exception
raise ex

LBYL vs EAFP

Something that is "exceptional" should be infrequent. If we are dividing two integers in a loop that repeats 1.000 times, and if, out of every 1.000 we run, we expect division by zero to occur 5 times, we might have 2 approaches:

LBYL (Look Before You Leap) – Test that divisor is non-zero 1.000 times.
EAFP (Easier to Ask Forgiveness than Permission) – Just do it, and handle the division by zero error 5 times (this is often more efficient).

Also, trying to fully determine if something is going to go wrong is a lot harder to write than just handling things when they do go wrong.

Read the Look Before You Leap article for more info on LBYL and EAFP approaches for exceptions.

Optimizing Performance with Exceptions

In some cases, relying on exceptions can help you improve your code performance. Consider the following Python code:

from timeit import timeit

def process():
    l = list(range(1_000))
    while len(l) > 0: # Calling the len() function in each iteration
        l.pop()

timeit("process()", globals=globals(), number=500_000) # 40.69522000011057

The issue with this code is that it checks the length of the list by calling Python's built-in function len() at every iteration.

A significant performance improvement can be achieved by using the for loop, which checks the length of the list only once:

from timeit import timeit

def process():
    l = list(range(1_000))
    for i in range(len(l)): # Calling the len() function once
        l.pop()

timeit("process()", globals=globals(), number=500_000) # 25.074866899987683

In this case, the code executes almost 50% faster (25s compared to previous 40s). The issue here is that the process() function is again being called 500.000 times by the timeit() function, and the process() function still invokes the len() built-in function at every iteration.

A better solution turns out to be using the try-except block, where you simply ignore the IndexError exception that gets raised if the pop() method is called on an empty list:

from timeit import timeit

def process():
    try:
        l = list(range(1_000))
        while True:
            l.pop()
    except IndexError:
        ... # Ignore the exception

timeit("process()", globals=globals(), number=500_000) # 18.16189290001057

With this approach the same code takes only 18 seconds to execute. It is worth mentioning that you should always target a specific exception – in this case IndexError, not Exception, which is too broad.

Using Your Own Exceptions

In Python you can define your own custom exceptions:

# Define a custom exception class
class MyCustomException(Exception):
    def __init__(self, message="A custom exception occurred"):
        self.message = message
        super().__init__(self.message)

# Check if MyCustomException is a subclass of Exception
print(issubclass(MyCustomException, Exception)) # True

# Example usage of the custom exception:
try:
    raise MyCustomException
except MyCustomException as ex:
    print(f"Caught exception #1: {ex}") # Caught exception #1: A custom exception occurred

# Example usage of the custom exception with different error message:
try:
    raise MyCustomException("This is a custom exception")
except MyCustomException as ex:
    print(f"Caught exception #2: {ex}") # Caught exception #2: This is a custom exception

`try-except-else-finally`

In combination with the try-except block, Python's syntax allows you to use the else clause that executes only if the try-except block was successful, and the finally clause that is always executed, so you can use it to ensure that certain tasks are performed if your application terminates abruptly:

# No exceptions raised
x = 4
y = 2

try:
    z = x / y
except ZeroDivisionError:
    raise
else:
    print(f"ELSE: {x} / {y} = {z}")
finally:
    print("FINALLY: Perform some tasks...")

# ELSE: 4 / 2 = 2.0
# FINALLY: Perform some tasks...

# Dividing by zero raises ZeroDivisionError
x = 4
y = 0

try:
    z = x / y
except ZeroDivisionError:
    raise
else:
    print(f"{x} / {y} = {z}")
finally:
    print("Perform some tasks...")

# FINALLY: Perform some tasks...
# ---------------------------------------------------------------------------
# ZeroDivisionError                         Traceback (most recent call last)
# Cell In[9], line 5
#       2 y = 0
#       4 try:
# ----> 5     z = x / y
#       6 except ZeroDivisionError:
#       7     raise
# 
# ZeroDivisionError: division by zero

Using Git on the Command Line

Goran Vasic — Sat, 26 Sep 2020 08:36:00 +0000

This article dives into the more advanced Git topics, providing valuable tips and tricks for using Git on the command line. By going through concrete examples, you will become more confident while working on the command line, greatly increasing overall productivity in your daily job.

What is Git?

Git is, by far, the most widely used free and open source modern distributed version control system (VCS), an efficient and trustworthy tool that helps you keep track of all the changes in your source code during software development.

It was initially developed by Linus Torvalds in 2005, for development of the Linux kernel, and with significant help from other developers such as Junio Hamano, it is still an actively maintained project on GitHub. From the early stages, Git was designed to handle both small and very large projects with speed and efficiency, and since then, it has become a de facto standard tool of its kind.

GUI vs Command Line

In spite of its popularity, Git is often criticized for being difficult to learn, primarily due to its command line nature which makes it hard for new users to become familiar with all of the commands and options Git has to offer. This is the main reason why a lot of developers, soon after being introduced to Git, start looking for a GUI client, convinced that it will make them faster and more productive. And it often does, at least in the beginning, as there are a lot of modern third-party tools that offer great user experience and cutting edge features, such as GitHub Desktop, SmartGit, GitKraken or Git Tower, to name a few.

The problem is that in the long run, instead of investing their time into learning Git, developers become dependent on these GUI clients and fail miserably the very first moment they have to act quickly from command line, without having the right tool at their disposal. That is why it is always a good idea to take it one step at a time and to practice Git from command line first, because over time, it will make you feel more comfortable and confident while using Git from terminal, greatly increasing productivity in your daily job. In other words, if you wish to become a Git master, you will have to go back to basics and build up from there.

Using aliases

One of the very first things we all probably did using Git was setting up our name and email address. It is your first day at a new job, and the colleague sitting next to you tells you that the best way to configure Git is by passing the --global option, for example:

$ git config --global user.name "Your Name"
$ git config --global user.email "your.email@example.com"

If this was the first and last time you've used the config command, there is a chance that you are unaware of the fact that Git can be configured on three levels: local, global and system. Since "local" is the default option, you do not have to specify --local when invoking the git config command from your repository:

$ git config --local user.name "Your Name"
$ git config user.email "your.email@example.com"

This command will create a "config" file under your $REPO/.git directory, after which it will take precedence over --global setting for every value it contains.

This becomes extremely useful as soon as you have to start working on 2 separate projects, where one of the repositories requires that you configure your corporate email, and the other one your client's email address.

In practice, it is completely fine to configure most of the Git settings on a global level, but it is worth remembering that each Git configuration level overrides values in the "upper" level:
local > global > system

Global configuration level is usually more suitable for creating aliases that can replace specific commands which are used often, but are long and cumbersome to type. For example, Git's log command offers a lot of information by default, but it can be rather difficult to get the high-level overview of all commit messages, which is what we usually want. For this reason, most people often use git log with some additional options, in order to simplify the output or to limit the number of results, e.g.

$ git log --oneline -n10

But we can take this a step further, and instead of constantly typing the --oneline option or limiting the number of results to 10, we can specify the exact kind of information we need by globally configuring a hist alias that will show us the last 10 commits accompanied by a nice graph:

$ git config --global alias.hist \
  "log --graph --date=short --abbrev=10 \
  --format='%C(yellow)%h %C(white)%ad %C(green)%s %C(cyan)[%an, %ar]%C(white)%d' \
  -n10"

I know that this might scare you at first, so try removing the "format" part from the command to make it more readable.

Executing this command will allow us to use the hist alias to display the latest 10 commits from Git history. We can even override the number of displayed commits to show the last 20 commits, for example:

$ git hist -n20

Overriding specific parameters is certainly useful, but it is worth noting that Git allows you to pass parameters to an alias:

$ git config --global alias.echo '!f() { text=${1-Hello World}; echo $text; }; f'

Again, the example above might seem confusing at first, but if you focus only on the part between the quotation marks, you will see that we are defining an anonymous function by specifying its body between curly braces, and we are then invoking it. Individual commands are separated by semicolons, and we have defined a variable "text" which takes the first parameter or defaults to "Hello World" if the parameter has not been passed. The function then prints value of variable "text" to the console using standard system command echo.

As you can see, this enables us to write powerful functions that accept one or more parameters, and by utilizing both Git and OS level commands, you can easily create custom Git plug-ins that may be used by your entire team for some specific tasks.

We can try out this concept by defining the find alias that will allow us to quickly search for a particular commit message using case-insensitive text:

$ git config --global alias.find '!f() { \
  text=${1}; \
  results=${2-10}; \
  git log --all --full-history --oneline -n$results \
  -i --grep="$text"; \
  }; f'

Now, by using the following command, we can search through all commit messages that contain a specific word, such as "refactor", limiting output to only 5 results:

$ git find "refactor" 5

Reset

One of the things that often make beginners uncomfortable (perhaps even scared) while using Git is its tendency to keep track of all the file changes in a repository. In other words, even if you only wish to compile the project without modifying any code, Git is still going to detect all artifacts produced after compilation and report that there are new files present in your repository.

Manually deleting files or adding them to .gitignore is often the easiest or quickest solution, but if there are a lot of random untracked files in your working directory, you should be aware of the following command which helps you clean-up dirty working tree:

$ git clean -f -d

In the command above, parameter -f means "force", and it will remove any untracked files, as well as any subdirectories that become empty as a result.

You should not worry about losing any changes on your existing files, they will remain intact. On the other hand, in a situation where you would like to revert all changes performed on tracked files while leaving the untracked files as they were, you can run:

$ git reset --hard HEAD

You can omit HEAD because it is implied, and it is not mandatory to use uppercase letters. Finally, if you wish to undo all of your changes, you can reset the entire working directory to the state of the latest commit by adding all files in the working directory to the staging area first, and then performing a hard reset on them:

$ git add .
$ git reset --hard

Undo

Having an "undo" option in software is such a common feature these days that we often end up shocked once we realize that it is not available. Valuable data can be lost and irreversible damage can be made. This is one of the main reasons why beginners hesitate so much when someone asks them to commit their changes in Git. What if they have just made a huge mistake, and there is no way back?

The good news is that you can revert your changes even after committing them, the same way as you can revert all changes to your tracked or untracked files. The only difference this time is that, instead of referencing the last commit using HEAD, you should perform a hard reset to a previous commit, which can be referenced using HEAD^:

$ git reset --hard HEAD^

There is a more convenient notation for referencing one or more commits, such as HEAD~1, HEAD~2 etc. This way of undoing changes almost feels like you are peeling the layers of an onion. But what if, instead of completely removing a layer, you only wish to change (update) the last commit? You can step back and re-commit your changes by performing a soft reset to a previous commit:

$ git reset --soft HEAD~1

Similar result can also be achieved by amending previous commit. In a situation when you forget to add some important files to a commit you've already created, or if there are some changes that logically belong to a previous commit, it is a better route to modify the existing commit by adding these changes to staging area, and then committing them using the --amend option:

$ git add .
$ git commit --amend

Git will prompt you to update the old commit message, after which it will replace the old commit with a new one. This new commit will also get a unique hash, as a result of containing both old and new changes, so it is important to note that undoing or modifying your commit history is fine as long as you haven't published the old commit history to a remote repository.

In case that you did, Git will refuse to overwrite your remote repository's commit history and will warn you as soon as you try to push your newest changes. At this point, you should coordinate with your team members, because some of your colleagues might have already pulled your previous changes and started working on top of them.

You can imagine how problematic this can become when you have a large team of developers contributing to the same repository. That is why, in these type of situations, it is always better to revert a particular commit using the following command:

$ git revert <commit>

Reverting a commit will not modify the existing commit history – it will create a new commit on top of it. This new commit will do the complete opposite of all of the changes performed in a referenced commit, so it is completely safe to push it to your remote.

Reflog

By now, you should already feel more comfortable using Git. At least, you should no longer be afraid of creating new commits, knowing how easy it is to undo all of your changes. Actually, you should start committing more frequently, because now you know that you can always reset or modify a commit, but if you perform a hard reset on any uncommitted changes, they are lost for good. As a matter of fact, the only way that you can completely lose your changes in Git is by NOT committing them, because even if you perform a hard reset to HEAD~4, you can always go back.

This is possible because Git keeps a local journal of everything you’ve done in your repository after cloning it. This journal is called "reflog", and it allows you to see all of the actions you've performed on a particular branch by using the following command:

$ git reflog <branch-name>

If branch is not specified, HEAD is implied. Reflog also preserves the order in which you've performed all actions, with HEAD@{0} being the most recent one, and HEAD@{1} the one before it. This way, even if you undo the last 4 commits by hard resetting to HEAD~4, you can always undo that step by performing a hard reset to HEAD@{1}. What's more, if you perform a hard reset to HEAD@{1} one more time, it will again remove the last 4 commits because this was the last action you did before performing an undo. Using reflog for undoing your actions is so convenient that it simply deserves its own alias. The following command creates an alias undo which performs a hard reset to a previous action:

$ git config --global alias.undo '!f() { \
  git reset --hard $(git rev-parse --abbrev-ref HEAD)@{${1-1}}; \
  }; f'

Now, you can simply type git undo whenever you hard reset to a particular commit.

Working with branches

It is possible that you have been in a situation where your fellow developer is unable to perform a quick bug fix because he/she is currently on a separate branch, working on a specific feature, and current code changes are half-done and not ready to be committed. This the right time to introduce them to git stash. Stashing takes your modified tracked files and staged changes and saves it on a stack of unfinished changes:

$ git stash save <comment>

You can then checkout another branch, fix the bug, and reapply your stashed uncommitted changes to a previous branch or anywhere you want using:

$ git stash apply stash@{0}

To view all stashed items, use git stash list, and to apply and remove the latest stashed item from the stack, use git stash pop.

There is one more situation which might slow you down, and that is when your code has a dependency on a particular commit that has been published to the remote repo. The only problem is that you are on a separate branch and do not want to merge all of the changes that came before and after that commit. You can easily solve this problem using Git's cherry-pick feature:

$ git cherry-pick <commit>

This will take a particular commit that exists on a separate branch and copy it on top of your branch. It's content will be exactly the same as in the original commit, but it will have a different SHA-1 hash.

Fixing merge conflicts

Copying code from other branches or merging your branch with another one can often result in merge conflicts. This happens when both branches contain commits that are changing the same code.

Logically, Git will ask you to choose which changes to keep. The easiest way to resolve conflicts is by keeping either your or their changes:

$ git checkout --ours <file>
$ git checkout --theirs <file>

The other way is to manually edit all files that were modified by both sides. Git has a fairly unknown feature called Reuse Recorded Resolution (ReReRe):

$ git config --global rerere.enabled true

It allows you to ask Git to remember how you’ve resolved a hunk conflict so that the next time it sees the same conflict, Git can automatically resolve it for you.

Rewriting history

Another way of solving the problem with merge conflicts is to resolve them on your branch before you even create a pull request. Git’s pull --rebase allows you to avoid creating merge commits, thus making Git history appear linear:

$ git pull origin develop --rebase

Invoking this command will temporarily remove your code changes and apply the latest changes that have been published to develop branch, simulating a scenario where you have just created a new branch from the latest develop. Then, one after another, it will try to add all of your commits back, stopping whenever a merge conflict occurs. After fixing a potential conflict, you should continue the process by typing git rebase --continue. Eventually, you should end up having the latest changes from "develop", followed by all of your "conflict-free" commits.

Pulling with --rebase is such a common workflow that there is a dedicated configuration option for it:

$ git config --global branch.autosetuprebase always

Another way of rewriting history is by using Git's interactive rebase feature. Among other things, it allows you to reorder, rename, fix, drop or squash commits from your local history:

$ git rebase -i <parent-commit>

Again, after fixing a potential conflict, simply run git rebase --continue. Also make sure not to rebase already published commit history, do this only on your local changes.

Git hooks

Git allows you to enforce code quality on your project using Git hooks. All hooks are scripts, stored in the .git/hooks subdirectory of the Git repository. You can use existing sample scripts by removing ".sample" suffix from their name, or write your own, such as "http://git.io/validate-commit-msg".

Git hook from the example above will warn you if your commit message is longer than 50 characters, and will ask you to modify the message.

Another example could be setting up a server-side hook that gets triggered whenever you push code to your remote repo. It will read all commit messages, and automatically resolve a particular JIRA using a plugin whenever it detects the word "Fix" accompanied by a JIRA number. It is worth mentioning that client-side hooks are not copied when you clone a repository. If your intent with these scripts is to enforce a policy, you'll probably want to do that on the server side.