---

Mastering Bash Scripting: Build Your Own Grep from Zero to Hero

This guide provides a comprehensive walkthrough for building a simplified grep command using Bash scripting. You will learn to parse command-line arguments, handle flags (-n, -l, -i, -v, -x), read files line-by-line, and implement core text-matching logic, elevating your shell scripting skills from beginner to advanced.

Have you ever found yourself staring at a terminal, lost in a sea of log files, desperately trying to pinpoint a single error message? The standard Unix command grep is the life raft in this scenario, a powerful tool for searching text. But what if you could not only use it, but understand its inner workings so deeply that you could build your own version? This isn't just an academic exercise; it's a rite of passage for any serious Bash scripter. By recreating this fundamental utility, you will unlock a profound understanding of file I/O, argument parsing, and control flow in the shell. This guide will take you on that journey, transforming you from a command user into a command creator.

---

What is Grep and Why Build Your Own?

At its core, grep (which stands for Global Regular Expression Print) is a command-line utility for searching plain-text data sets for lines that match a regular expression or a fixed string. Its simplicity belies its power; developers, system administrators, and data scientists rely on it daily to filter logs, search codebases, and process data streams. It's the Swiss Army knife of text processing on Unix-like systems.

While the standard grep is a highly optimized program written in C, building a simplified version in Bash is an invaluable learning experience offered in the exclusive kodikra.com learning path. This project forces you to grapple with real-world scripting challenges that go beyond simple "Hello, World" examples. You'll master concepts that are directly applicable to writing robust automation scripts and command-line tools.

The Educational Value Proposition

• Argument Parsing: You will learn how to professionally handle command-line options (flags) and arguments, a crucial skill for creating user-friendly scripts.
• File I/O: This project provides hands-on experience with reading files efficiently and safely in Bash, avoiding common pitfalls.
• Algorithmic Thinking: You'll translate a set of requirements (the `grep` flags) into conditional logic within your script, honing your problem-solving abilities.
• Shell Mastery: You will gain a deeper appreciation for the tools the shell provides, such as loops, conditional statements, and string manipulation, solidifying your overall Bash proficiency.

By the end of this guide, you won't just have a script; you'll have a new level of confidence and competence in your ability to command the shell.

---

How a Grep-like Script Works: The Core Logic

Before we dive into the code, it's essential to understand the high-level logic. A custom grep script follows a clear, sequential process. It must first understand the user's request (the flags, the search pattern, and the files) and then systematically execute the search operation based on that request.

The entire operation can be broken down into a few logical phases: initialization, argument parsing, and the main processing loop. The script must be smart enough to handle various combinations of flags and correctly identify which arguments are flags, which is the pattern, and which are the files to be searched.

Here is a conceptual flowchart illustrating the script's journey from invocation to output:

    ● Start
    │
    ▼
  ┌───────────────────────┐
  │ Initialize Variables  │
  │ (flags, counters)     │
  └──────────┬────────────┘
             │
             ▼
  ┌───────────────────────┐
  │ Parse Flags (-n, -i)  │
  │ using getopts         │
  └──────────┬────────────┘
             │
             ▼
  ┌───────────────────────┐
  │ Isolate Search Pattern│
  │ and File List         │
  └──────────┬────────────┘
             │
             ▼
  ┌─ For each File in List ─┐
  │          │              │
  │          ▼              │
  │   ┌─ While read Line ─┐ │
  │   │        │          │ │
  │   │        ▼          │ │
  │   │   Apply Flag Logic│ │
  │   │   (case, invert)  │ │
  │   │        │          │ │
  │   │        ▼          │ │
  │   │  ◆ String Match? ◆│ │
  │   │   ╱           ╲   │ │
  │   │ Yes           No  │ │
  │   │  │              │ │ │
  │   │  ▼              ▼ │ │
  │   │[Print Output]  [Continue]│ │
  │   │                         │ │
  │   └─────────────────────────┘ │
  │                             │
  └────────────┬────────────────┘
               │
               ▼
            ● End

