Writing Bash Scripts With If-Then Statements: Practical Examples

When a Bash script ignores a bad filename, overwrites the wrong directory, or keeps running after a failed command, the problem is usually the same: missing conditional logic. bash if then statements are the basic control structure that lets scripts make decisions instead of blindly executing line after line. If you write Bash scripting for admin tasks, Linux automation, or any kind of workflow cleanup, this is the part you need to get right first.

This article walks through the core syntax, the test command, bracket styles, string and number comparisons, file checks, exit status handling, and practical script patterns you can use immediately. It also covers how conditionals fit into shell programming tutorials that go beyond toy examples and into real work: validating input, branching on command success, checking permissions, and controlling multi-step jobs.

If you are working through the CompTIA N10-009 Network+ Training Course, these patterns also help with common networking tasks like verifying reachability, checking service status, and automating prep steps before a change window. That matters because good automation is not just about speed. It is about making the script behave safely when something is missing, misconfigured, or down.

Understanding If-Then Syntax In Bash

The basic if-then structure in Bash is simple, but the details matter. A condition is evaluated, and if that condition succeeds, the script runs the commands inside the block. Bash does not need curly braces for this structure; it uses keywords like if, then, and fi to mark the beginning and end.

if command_or_test
then
    echo "Condition met"
fi

That block has four pieces. if starts the decision. The test condition follows. then begins the commands to run when the condition succeeds. fi closes the block. Indentation is optional for Bash, but it is essential for humans. A script that is indented consistently is easier to debug and much easier to hand off to another admin.

Bash conditions are evaluated by exit status, not by returning true or false objects the way some programming languages do. In Bash, an exit status of 0 means success, and anything non-zero means failure. That is why this works:

if ping -c 1 8.8.8.8 > /dev/null 2>&1
then
    echo "Network is reachable"
fi

Nested if statements are useful when one check depends on another. For example, you might verify that a directory exists first, then check whether a config file inside that directory is readable. That keeps the logic specific and avoids running deeper checks against missing paths.

Good Bash scripts are decision trees, not command dumps. The earlier you check a condition, the fewer bad actions your script can take later.

For official shell behavior and command semantics, the GNU Bash Reference Manual is the right source to keep nearby: GNU Bash Manual.

Testing Conditions With The Test Command And Brackets

The test command is one of the standard ways to evaluate conditions in Bash. The bracket form, [ ], is just a more familiar syntax for the same idea in many scripts. Both are common in shell scripting, and both can evaluate strings, numbers, files, and command results.

if test -f /etc/hosts
then
    echo "File exists"
fi

if [ -f /etc/hosts ]
then
    echo "File exists"
fi

Single brackets, [ ], are portable across older POSIX shells. Double brackets, [[ ]], are a Bash feature and usually safer for modern Bash scripting because they reduce word-splitting problems and support more flexible pattern matching. If you are writing scripts that will stay in Bash, [[ ]] is often the better default.

if [[ -n "$user_input" ]]
then
    echo "Input provided"
fi

Quoting variables matters. Without quotes, a variable containing spaces can break your test into multiple words. That can cause syntax errors or logic bugs that are hard to trace.

Here are three common examples:

• Empty string check: [ -z "$name" ]
• File exists: [ -e "$path" ]
• Number threshold: [ "$count" -ge 10 ]

Common mistakes are usually small but painful. Missing spaces inside brackets, such as [[-z "$name"]], will fail. Forgetting to quote variables can break tests when data contains spaces, wildcard characters, or empty values. If you have ever seen a script work perfectly in testing and then fail in production, this is often why.

For shell syntax and portable scripting guidance, the POSIX Shell Command Language is a useful reference: The Open Group POSIX Shell.

Comparing Strings In Bash

String comparisons are one of the most common uses of bash if then. You use them to validate usernames, check environment names, confirm yes-or-no answers, and branch based on text input. String operators compare text literally unless you intentionally use pattern matching.

if [[ "$environment" = "production" ]]
then
    echo "Running production settings"
fi

if [[ "$answer" != "yes" ]]
then
    echo "Aborting"
fi

The -z operator checks whether a string is empty. The -n operator checks whether a string is non-empty. Both are handy for input validation and for catching unset or blank variables before a script goes further.

if [[ -z "$username" ]]
then
    echo "Username is required"
    exit 1
fi

