Learn BASH Scripting - Loops Part 2: while, until & Reading Files

#Introduction

In episode 11 we mastered the for loop — from word lists, {1..10} ranges, to the C-style for ((i=0; i<10; i++)). In this episode we complete the loop arsenal with its partners: while and until.

for is like a factory sorter who knows exactly how many boxes will pass: it needs a complete list before starting. But many jobs don't know how many times they need to repeat before finishing — waiting for a service to come up, reading a file whose lines can grow, or waiting for a user to type the right answer. For these jobs, while and until are the right tools: they repeat while a condition holds, not while items remain.

This episode's biggest bonus: reading files line by line with while read. Almost every operational script — log parsers, configuration file processing, CSV handling — rests on this pattern. We'll also dissect one of Bash's most famous mysteries: why variables inside while often "disappear" after the pipeline finishes (the answer: subshell). Let's get started.

#Main Discussion

#while: Repeat While the Condition Is True

while is the most flexible loop. It evaluates a condition — any command or test — and as long as that condition returns exit status 0 (success), the do...done block keeps running:

count=0
while [ "$count" -lt 5 ]; do
    echo "Hitungan: $count"
    count=$((count + 1))
done

Reading the code above: "as long as $count is less than 5, print its value then add 1." Without the count=$((count + 1)) line, the condition would never change and you'd be stuck in an infinite loop. This is a classic mistake — the condition and the change to that condition are two things that must always coexist in a condition-based loop.

Think of while as a camp watchtower furnace: the fire is kept burning as long as there's wood ([ -n "$kayu" ]). Every iteration you check the wood, and when it runs out, the fire goes out. Bash itself evaluates the condition at the start of every iteration — before the block executes.

#until: Repeat Until the Condition Is True

until is the logical opposite of while — this isn't just cosmetic, it's a difference in how you think:

• while [ kondisi ] → run while the condition is true.
• until [ kondisi ] → run until the condition is true (stop as soon as it becomes true).

count=0
until [ "$count" -ge 5 ]; do
    echo "Masih di angka $count"
    count=$((count + 1))
done

In terms of results, the example above is identical to the while version. The difference is in readability: choose until when the stop condition is more natural to say than the continue condition. Imagine waiting for a user to answer "yes":

jawaban=""
until [ "$jawaban" = "ya" ]; do
    read -p "Konfirmasi (ketik 'ya'): " jawaban
done
echo "Dikonfirmasi!"

The mental reading: "keep asking until he answers yes." Far more readable than while [ "$jawaban" != "ya" ], which forces you to think in negation.

#The while true + break Pattern: Lightweight Daemon

There's one pattern hugely popular in daemon and watcher scripts: while true — a loop that never stops on its own, stopped explicitly via break from inside. This pattern fits when the stop condition is hard to write at the top of the loop (for example, when it depends on the result of the iteration's work):

while true; do
    if [ -f /tmp/stop-dengan-fresh ]; then
        echo "File penanda terdeteksi, berhenti."
        break
    fi
    echo "Menjalankan tugas rutin... (Ctrl+C untuk berhenti)"
    sleep 10
done

The true command is a Bash builtin that always returns exit status 0 — a condition that never becomes false, so the loop never stops on its own condition. Inside, break becomes the only deliberate way out. This pattern also often hosts continue to skip one cycle:

while true; do
    read -p "Perintah: " cmd
    case "$cmd" in
        next)   continue ;;
        quit)   break ;;
        *)      echo "Eksekusi: $cmd" ;;
    esac
done
echo "Selesai."

#Reading Files Line by Line

Now we get to the most important pattern in this episode. To process a file line by line, the standard formula is:

while read -r line; do
    echo "Baris: $line"
done < file.txt

Let's dissect each part:

1. while read -r line — each iteration, the read command takes one line from stdin and stores it in the line variable, then returns exit status 0 (successfully read). When the file runs out, read returns a non-zero status and the loop stops. The beauty of this pattern: the loop knows when to stop on its own, without counting lines.
2. done < file.txt — the input redirection attaches to done, not the start. This tells: "feed every line of file.txt as stdin for the read command inside the loop."

In fact, read is the key here — each iteration it consumes one line and moves the cursor to the next line. It's like a conveyor belt where you take one document each time until the stack runs out.

#Why read -r?

The -r option on read may seem trivial, but it saves you from a very subtle bug. Without -r, read treats backslash (\) as an escape character — a character that modifies the next character:

echo 'C:\data\server\logs.txt' > path.txt
 
