Module 04: Terminal Mastery for Omarchy Developers

About This Module

The terminal is one of the most important parts of an Omarchy workstation.

You already used it during installation, system verification, GitHub authentication, service checks, and command discovery.

Now we turn it into a daily development tool.

This module is not about becoming a Bash expert.

It is about learning the terminal skills that give you the biggest return as a developer:

• navigating quickly;
• inspecting files;
• searching code;
• chaining commands;
• understanding command output;
• using shell history;
• finding commands;
• working safely with configuration;
• using the enhanced command-line tools that Omarchy already provides.

Current Omarchy ships a collection of improved shell tools, including:

• fzf
• zoxide
• ripgrep (rg)
• eza
• fd
• bat
• tldr

These are not random extras.

They are part of the intended Omarchy workflow.

By the end of this module, the terminal should stop feeling like a fallback interface and start feeling like one of the fastest ways to work.

---

What You Will Learn

By the end of Module 4, you will be able to:

• open and identify your default terminal;
• understand the relationship between terminal emulator and shell;
• read a command line structurally;
• navigate directories quickly;
• create, copy, move, and remove files safely;
• inspect text files;
• search filenames with fd;
• search file contents with rg;
• use eza-based directory listings;
• use bat for readable file output;
• fuzzy-find files with fzf;
• fuzzy-search command history with Ctrl + R;
• jump between frequently used directories with zoxide;
• use pipes;
• redirect output;
• combine commands;
• understand standard output and standard error;
• use quotes correctly;
• understand shell expansion;
• inspect aliases, functions, and executables with type;
• read command help and manual pages;
• add your own aliases and environment variables safely to ~/.bashrc;
• avoid common shell mistakes.

---

4.1 — Terminal Emulator vs Shell

These two terms are often confused.

They are not the same thing.

Terminal Emulator

The terminal emulator is the graphical application displaying the terminal window.

Current Omarchy supports terminal choices including:

• Foot
• Alacritty
• Ghostty
• Kitty

Current official Omarchy documentation identifies Foot as the default terminal for a standard installation, while allowing supported alternatives to be installed and selected.

Our Stevinator workstation baseline uses:

Ghostty

The exact terminal does not fundamentally change the shell skills in this module.

---

Shell

Inside the terminal runs a shell.

Check your configured shell:

echo "$SHELL"

On the workstation used to build this course:

/usr/bin/bash

The shell is responsible for interpreting commands such as:

cd ~/Projects

or:

rg "TODO" src

Conceptually:

Ghostty
→ terminal window

Bash
→ reads and interprets your commands

Linux/Omarchy tools
→ perform the actual work

---

4.2 — Check Your Default Terminal

Omarchy manages the selected terminal through its default application layer.

Run:

omarchy default terminal

Current Omarchy’s terminal default command integrates with xdg-terminal-exec.

That means shortcuts and Omarchy launch helpers can target the configured terminal instead of hard-coding one application.

To inspect the supported choices on your installed version:

omarchy default terminal --help

or:

omarchy commands --all | grep "default terminal"

---

4.3 — Launch a Terminal

Current Omarchy shortcut:

Super + Return

This launches the configured default terminal.

Current Omarchy also provides:

Super + Alt + Return

for launching a terminal with Tmux.

We will cover Tmux in the next module.

For now use:

Super + Return

---

4.4 — Anatomy of a Command

Consider:

rg "TODO" ~/Projects

Break it apart:

rg

is the command.

"TODO"

is an argument.

~/Projects

is another argument.

Now consider:

fd -H "config"

Here:

fd

is the command.

-H

is an option/flag.

"config"

is an argument.

This pattern appears everywhere:

COMMAND [OPTIONS] [ARGUMENTS]

---

4.5 — Command Help

When you do not remember syntax, do not guess.

Try:

COMMAND --help

Examples:

rg --help

fd --help

bat --help

For Omarchy commands:

omarchy network --help

This habit is more valuable than memorizing hundreds of options.

---

4.6 — Manual Pages

Many Linux tools include manual pages.

Use:

man COMMAND

Example:

man rg

or:

man fd

Navigation inside man commonly includes:

Arrow keys / Page Up / Page Down
→ move

/
→ search

q
→ quit

---

4.7 — tldr: Practical Command Examples

Traditional manual pages are comprehensive but can be dense.

Current Omarchy includes tldr, which provides concise examples.

Try:

tldr tar

or:

tldr grep

This is often useful when you know the command but cannot remember the common syntax.

A useful learning sequence is:

tldr
→ quick examples

--help
→ available options

man
→ full documentation

---

4.8 — Your Current Directory

Check where you are:

pwd

Example:

/home/alex

pwd means:

print working directory

Almost every relative path you type is interpreted from this location.

---

4.9 — Basic Navigation

Move to your projects directory:

cd ~/Projects

Move home:

cd ~

or simply:

cd

Move one directory upward:

cd ..

Move into a directory:

cd path/to/directory

---

4.10 — Tab Completion

Do not type long paths manually when the shell can complete them.

Start typing:

cd ~/Pro

then press:

Tab

If the match is unambiguous, Bash completes it.

Tab completion works for many:

• paths;
• commands;
• filenames;
• options.

This reduces typos significantly.

---

4.11 — Listing Files

You already know:

ls

On current Omarchy, the shell environment uses eza to provide richer directory listings.

The official Omarchy shell-tools documentation states that eza is used as the enhanced replacement behind the default ls experience.

Try:

ls

Then inspect what ls actually is:

type ls

You may discover that it is an alias rather than raw /usr/bin/ls.

This is why we learned type in Module 2.

---

4.12 — Omarchy Directory Listing Helpers

Current official Omarchy shell tooling includes useful listing aliases.

Common Omarchy aliases include:

ls

for the enhanced directory listing.

lsa

for showing hidden entries.

lt

for a nested/tree-style view.

lta

for a nested view including hidden files.

Try all four inside:

cd ~/.config

Then:

ls

lsa

lt

lta

Do not worry if exact formatting varies with the current theme/version.

---

4.13 — Inspect Aliases

Run:

type ls

Then:

type lsa

Then:

type lt

The output tells you how Bash resolves each command.

You can also list shell aliases with:

alias

Do not memorize them all.

Use:

type NAME

when you encounter an unfamiliar short command.

---

4.14 — Create a Practice Directory

Let’s create a safe sandbox.

Run:

mkdir -p ~/Projects/terminal-practice

Enter it:

cd ~/Projects/terminal-practice

Verify:

pwd

Everything in the next exercises can happen here.

---

4.15 — Create Directories

Create a directory:

mkdir notes

Create nested directories:

mkdir -p src/components

Check:

lt

-p allows mkdir to create missing parent directories.

---

4.16 — Create an Empty File

Use:

touch notes/todo.txt

Then:

ls notes

touch can create an empty file if it does not exist.

It can also update timestamps on existing files.

---

4.17 — Write Simple Text

Use shell redirection:

echo "Learn Omarchy terminal tools" > notes/todo.txt

Then inspect:

cat notes/todo.txt

Expected:

Learn Omarchy terminal tools

We will explain > properly shortly.

---

4.18 — cat vs bat

Traditional Linux tool:

cat notes/todo.txt

Omarchy also ships:

bat notes/todo.txt

Current official Omarchy documentation describes bat as a cat-style viewer with:

• syntax highlighting;
• line numbers;
• paging.

For source code and configuration, bat is usually more pleasant.

Use cat when:

• output is tiny;
• you want raw output;
• output is being piped elsewhere.

Use bat when:

• reading code;
• reading configuration;
• syntax highlighting helps.

---

4.19 — Copy Files

Create another file:

cp notes/todo.txt notes/todo-backup.txt

Inspect:

ls notes

cp copies.

---

4.20 — Move and Rename Files

Rename:

mv notes/todo-backup.txt notes/archive.txt

mv can both:

• move files;
• rename files.

Move into another directory:

mkdir archive
mv notes/archive.txt archive/

Check:

lt

---

4.21 — Removing Files

Remove a file:

rm archive/archive.txt

Remove an empty directory:

rmdir archive

Be careful with rm.

Unlike a graphical file manager, command-line removal may not use a trash/recycle bin.

---

4.22 — The Dangerous rm -rf

You will see this command on the internet:

rm -rf SOME_PATH

It means roughly:

-r
→ recursive

-f
→ force

This can remove directories and their contents without normal interactive protections.

Do not copy an rm -rf command unless you understand the exact path.

A missing variable or typo can be destructive.

Course Rule

Read the target path before pressing Enter on recursive deletion commands.

---

4.23 — Wildcards

The shell can expand wildcard patterns.

Example:

ls *.txt

means:

all filenames in this directory ending in .txt

Another example:

rm *.tmp

would remove all .tmp files in the current directory.

Wildcards are powerful, which means you should inspect matches before destructive use.

Safer pattern:

ls *.tmp

first.

Then, if correct:

rm *.tmp

---

4.24 — Quoting

Quoting becomes important when arguments contain spaces or shell-special characters.

Create:

mkdir "My Notes"

Without quotes:

mkdir My Notes

Bash interprets that as two directory names:

My
Notes

instead of one.

---

4.25 — Single Quotes vs Double Quotes

Double quotes allow environment-variable expansion.

Example:

echo "Home: $HOME"

might print:

Home: /home/alex

Single quotes generally preserve the text literally:

echo 'Home: $HOME'

prints:

Home: $HOME

This distinction matters constantly in shell commands and scripts.

---

4.26 — Command History

Press:

Up Arrow

to move through earlier commands.

Press:

Down Arrow

to move forward again.

For a short session, this is often enough.

But Omarchy provides something much better.

---

4.27 — Fuzzy History Search

Current Omarchy ships fzf.

Press:

Ctrl + R

You should get fuzzy history search.

Start typing part of an earlier command.

Example:

hyprctl

You can find previous commands containing that text without remembering the full syntax.

For developers, this quickly becomes one of the highest-value shortcuts in the terminal.

---

4.28 — Why Fuzzy History Matters

Suppose three days ago you ran:

omarchy network status --verbose

You vaguely remember:

network verbose

Press:

Ctrl + R

and search:

network

Instead of searching documentation again, you recover the exact command from your own history.

---

4.29 — fzf File Search

Current Omarchy provides fuzzy file finding using fzf.

The official shell-tools documentation exposes:

ff

as a fuzzy file finder.

Go to:

cd ~/Projects

Then:

ff

You should get an interactive finder with file previews.

Type parts of a filename to narrow results.

---

4.30 — Searching Filenames with fd

Current Omarchy includes fd, a friendlier alternative to traditional find for many everyday uses.

Return to:

cd ~/Projects/terminal-practice

Find files containing todo in their name:

fd todo

Find all text files:

fd '\.txt$'

---

4.31 — Hidden Files and fd

A useful gotcha:

fd does not necessarily include hidden files/directories in its default search.

To include hidden entries:

fd -H PATTERN

Example:

fd -H "config" ~

The current official Omarchy documentation explicitly shows -H when searching hidden directories.

This is important when searching:

~/.config

---

4.32 — Searching Inside Files with rg

ripgrep, invoked as:

rg

searches file contents.

Create a few sample files:

echo "TODO: learn ripgrep" > notes/search.txt
echo "DONE: learn pwd" > notes/done.txt

Search:

rg "TODO"

Expected result should point to:

notes/search.txt

---

4.33 — Search a Specific Directory

Example:

rg "TODO" notes/

Search your Hyprland config for workspace:

rg "workspace" ~/.config/hypr

This is a practical example from our real Omarchy learning journey.

---

4.34 — Case-Insensitive Search

Use:

rg -i "todo"

This can match:

TODO
Todo
todo

---

4.35 — Show Line Numbers

rg normally provides useful context automatically, but you can explicitly request line numbers:

rg -n "TODO"

This becomes especially useful when discussing results with an AI coding agent or another developer.

---

4.36 — Search Only Certain File Types

Example:

rg "function" -g '*.ts'

Search Lua files:

rg "o.bind" -g '*.lua' ~/.config/hypr

This is extremely useful in real codebases.

---

4.37 — Why rg Beats Manual Browsing

Imagine a project containing:

500 files

You need to find where:

runBacklog

is defined.

Do not open files one by one.

Run:

rg "runBacklog"

That is exactly the kind of codebase navigation workflow we want for this workstation.

---

4.38 — Pipes

A pipe sends the output of one command into another command.

The pipe character is:

|

Example:

omarchy commands --all | grep network

Conceptually:

omarchy commands --all
        ↓ output
grep network
        ↓ filtered output

---

4.39 — Pipe Example: Count Results

Search files:

fd

Pipe into:

wc -l

Combined:

fd | wc -l

This roughly counts the number of returned paths.

---

4.40 — Pipe Example: Search Command Output

You already used:

omarchy commands --all | grep -i hypr

This is a perfect practical example.

The first command produces a large list.

The second command filters it.

---

4.41 — Standard Output

Commands can produce normal output called:

stdout

Example:

echo "hello"

Output:

hello

---

4.42 — Standard Error

Commands can also produce error output:

stderr

For example:

ls /path/that/does/not/exist

The shell displays an error.

This distinction matters when redirecting output and when debugging scripts.

---

4.43 — Redirect Output to a File

Use:

>

Example:

omarchy version > version.txt

Inspect:

cat version.txt

Important:

>

overwrites the target file.

---

4.44 — Append Output

Use:

>>

Example:

echo "First line" > log.txt
echo "Second line" >> log.txt

Inspect:

cat log.txt

Result:

First line
Second line

---

4.45 — Why Redirection Matters

Redirection is useful for:

• saving diagnostics;
• generating reports;
• recording command output;
• building files;
• logging scripts.

Example:

hyprctl monitors all > monitor-info.txt

Now you can attach or inspect that file later.

---

4.46 — Redirecting Errors

Common shell syntax:

COMMAND 2>/dev/null

This discards standard error.

You saw this pattern in some Omarchy-related inspection commands.

Example:

grep -R "workspace" ~/.config/hypr /usr/share/omarchy/default/hypr 2>/dev/null

Use this intentionally.

Do not hide errors while troubleshooting unless you know why.

---

4.47 — /dev/null

/dev/null is a special device that discards anything written to it.

Think:

output
→ /dev/null
→ gone

Useful for:

• intentionally suppressing noise;
• optional probes;
• scripts where failure output is irrelevant.

Not useful when:

you actually need to understand the error.

---

4.48 — Running Commands Sequentially

You can place multiple commands on one line using:

;

Example:

pwd; ls

This runs:

pwd

then:

ls

even if the first command fails.

---

4.49 — Run the Next Command Only on Success

Use:

&&

Example:

mkdir test && cd test

cd test runs only if mkdir test succeeds.

This is extremely useful.

---

4.50 — Run the Next Command Only on Failure

Use:

||

Example:

test -f config.toml || echo "config.toml is missing"

This pattern appears frequently in shell scripts.

---

4.51 — Why && Is Safer Than ;

Compare:

cd important-directory; rm something

with:

cd important-directory && rm something

With ;, the removal command still executes if cd fails.

With &&, it runs only if the directory change succeeded.

For dependent operations, prefer:

&&

---