This flow demonstrates the nested nature of the problem. We have an outer loop for the files and an inner loop for the lines within each file. The core matching logic is executed inside the innermost loop, where all the flag conditions are evaluated for every single line.

---

The Essential Bash Toolkit for Building Grep

To construct our script, we'll rely on several built-in Bash features and commands. Understanding these tools is the key to writing clean, efficient, and correct code. This isn't just a random collection of commands; it's a curated set of instruments perfect for the task at hand.

Key Bash Constructs

• getopts: This is the standard, POSIX-compliant shell builtin for parsing command-line options (flags). It's far more robust than manually checking $1, $2, etc., as it correctly handles clustered flags (like -ni) and flags that might appear in any order.
• shift: This command is the perfect partner to getopts. After getopts has processed all the flags, shift is used to discard them from the list of positional parameters, leaving only the non-option arguments (our search pattern and file names) for easy access.
• while read -r line: This is the canonical, safest way to read a file line by line in Bash. Using a for loop to read lines can cause issues with word splitting and globbing, while this `while` loop construct processes each line exactly as it appears. The -r option prevents backslash interpretation.
• case Statements: A case statement is a clean and readable way to handle multiple conditions, making it ideal for managing the logic of our different `grep` flags. It's a much more elegant solution than a long chain of if-elif-else blocks.
• Parameter Expansions: We will use Bash's parameter expansion capabilities for tasks like case-insensitive matching. For example, ${string,,} converts a string to all lowercase, providing a simple way to implement the -i flag.
• Positional Parameters ($1, $@, $#): These special variables are fundamental to any script that accepts arguments. $1 is the first argument, $@ represents all arguments as separate strings, and $# gives the total count of arguments.

---

Step-by-Step Implementation: The Bash Grep Script

Now, let's synthesize our understanding of the logic and tools into a complete, working script. The following code is a robust implementation of our simplified grep command. It is heavily commented to explain the purpose of each section and command, serving as a learning resource in itself.

The Complete Source Code

#!/bin/bash

# A script to mimic the basic functionality of the grep command.
# This is part of the exclusive curriculum from kodikra.com.

# --- Variable Initialization ---
# Flags are set to 0 (false) by default. They will be set to 1 (true) if the corresponding option is passed.
FLAG_N=0 # Print line number
FLAG_L=0 # Print file name only
FLAG_I=0 # Case-insensitive search
FLAG_V=0 # Invert match (select non-matching lines)
FLAG_X=0 # Match entire line only

# --- Argument Parsing with getopts ---
# getopts is a shell builtin that parses command-line options.
# The string "nlivx" tells getopts which options to look for.
# The loop continues as long as getopts finds options.
while getopts "nlivx" opt; do
  case ${opt} in
    n) FLAG_N=1 ;;
    l) FLAG_L=1 ;;
    i) FLAG_I=1 ;;
    v) FLAG_V=1 ;;
    x) FLAG_X=1 ;;
    *) 
      echo "Usage: $0 [-nlivx] PATTERN FILE..." >&2
      exit 1
      ;;
  esac
done

# --- Isolate Pattern and Files ---
# shift consumes the options that getopts has already processed.
# OPTIND is a variable managed by getopts that holds the index of the next argument to be processed.
# By shifting OPTIND-1 times, we remove all options from the positional parameters.
shift $((OPTIND - 1))

# After shifting, the first remaining argument is the search pattern.
PATTERN="$1"
shift # Shift again to remove the pattern, leaving only the file names.

# The rest of the arguments are the files to be searched.
FILES=("$@")