String comparison is case-sensitive by default. That means Production and production are different values. If you want to normalize user input, convert it first with parameter expansion or a tool like tr.

choice=$(echo "$choice" | tr '[:upper:]' '[:lower:]')

Lexicographic comparison matters when you are comparing text values that should sort in a certain order, such as version labels, hostnames, or environment tags. It is not numeric comparison. "9" is not greater than "10" in string logic the way a human might expect. That is why choosing the right operator matters.

String Equality	Use case: exact match for names, flags, or responses
String Emptiness	Use case: required input checks before continuing

A practical example is a prompt that asks for a maintenance environment. If the user types anything other than dev, stage, or prod, your script can reject the input and stop. That is safer than guessing.

For broader Linux command reference, the Bash built-in help and man pages are worth using directly: Bash Reference Manual and the man page behavior covered by your local ls man page and other system manuals. If you need a quick refresher on general file and text tools, the GNU coreutils documentation is also useful.

Comparing Numbers In Bash

Numeric comparisons in Bash use different operators than strings. That is a common source of errors in new scripts. If you compare numbers with string operators, you can get incorrect results, especially once values move past single digits.

The core numeric operators are straightforward:

• -eq equal to
• -ne not equal to
• -lt less than
• -le less than or equal to
• -gt greater than
• -ge greater than or equal to

if [[ "$retries" -ge 3 ]]
then
    echo "Retry limit reached"
fi

These operators are useful for thresholds, counters, scores, packet-loss limits, disk checks, and aging logic. For example, a script might stop after three failed pings, or it might warn when free space drops below 10 percent. That is where bash if then becomes practical instead of theoretical.

Before doing arithmetic comparisons, guard against non-numeric input. A blank string, a hostname, or a typo can make the test fail in unpredictable ways. One common pattern is to validate the input with a regular expression first.

if [[ "$count" =~ ^[0-9]+$ ]]
then
    if [[ "$count" -gt 10 ]]
    then
        echo "Count is above threshold"
    fi
else
    echo "Count is not numeric"
fi

A typical mistake is using string comparison for numbers:

if [[ "$count" > 10 ]]
then
    echo "Wrong for numeric checks"
fi

That compares alphabetically, not mathematically. It may appear to work for small test cases and then fail later. For admin scripts, especially those tied to monitoring or network checks in the CompTIA N10-009 Network+ Training Course, this is the kind of bug that turns a useful check into a false alert.

For standards-based numeric and scripting behavior, the Bash manual and POSIX documentation remain the best references. If you are doing threshold logic around security or compliance tasks, NIST guidance and vendor documentation often define the actual limits you should encode in scripts.

Checking Files And Directories

File checks are where Linux automation starts to feel real. Scripts often need to verify that a config file exists, that a log file is writable, or that an output directory is available before writing anything. Bash gives you direct tests for those cases.

if [[ -f "/etc/myapp.conf" ]]
then
    echo "Config file exists"
fi

if [[ -d "$backup_dir" ]]
then
    echo "Backup directory exists"
fi

Useful file tests include existence, readability, writability, executability, and path type. A regular file is not the same thing as a directory. A path can exist but still be unusable if permissions block access. That is why checking the path alone is not enough.

• -e: path exists
• -f: regular file exists
• -d: directory exists
• -r: readable
• -w: writable
• -x: executable

One practical pattern is creating a directory only if it does not already exist:

if [[ ! -d "$output_dir" ]]
then
    mkdir -p "$output_dir"
fi

That prevents errors and keeps the script idempotent. You can run it more than once without breaking the environment. That is especially important in backup scripts, deployment scripts, and scheduled jobs.

If you are testing system paths, command docs and Linux manuals are your friend. For example, the GNU coreutils docs and local man pages explain how ls, chmod 600, and directory permissions interact. For permissions and access controls, official vendor docs from Microsoft Learn and Linux documentation often provide the clearest operational examples.

Using If-Then With Command Exit Status

Most Bash commands communicate success or failure with an exit code. A zero exit code means the command succeeded. A non-zero exit code means something went wrong. This is one of the most important ideas in shell scripting, because it lets you turn almost any command into a condition.

if ping -c 1 192.0.2.10 > /dev/null 2>&1
then
    echo "Host is reachable"
else
    echo "Host is unreachable"
fi

This pattern is useful with grep, curl, systemctl, ssh, and many other commands. For example, you can check whether a service is active, whether a log entry exists, or whether an HTTP endpoint returns a usable response. When the command succeeds, the script continues. When it fails, you can log the failure or stop the workflow.