4.52 — Environment Variables in Commands

Example:

echo "$HOME"

Use an environment variable inside a path:

ls "$HOME/.config"

Quotes are generally a good habit around variables that may contain spaces.

---

4.53 — Temporary Environment Variable for One Command

You can set a variable only for one command:

EXAMPLE=value some-command

This is common in development.

For example:

NODE_ENV=production node app.js

The variable applies to that command invocation rather than permanently changing your shell.

---

4.54 — Inspect a Command with type

We covered this earlier, but it belongs in your daily terminal toolbox.

Run:

type ls

type cd

type python

type node

type omarchy

type tells you what Bash would actually execute.

---

4.55 — Why This Matters With Mise

Suppose:

python --version

returns a version you did not expect.

Run:

type python

The result may reveal that python is being provided by:

• system /usr/bin;
• mise;
• another wrapper;
• an alias.

This is much more useful than immediately reinstalling Python.

---

4.56 — Check Executable Location

If type reports an executable, you can inspect paths with:

command -v python

or:

which python

We prefer:

type python

as the first diagnostic because it understands aliases and functions too.

---

4.57 — Exit Codes

Commands report whether they succeeded.

Typically:

0
→ success

non-zero
→ some kind of failure

After a command, inspect the last exit code:

echo $?

Example:

true
echo $?

Expected:

0

Then:

false
echo $?

Expected non-zero.

---

4.58 — Why Silent Commands Can Be Fine

Some commands intentionally print nothing when successful.

This happened during our real Omarchy learning journey.

The absence of output does not automatically mean:

nothing happened

You may need to check:

• exit code;
• state afterwards;
• corresponding status command.

Example:

some-command
echo $?

This is an important troubleshooting habit.

---

4.59 — head and tail

Show the beginning of output:

COMMAND | head

Example:

omarchy commands --all | head

Show the end:

COMMAND | tail

Useful for large outputs and logs.

---

4.60 — Follow a Log

A common pattern is:

tail -f FILE

This follows new lines as they are appended.

You do not need it frequently yet, but it becomes useful for:

• app logs;
• development servers;
• service diagnostics.

Press:

Ctrl + C

to stop following.

---

4.61 — Ctrl + C

In the terminal:

Ctrl + C

usually sends an interrupt signal to the foreground process.

Use it to stop commands such as:

• development server;
• endless output;
• ping;
• tail -f;
• long-running CLI task.

It does not mean “copy” in the traditional terminal context.

Omarchy provides unified desktop copy/paste shortcuts at the compositor level, but understand that Ctrl + C still has its classic shell meaning inside terminal applications.

---

4.62 — Clear the Terminal

Use:

clear

or commonly:

Ctrl + L

This clears/redraws the terminal view without deleting shell history.

---

4.63 — Autocomplete and History Are More Important Than Typing Speed

A developer should rarely type repetitive full commands manually.

Use:

Tab
→ completion

Up Arrow
→ recent command

Ctrl + R
→ fuzzy history

zoxide
→ remembered directories

ff
→ fuzzy files

The goal is not to become a faster typist.

The goal is to type less.

---

4.64 — Zoxide

Current Omarchy ships zoxide as a smarter directory-jumping tool.

Zoxide learns directories you visit.

Suppose you visit:

cd ~/.config/omarchy

After zoxide has learned the path, you can often jump back using only a fragment.

Current official Omarchy documentation integrates zoxide so that remembered directory navigation becomes dramatically shorter.

Try visiting several directories normally first:

cd ~/.config/hypr
cd ~/Projects
cd ~/.config/omarchy

Then experiment with remembered fragments according to the current shell integration.

---

4.65 — Why Zoxide Matters

Without directory memory:

cd ~/Projects/client/backend/services/auth

every time.

With a learned directory:

jump using a small unique fragment

This adds up quickly during a development day.

---

4.66 — fd + rg + fzf: The Core Search Trio