read path < path.txt
echo "Tanpa -r : $path"
# Tanpa -r : C:dataserverlogs.txt   <- backslash hilang!
 
read -r path < path.txt
echo "Dengan -r: $path"
# Dengan -r: C:\data\server\logs.txt

Why does read without -r remove backslashes? Because read is designed to support line continuation — a backslash at the end of a line means "continue on the next line". Without -r, even backslashes in the middle of a line get digested. For real-world data — Windows paths, regex, escape sequences — backslash is valid data that must be preserved. The golden rule: always write read -r unless you have an explicit reason not to.

#IFS to Preserve Leading Spaces

There's a second, subtler trap: read by default strips spaces and tabs at the beginning and end of a line. That's because the default IFS (Internal Field Separator) contains space, tab, and newline. For files whose lines intentionally have leading spaces (for example, source code or indented output), use IFS= before read:

while IFS= read -r line; do
    echo ">>> $line <<<"
done < indentasi.txt

Note the writing: while IFS= read -r line — the IFS= assignment is directly on the same line as read. This is a one-command variable assignment (command assignment), which only applies to that single command. With an empty IFS, read doesn't trim any space characters from the line.

#Reading CSV: while IFS=',' read -r f1 f2

read's most commonly used strength in the real world is its ability to split one line into several fields at once. Just give read a list of variables — it divides the line based on IFS and fills each variable:

while IFS=',' read -r nama umur kota; do
    echo "Nama : $nama"
    echo "Umur : $umur"
    echo "Kota : $kota"
    echo "---"
done < data.csv

For each line like arman,30,jakarta, read splits it on commas and fills $nama=arman, $umur=30, $kota=jakarta. If a line has fewer fields than variables, the rest stay empty; if more, the last field holds the remainder.

A closer-to-DevOps example: the servers.csv file contains a list of servers and their roles, then the script pings them all:

while IFS=',' read -r host role; do
    if ping -c 1 -W 2 "$host" >/dev/null 2>&1; then
        echo "OK   : $host ($role)"
    else
        echo "FAIL : $host ($role)"
    fi
done < servers.csv

#The Subshell Mystery: Why Variables "Disappear" After a Pipeline

This is one of Bash's most famous mysteries and one that most often makes admins bang their heads against the wall. Try running this script:

total=0
cat data.txt | while read -r baris; do
    total=$((total + 1))
done
echo "Total baris: $total"   # output: Total baris: 0  <- BUG!

You expect total to hold the line count, but the output is 0. Why? Because every element in a pipeline (cat ... | while ...) runs in a subshell — a child Bash process with its own copy of the variables. The assignment total=$((total + 1)) happens in the subshell, and when the subshell finishes, all its changes are discarded. $total in the parent shell is never touched.

The analogy: you send a courier (subshell) carrying a notebook (variable copy). The courier writes down numbers, but the notebook he carries is a photocopy — once he leaves, the original notebook stays blank.

There are several solutions. The simplest: don't use a pipeline at all — use direct redirection:

total=0
while read -r baris; do
    total=$((total + 1))
done < data.txt
echo "Total baris: $total"

An alternative solution for certain cases — if you truly need a pipeline (for example, because another process filters the data), use process substitution or move the result into a variable with mapfile:

total=0
while read -r baris; do
    total=$((total + 1))
done < <(grep -v '^#' data.txt)
echo "Total: $total"
 
mapfile -t baris_baris < data.txt
echo "Jumlah baris: ${#baris_baris[@]}"

#Common Mistakes in while, until, and Reading Files

#Conclusion

In this episode 12 we completed Bash's loops with while (runs while a condition is true), until (runs until a condition is met), and the while true + break pattern for daemons and REPLs. More importantly, we mastered the most productive pattern in Bash scripting: while IFS= read -r line; do ...; done < file for reading files line by line, splitting CSV into fields with IFS=',', and revealed the subshell mystery — why variables changed in a pipeline "disappear" and how to avoid it.

The principle to take home: for for known lists, while/until for evaluated conditions, and always read -r (plus IFS= when needed) when touching data from files. With the combination of conditionals and loops, your scripts can now read, evaluate, and repeat — three core abilities of automation.

But there's one issue starting to be felt: your code is getting longer, and the same patterns (for example, "read file, filter, report") are starting to repeat in many places. In the next episode, episode 13, we'll discuss the solution: functions — how to wrap logic into reusable blocks, complete with local variables, arguments, and return values. That's where your scripts change from merely executing tasks to clean code architecture. See you in the next episode!