if systemctl is-active --quiet nginx
then
    echo "Nginx is running"
else
    echo "Nginx is not running"
    exit 1
fi

Branching on failure is just as important as branching on success. If a dependency is missing, your script can trigger fallback behavior, alert the operator, or exit cleanly instead of failing later in a more confusing way.

Exit status is the contract between commands and scripts. If you ignore it, your automation is guessing.

Logging makes this pattern much more useful. A short message tied to each branch tells the person reading the logs exactly which decision was made and why. For operations work, especially in network validation or service checks, that clarity saves time during incident response.

Official service and command behavior documentation from system vendors is the right place to confirm command options. For Linux service checks, distro documentation and systemd documentation are practical references.

Adding Else And Elif For Multiple Paths

The else clause gives an if block a default path. If the condition is not met, the script does something else instead of just stopping silently. The elif keyword adds another test, which lets you chain decisions without nesting every branch inside another block.

if [[ "$environment" = "dev" ]]
then
    echo "Loading development settings"
elif [[ "$environment" = "stage" ]]
then
    echo "Loading staging settings"
elif [[ "$environment" = "prod" ]]
then
    echo "Loading production settings"
else
    echo "Unknown environment"
    exit 1
fi

This is a common real-world pattern. A deployment script may need different configs for development, staging, and production. A backup script may need different retention rules based on whether it is running on a test host or a production host. bash if then becomes a control panel for those decisions.

For many branches based on a single value, a case statement can be cleaner than a long elif chain. Still, if and elif are often better when you need to combine multiple tests, like checking both a value and a file state. The main goal is readability. If someone else has to maintain your script at 2 a.m., simple is better than clever.

else	Use case: default behavior when a condition is not met
elif	Use case: one of several mutually exclusive paths

For automation tied to enterprise controls, this structure is often used alongside compliance logic. For example, NIST guidance may define a required action when a service fails or when a port should not be open. The actual decision tree belongs in the script, but the policy should come from the authoritative source.

Practical Script Examples

The fastest way to learn shell programming tutorials is to build small scripts that solve real problems. Below are practical examples that combine the condition patterns covered so far. They are short on purpose, but each one uses the same logic you would use in larger automation jobs.

Input Validation Script

#!/usr/bin/env bash

if [[ -z "$1" ]]
then
    echo "Usage: $0 <username>"
    exit 1
fi

username="$1"
echo "Proceeding with user: $username"

This script refuses to continue if the required argument is missing. That one check prevents a lot of bad behavior later. In production scripts, this pattern is often the first line of defense against accidental misuse.

Backup Script With File And Permission Checks

#!/usr/bin/env bash

source_file="/var/log/syslog"
destination_dir="/backup"

if [[ -f "$source_file" && -w "$destination_dir" ]]
then
    cp "$source_file" "$destination_dir/"
    echo "Backup completed"
else
    echo "Backup failed: check source file and destination permissions"
    exit 1
fi

This combines a file check with a writeability check. It avoids trying to copy a file into a directory the script cannot use. For scheduled backups, that is the difference between a clean run and a silent failure.

System Check Script

#!/usr/bin/env bash

if ping -c 1 8.8.8.8 > /dev/null 2>&1
then
    echo "Network reachable"
else
    echo "Network check failed"
fi

if systemctl is-active --quiet sshd
then
    echo "SSHD is active"
else
    echo "SSHD is not active"
fi

This kind of script is common before maintenance windows. You check network connectivity, then verify a service state before making changes. That is basic operational hygiene, and it maps well to the troubleshooting mindset used in network administration.

User Prompt Menu

#!/usr/bin/env bash

read -r -p "Choose dev, stage, or prod: " env

if [[ "$env" = "dev" ]]
then
    echo "Starting dev workflow"
elif [[ "$env" = "stage" ]]
then
    echo "Starting stage workflow"
elif [[ "$env" = "prod" ]]
then
    echo "Starting prod workflow"
else
    echo "Invalid choice"
    exit 1
fi

This is a simple but realistic menu pattern. It turns free-form user input into controlled branches. That reduces mistakes and keeps the script aligned with the options you actually support.

For Linux file handling and command behavior, official documentation from Red Hat and the GNU Bash manual are reliable references. If you want to understand how these checks fit into broader systems work, the CompTIA N10-009 Network+ Training Course is a practical place to connect scripting to troubleshooting and service validation.