A useful mental model:

fd
→ Where is the file?

rg
→ Where is the text?

fzf / ff
→ Let me interactively choose

Examples:

fd "config"

Find files.

rg "databaseUrl"

Find content.

ff

Interactively find and preview a file.

These three tools cover a huge percentage of everyday codebase navigation.

---

4.67 — bat + rg: Inspect Search Results

Search:

rg -n "workspace" ~/.config/hypr

Once you identify the relevant file:

bat ~/.config/hypr/hyprland.lua

This pattern is excellent:

search
→ identify file
→ inspect file
→ edit only if necessary

---

4.68 — Searching Command Output with rg

rg is primarily a file-content search tool, while standard tools such as grep are common for streams.

For large command output you will frequently see:

omarchy commands --all | grep -i network

Use whichever tool fits the input naturally.

The important concept is the pipe.

---

4.69 — Avoid sudo in Your Home Directory

You learned this in Module 2.

It deserves repetition because the terminal makes dangerous commands easy to type.

Do not edit:

~/.config/hypr/bindings.lua

with:

sudo nvim ...

under normal circumstances.

Your personal files should remain owned by your user.

Use sudo only when the operation genuinely requires system-level privileges.

---

4.70 — Your .bashrc

Your personal Bash customizations belong in:

~/.bashrc

The current official Omarchy dotfiles documentation specifically recommends putting your own:

• aliases;
• functions;
• exports;

in this file.

It is intended to survive Omarchy updates.

---

4.71 — Inspect .bashrc

Run:

bat ~/.bashrc

Your file may be intentionally small because Omarchy loads its defaults separately.

That is good.

Your file should represent your personal customizations, not a copy of all Omarchy shell internals.

---

4.72 — Add a Personal Alias

For example:

alias cproj='cd ~/Projects'

You could add this to:

~/.bashrc

Then reload:

source ~/.bashrc

Now:

cproj

would jump to your project directory.

Important

Do not add aliases merely because you can.

A good alias should reduce a repeated friction point.

---

4.73 — Add an Environment Variable

Example:

export EDITOR=nvim

could be placed in .bashrc if that is intentionally how you want tools to resolve the editor.

However, Omarchy already has its own default-editor integration.

Before adding environment overrides, check whether Omarchy already manages the setting you want.

This is the same principle throughout the course:

Use the Omarchy layer when it already solves the problem cleanly.

---

4.74 — Functions

A shell function can wrap several commands.

Example:

mkcd() {
  mkdir -p "$1" && cd "$1"
}

Then:

mkcd experiment

creates and enters the directory.

Functions become useful later for personal workflows and automation.

For now, understand the concept.

---

4.75 — Reloading Shell Configuration

After editing .bashrc, either open a new terminal or run:

source ~/.bashrc

source evaluates the file in the current shell.

You may also see shorthand:

. ~/.bashrc

Both forms are common.

---

4.76 — Do Not Edit Omarchy’s Internal Shell Files

You can inspect Omarchy’s shell defaults under:

/usr/share/omarchy

but your personal changes should go in:

~/.bashrc

The official Omarchy dotfiles guidance is clear that package-owned files under /usr/share/omarchy can be overwritten by updates.

This is the same upgrade-safe configuration strategy you learned with Hyprland.

---

4.77 — Environment Debugging Pattern

If a command behaves unexpectedly:

1. type COMMAND
2. command -v COMMAND
3. COMMAND --version
4. echo "$PATH"

Example:

type node
command -v node
node --version

This often reveals the problem without reinstalling anything.

---

4.78 — Working With Large Output

Do not let huge command output flood the terminal if you only need a small part.

Use:

COMMAND | head

or:

COMMAND | tail

or:

COMMAND | grep PATTERN

or save it:

COMMAND > output.txt

Then inspect:

bat output.txt

---

4.79 — Copying Commands Safely

When copying a command from documentation:

1. read it;
2. identify the command;
3. identify the paths;
4. identify flags;
5. look for sudo;
6. look for destructive commands such as rm;
7. only then execute.

Especially inspect:

rm
mv
chmod
chown
dd
mkfs
pacman
sudo

The terminal is powerful because it assumes you know what you asked it to do.

---

4.80 — Commands From AI Agents

AI coding agents can generate shell commands.

Treat them the same way as commands from a human tutorial.

Before execution:

What does it change?
Does it need sudo?
Which files does it touch?
Can it delete data?
Can I inspect first?

One of the reasons we are learning shell fundamentals is so you can judge AI-generated commands rather than blindly approving them.

---

4.81 — Practical Exercise: Navigate Without the File Manager

Starting from home:

cd

Do the following:

1. enter ~/Projects;
2. create terminal-practice-2;
3. enter it;
4. create src, docs, and tests;
5. create README.md;
6. display the directory tree;
7. return home.

Possible commands:

cd ~/Projects
mkdir terminal-practice-2
cd terminal-practice-2
mkdir src docs tests
touch README.md
lt
cd

---

4.82 — Practical Exercise: Search a Project

Inside a project repository, perform:

fd

Then:

rg "TODO"

Then:

rg -n "TODO"

Then:

ff

Your goal is to understand the different search experiences.

---

4.83 — Practical Exercise: Search Omarchy Configuration

Search your own Hyprland config:

rg "monitor" ~/.config/hypr

Then:

rg "bind" ~/.config/hypr

Search Omarchy’s defaults without editing them:

rg "Toggle scratchpad" /usr/share/omarchy

This demonstrates a powerful troubleshooting workflow.

---

4.84 — Practical Exercise: Build a Diagnostic File

Run:

{
  echo "=== Omarchy ==="
  omarchy version
  echo
  echo "=== Network ==="
  omarchy network status --verbose
  echo
  echo "=== Failed system services ==="
  systemctl --failed
} > diagnostic.txt

Inspect:

bat diagnostic.txt

You just combined:

• grouping;
• commands;
• redirection;
• diagnostics.

This is a useful real-world pattern.

---

4.85 — Practical Exercise: Fuzzy History

Run several commands:

omarchy version
hyprctl monitors all
omarchy network status --verbose
git --version
mise --version

Now press:

Ctrl + R

Search for:

network

Select the earlier network command.

Then repeat with:

monitor

This exercise is more important than it looks.

---

4.86 — Practical Exercise: Inspect Command Resolution

Run:

type ls
type cat
type bat
type fd
type rg
type python
type node
type omarchy

Write down which are:

• aliases;
• builtins;
• executable paths;
• wrappers.

Your exact results can vary by current Omarchy configuration.

That variation is part of the lesson.

---

4.87 — Practical Exercise: One Pipeline

Run:

omarchy commands --all | grep -i "restart"

Then:

omarchy commands --all | grep -i "network"

Then:

omarchy commands --all | grep -i "hyprland" | head -n 20

You are now chaining tools instead of manually scrolling through hundreds of lines.

---

4.88 — Five-Minute Terminal Challenge

Complete the following without a graphical file manager:

1. go to ~/Projects;
2. find a project directory using fd;
3. enter the project;
4. find every file containing config in its name;
5. search all files for the word TODO;
6. inspect one matching file with bat;
7. check Git status;
8. return to a previous command using Ctrl + R;
9. return home.

The objective is not speed.

It is fluency.

---

4.89 — Common Terminal Mistakes

---

Mistake 1 — Typing Everything Manually

Use:

• Tab completion;
• history;
• Ctrl + R;
• zoxide;
• ff.

The best command is often the command you do not have to retype.

---

Mistake 2 — Reaching for sudo Too Quickly

Permission errors are not automatically requests for root.

---

Mistake 3 — Using rm -rf Without Inspecting the Path