# --- Main Processing Logic ---
# Check if there are multiple files to decide if filenames should be prefixed.
MULTIPLE_FILES=0
if [[ ${#FILES[@]} -gt 1 ]]; then
  MULTIPLE_FILES=1
fi

# Loop through each file provided as an argument.
for FILE in "${FILES[@]}"; do
  LINE_NUMBER=0
  FILE_MATCHED=0 # A flag to track if a match has been found in the current file (for -l)

  # Read the file line by line. This is the most robust way to process files in Bash.
  while IFS= read -r LINE; do
    ((LINE_NUMBER++))

    # --- Prepare strings for comparison based on flags ---
    SEARCH_LINE="$LINE"
    SEARCH_PATTERN="$PATTERN"
    
    # If -i (case-insensitive) flag is set, convert both line and pattern to lowercase for comparison.
    if [[ $FLAG_I -eq 1 ]]; then
      SEARCH_LINE="${LINE,,}"
      SEARCH_PATTERN="${PATTERN,,}"
    fi

    # --- Core Matching Logic ---
    MATCH_FOUND=0
    # If -x (exact match) flag is set, check for full string equality.
    if [[ $FLAG_X -eq 1 ]]; then
      if [[ "$SEARCH_LINE" == "$SEARCH_PATTERN" ]]; then
        MATCH_FOUND=1
      fi
    # Otherwise, check if the pattern is a substring of the line.
    else
      if [[ "$SEARCH_LINE" == *"$SEARCH_PATTERN"* ]]; then
        MATCH_FOUND=1
      fi
    fi

    # If -v (invert match) flag is set, flip the result of the match.
    if [[ $FLAG_V -eq 1 ]]; then
      MATCH_FOUND=$((1 - MATCH_FOUND)) # Toggles 1 to 0 and 0 to 1
    fi

    # --- Output Generation ---
    if [[ $MATCH_FOUND -eq 1 ]]; then
      # If -l (files with matches) flag is set, print the filename and break the inner loop.
      if [[ $FLAG_L -eq 1 ]]; then
        echo "$FILE"
        FILE_MATCHED=1
        break # No need to search the rest of this file
      fi

      # Prepare the output prefix (filename if multiple files)
      PREFIX=""
      if [[ $MULTIPLE_FILES -eq 1 ]]; then
        PREFIX="${FILE}:"
      fi

      # If -n (line number) flag is set, add it to the prefix.
      if [[ $FLAG_N -eq 1 ]]; then
        PREFIX="${PREFIX}${LINE_NUMBER}:"
      fi

      # Print the final formatted output.
      echo "${PREFIX}${LINE}"
    fi
  done < "$FILE" # Redirect the file content into the while loop.
done

Detailed Code Walkthrough

Let's dissect the script piece by piece to understand its mechanics.

1. Initialization and Flag Parsing

We begin by initializing variables for our flags (FLAG_N, FLAG_L, etc.) to 0, representing a "false" state. The while getopts "nlivx" opt loop is the heart of our argument parsing. For each valid flag it finds on the command line, it executes the corresponding case, setting the flag variable to 1 ("true"). This is an elegant and scalable way to handle options.

2. Argument Shifting

The line shift $((OPTIND - 1)) is crucial. The getopts command keeps track of its progress in the $OPTIND variable. After the loop finishes, $OPTIND points to the first non-option argument. We use shift to discard all the processed options, so that $1 now reliably holds the search pattern, and $@ holds the list of files.

3. The Main File Loop

The script then iterates through each file name in the FILES array using a for loop. Inside this loop, we reset a LINE_NUMBER counter for each new file. We also determine if we are searching multiple files to decide whether to prefix output lines with the filename, mimicking the behavior of the real `grep`.

4. The Line-by-Line Reading Loop

The while IFS= read -r LINE construct is the safest and most efficient way to read a file line by line in Bash. The file's content is redirected into this loop using < "$FILE". For each line read, we increment our LINE_NUMBER counter.

5. Applying Flag Logic

This is where the script's intelligence lies. Before performing the comparison, we check our flag variables. If FLAG_I is active, we convert both the current line and the search pattern to lowercase. This ensures the subsequent comparison is case-insensitive. This pre-processing step simplifies the final matching logic.

The following ASCII diagram illustrates this conditional logic flow for each line processed:

    ● Start Line Processing
    │
    ▼
  ┌──────────────────┐
  │ Read line, inc # │
  └─────────┬────────┘
            │
            ▼
    ◆ Flag -i set? ◆
   ╱                ╲
 Yes                  No
  │                   │
  ▼                   ▼
[Line & Pattern       [Use original
 to lowercase]        Line & Pattern]
  │                   │
  └────────┬──────────┘
           │
           ▼
    ◆ Flag -x set? ◆
   ╱                ╲
 Yes                  No
  │                   │
  ▼                   ▼
[Check for exact     [Check for substring
 line match]          match]
  │                   │
  └────────┬──────────┘
           │
           ▼
    ◆ Flag -v set? ◆
   ╱                ╲
 Yes                  No
  │                   │
  ▼                   ▼
[Invert match        [Keep match
 result]              result]
  │                   │
  └────────┬──────────┘
           │
           ▼
    ◆ Match is True? ◆
   ╱                ╲
 Yes                  No
  │                   │
  ▼                   ▼
[Format & Print]     [Do Nothing]
  │
  ▼
 ● End Line Processing

6. Matching and Output

The core comparison happens here. If FLAG_X is set, we use [[ "$SEARCH_LINE" == "$SEARCH_PATTERN" ]] for an exact match. Otherwise, we use globbing [[ "$SEARCH_LINE" == *"$SEARCH_PATTERN"* ]] to check for a substring. The result is stored in MATCH_FOUND. The FLAG_V logic is a clever trick: $((1 - MATCH_FOUND)) flips a 1 to a 0 and a 0 to a 1, effectively inverting the match result.

Finally, if a match is confirmed, the script constructs and prints the output. It checks for the -l flag first, which allows it to print the filename and immediately break from the inner loop for efficiency. If not, it builds the output string by conditionally adding prefixes for the filename (if multiple files) and the line number (if -n is set) before printing the original line content.

---

Putting It to the Test: How to Use Your Custom Grep

To use your script, save the code above into a file named mygrep.sh, make it executable, and then run it from your terminal.

First, make the script executable:

chmod +x mygrep.sh

Next, let's create some sample files to search through.

# Create file1.txt
cat > file1.txt << EOL
Hello world
This is a test file.
Bash scripting is fun.
Another line with hello.
EOL

# Create file2.txt
cat > file2.txt << EOL
The quick brown fox.
Jumps over the lazy dog.
HELLO WORLD, case matters.
EOL

Example Commands and Outputs

1. Basic Search
Search for "hello" in file1.txt.

./mygrep.sh "hello" file1.txt

Output:

Another line with hello.

2. Case-Insensitive Search (-i)
Search for "hello" in both files, ignoring case.

./mygrep.sh -i "hello" file1.txt file2.txt

Output:

file1.txt:Hello world
file1.txt:Another line with hello.
file2.txt:HELLO WORLD, case matters.

3. Line Number and Inverted Match (-n, -v)
Show all lines in file1.txt that *do not* contain "hello", with line numbers.

./mygrep.sh -n -v "hello" file1.txt

Output:

1:Hello world
2:This is a test file.
3:Bash scripting is fun.

4. List Files with Matches (-l)
Show only the names of files containing "world" (case-insensitive).

./mygrep.sh -li "world" file1.txt file2.txt

Output:

file1.txt
file2.txt

5. Exact Line Match (-x)
Find lines that are exactly "Hello world".

./mygrep.sh -x "Hello world" file1.txt

Output:

Hello world

---

Pros and Cons of a Custom Bash Grep

Building your own tools in Bash is empowering, but it's also important to understand the trade-offs compared to using native, compiled utilities.

Pros (Advantages)	Cons (Disadvantages)
Deep Educational Value	Performance
The primary benefit is learning. You gain an intimate understanding of shell scripting, argument parsing, and file handling.	Bash is an interpreted language. This script will be significantly slower than the native `grep` (written in C) on large files.
Zero Dependencies	Limited Features
The script runs on any system with a standard Bash shell, requiring no compilation or installation of external libraries.	This implementation lacks powerful features like regular expressions (regex), context control (`-A`, `-B`), or recursive directory searching.
Full Customizability	Error Handling
You have complete control. You can easily add new, custom flags or modify behavior to suit a specific, niche purpose.	A production-grade tool has extensive error handling (e.g., for file permissions, binary files). This script is more simplistic.

---

Frequently Asked Questions (FAQ)

Why is my script so much slower than the real `grep`?

The standard grep is a compiled program written in the C programming language, which runs directly on the machine's processor. Bash is an interpreted language, meaning each line of the script is read, parsed, and executed by the Bash interpreter at runtime. This interpretation layer adds significant overhead, especially inside loops that process large files, making it inherently slower than a compiled binary.

How could I add basic regular expression support?

You could replace the globbing match [[ "$SEARCH_LINE" == *"$SEARCH_PATTERN"* ]] with Bash's regex match operator: [[ "$SEARCH_LINE" =~ $SEARCH_PATTERN ]]. However, this only supports Extended Regular Expressions (ERE) and doesn't handle the complexities and different regex flavors that the real `grep` does. Implementing full PCRE compatibility would be a monumental task in pure Bash.

What is the difference between `getopts` and `getopt`?

getopts is a shell builtin, meaning it's part of Bash itself. It is POSIX-compliant and generally safer to use. getopt is an external program, and its behavior can vary between systems (e.g., GNU `getopt` vs. BSD `getopt`). While more powerful (it can handle long options like --invert-match), it's more complex to use correctly and less portable. For shell scripts, getopts is the standard recommendation.

Why use `while read -r line` instead of a `for` loop?

Using for line in $(cat file) is a common beginner mistake. The command substitution $(cat file) reads the entire file into memory at once, which is inefficient for large files. More importantly, it performs word splitting based on spaces, tabs, and newlines, which will break lines containing multiple spaces. The while read -r line construct reads one line at a time and, with IFS= and -r, preserves whitespace and backslashes, making it the most reliable method.

How can I make the script handle standard input (stdin) like the real `grep`?

You would add a condition at the beginning to check if the file list is empty. If it is, you would run your `while read` loop without the file redirection, causing it to read from standard input. This would allow you to pipe data into your script, for example: ls -l | ./mygrep.sh "txt".

What does the `shift $((OPTIND-1))` command actually do?

getopts uses a variable called OPTIND to keep track of the index of the next argument to process. After it has parsed all the flags (e.g., -n -i), OPTIND will point to the first non-flag argument (the pattern). If OPTIND is 3, it means the first two arguments were flags. shift $((3-1)) becomes shift 2, which discards the first two positional parameters ($1 and $2), making the old $3 the new $1.

Is it possible to search directories recursively?

While not included in this script, you could achieve this by wrapping the core logic in a function and using the find command. For example: find . -type f -exec ./mygrep.sh "pattern" {} +. Integrating this logic directly into the script would involve checking if a file argument is actually a directory and, if so, recursively calling the search logic for its contents.

---

Conclusion: From User to Creator

You have successfully journeyed from concept to a fully functional command-line tool. By building your own grep, you've done more than just replicate a command; you've demystified the process of shell scripting. You now possess a practical understanding of argument parsing, file processing loops, conditional logic, and output formatting—the very building blocks of powerful automation scripts.

This project is a testament to the idea that the best way to learn a system is to build a piece of it. The skills you've honed here are not confined to this single script; they are foundational principles that will serve you in every future Bash project you undertake. Continue to experiment, add new features, and refine your code.

Technology Disclaimer: The solution provided is compatible with Bash version 4.0 and higher. The parameter expansion ${string,,} for lowercasing was introduced in Bash 4.0.

Ready for your next challenge? Continue your journey on our Bash 5 learning path to tackle even more advanced projects. To review the fundamentals or explore other concepts, see the complete Bash guide on kodikra.com.

---

Published by Kodikra — Your trusted Bash learning resource.