Best Practices For Reliable Bash Conditionals

Reliable Bash conditionals are less about advanced syntax and more about discipline. The first rule is simple: quote your variables unless you have a specific reason not to. Quoting protects against spaces, blanks, and globbing issues. It is one of the easiest habits to build and one of the most valuable.

Use [[ ]] for modern Bash scripts whenever portability to older shells is not a requirement. It handles many parsing edge cases better than [ ]. That said, if the script needs to run in a strict POSIX environment, use the syntax that environment supports.

Break complex conditions into smaller checks or helper functions. A single line packed with six conditions may look efficient, but it is harder to debug and easier to break. Clear branching is better than compressed branching.

1. Check whether the input exists.
2. Validate its format.
3. Confirm the file or command state.
4. Take action only after the prerequisites pass.

Tools matter too. ShellCheck is extremely useful for catching syntax problems, unquoted variables, and logic issues before they become outages. If you write a lot of Bash scripting, it should be part of your normal review process.

Finally, make your error messages specific and use meaningful exit codes. “Something went wrong” is not enough. Tell the user what failed, what the script expected, and whether they can retry. That is the difference between a script people trust and one they work around.

For guidance on scripting quality and secure coding practices, ShellCheck is a widely used static analysis tool, and the CIS Benchmarks are helpful when your scripts touch system hardening or permission checks like chmod 600.

Debugging If-Then Statements In Bash

When an if-then statement does not behave the way you expect, the first step is to see what Bash is actually running. set -x prints commands as they execute, which helps you trace branch selection and variable expansion. It is one of the fastest ways to understand a bad conditional.

set -x
if [[ "$status" = "ready" ]]
then
    echo "Proceeding"
fi
set +x

Simple echo statements are also useful. Print the variable before the test so you know whether it contains what you think it contains. Many “broken” conditions are really data problems. The variable is blank, has trailing spaces, or contains a value from the wrong source.

Syntax errors are usually easy to name once you know what to look for:

• Missing fi: the block never closes
• Unmatched brackets: [ or [[ not properly closed
• Misplaced then: keyword on the wrong line or after a malformed test
• Missing spaces: especially inside [ ]

Test scripts incrementally. Do not build a 200-line script and wait until the end to run it. Check one conditional block at a time. That is how you isolate where the logic goes wrong.

If a condition always fails, inspect the data before you inspect the syntax. The problem is often the value, not the comparison.

A practical troubleshooting checklist looks like this:

1. Print the variable values.
2. Confirm the operator matches the data type.
3. Check for quotes around variables.
4. Validate the syntax with shellcheck.
5. Run the test manually at the prompt.

For deeper command behavior, the Bash manual and your system’s man pages remain essential references. If your script interacts with services, logs, or network tools, it is worth checking the vendor docs for those commands too. That habit saves time and prevents guessing.

Conclusion

bash if then statements are the backbone of decision-making in Bash scripts. They let you validate input, compare strings, compare numbers, check files and directories, and branch on command success or failure. Once you understand that exit status drives the logic, the rest of Bash scripting becomes much easier to reason about.

The most useful patterns are the ones you can apply immediately: string emptiness checks, numeric thresholds, permission checks, directory creation guards, and fallback handling when a command fails. Those are the building blocks behind dependable Linux automation and the kind of shell programming that supports real operations work.

Practice by taking the examples here and adapting them to your own environment. Swap in your own file paths, service names, and environment labels. Then test them one condition at a time, watch the exit codes, and keep the structure readable.

If you want your scripts to be more dependable, keep three habits in place: quote variables, use clear branching, and debug early. That combination will save you far more time than any clever one-liner ever will.

For readers working through the CompTIA N10-009 Network+ Training Course, these Bash patterns fit naturally into troubleshooting, connectivity checks, and workflow validation. They are small tools, but they solve real problems.

CompTIA® and Network+™ are trademarks of CompTIA, Inc.

if [ -f "/path/to/file" ]; then
    echo "File exists."
fi

if [ -f "/file1" ] && [ -f "/file2" ]; then
    echo "Both files exist."
fi

if [ "$status" -eq 0 ]; then
    echo "Operation succeeded."
elif [ "$status" -eq 1 ]; then
    echo "Operation failed with error code 1."
else
    echo "Unknown status."
fi