Recursive deletion can be irreversible.

---

Mistake 4 — Forgetting Quotes Around Paths With Spaces

Use:

cd "My Project"

not:

cd My Project

unless you actually mean two arguments.

---

Mistake 5 — Confusing > and >>

>
→ overwrite

>>
→ append

---

Mistake 6 — Thinking fd Searches Hidden Files Automatically

When hidden paths matter:

fd -H ...

---

Mistake 7 — Searching Files One by One

Use:

rg

for content and:

fd

for filenames.

---

Mistake 8 — Assuming ls Is Always Raw ls

On Omarchy, enhanced shell aliases may change what familiar commands resolve to.

Check:

type ls

---

Mistake 9 — Assuming Silent Output Means Failure

Check:

echo $?

or inspect the resulting state.

---

Mistake 10 — Editing Omarchy Internals for a Personal Shell Change

Use:

~/.bashrc

for your own aliases, exports, and functions.

Do not put normal personal changes inside package-owned /usr/share/omarchy files.

---

4.90 — Checkpoint

Before moving to Tmux, you should be able to answer yes to the following.

Terminal Basics

• I understand the difference between terminal emulator and shell.
• I can identify my shell.
• I can check the configured Omarchy terminal.
• I know how to get command help.

Navigation

• I can use pwd.
• I can use cd.
• I understand ~, ., and ...
• I use Tab completion.

Files

• I can create directories.
• I can create files.
• I can copy files.
• I can move/rename files.
• I understand the danger of rm -rf.

Omarchy Shell Tools

• I understand what eza provides.
• I can use lsa, lt, and lta.
• I can use bat.
• I can use fd.
• I know when fd -H matters.
• I can use rg.
• I can use ff/fzf.
• I can fuzzy-search history with Ctrl + R.
• I understand what zoxide does.
• I can use tldr.

Shell Composition

• I understand pipes.
• I understand >.
• I understand >>.
• I understand &&.
• I understand ||.
• I know what /dev/null does at a high level.

Environment

• I understand $PATH.
• I can inspect commands with type.
• I understand why command resolution matters with mise.
• I know where my personal Bash configuration belongs.

Safety

• I inspect destructive commands before running them.
• I do not use sudo automatically.
• I can recognize when an AI-generated command deserves extra inspection.

---

4.91 — What You Can Now Do

After completing Module 4, you can:

• operate comfortably inside the terminal;
• navigate without a graphical file manager;
• search large codebases quickly;
• inspect code and configuration cleanly;
• fuzzy-search files and history;
• jump around frequently used directories;
• chain tools using pipes;
• save command output;
• inspect command resolution;
• understand why runtime paths matter;
• customize Bash safely;
• read terminal commands rather than treating them as magic;
• evaluate commands suggested by documentation or AI agents more safely.

This is the foundation for nearly everything that follows:

• Tmux;
• Git;
• mise;
• coding agents;
• development servers;
• logs;
• automation;
• remote systems;
• recovery.

---

Module 4 Summary

Terminal stack:

Terminal emulator
→ Ghostty / Foot / Alacritty / Kitty

Shell
→ Bash

Commands
→ Linux + Omarchy + developer tools

Navigation:

pwd
cd
Tab

Directory inspection:

ls
lsa
lt
lta

Search:

fd
→ filenames

rg
→ file contents

ff / fzf
→ interactive fuzzy selection

Ctrl + R
→ fuzzy history

File inspection:

cat
→ raw/simple output

bat
→ developer-friendly viewing

Command composition:

|
→ pipe

>
→ overwrite output file

>>
→ append output

&&
→ next command on success

||
→ next command on failure

Command diagnosis:

type COMMAND
command -v COMMAND
COMMAND --version
echo "$PATH"

Personal shell configuration:

~/.bashrc

And the most important lesson:

The terminal becomes fast when you stop retyping, stop browsing manually, and start composing small tools.

---