Your First Bash Script

Part of a deep dive: Bash Scripting

Consult the map

• Bash Scripting — step 1 of 6

  ---

  ← (first step) · you are here · Variables and Quoting →

  Start the deep dive →

Prerequisites

If you need a refresher on the terminal, start with Command Line Fundamentals.

Running the same sequence of commands manually, over and over, is a familiar routine. A Bash script captures that sequence, makes it repeatable, and lets it get handed to a colleague or a CI pipeline. The gap between "I know the commands" and "I wrote the script" is smaller than it looks.

---

Where You Might Have Seen This

If you've typed the same sequence of commands more than once, you've already felt the problem a script solves — it's just that sequence saved to a file and made repeatable. If you've used Windows batch files (.bat), the concept is identical; Linux just uses different syntax and bash is available everywhere by default.

---

A First Script

#!/usr/bin/env bash

echo "=== System Information ==="
echo "User:     $(whoami)"
echo "Host:     $(hostname)"
echo "Date:     $(date)"
echo "Uptime:   $(uptime -p)"
echo "Disk:     $(df -h / | awk 'NR==2 {print $3 " used of " $2}')"
echo "Memory:   $(free -h | awk '/^Mem:/ {print $3 " used of " $2}')"

Three things to notice:

• $(...) runs a command and substitutes its output inline — covered in depth in Variables and Quoting
• echo sends output to stdout; pipelines and redirection work just like at the prompt
• There's no main() function — Bash runs top to bottom

---

The Shebang Line

That first line — #!/usr/bin/env bash — tells the OS which interpreter to run the script with. Without it, the shell has to guess, and it can guess wrong.

#!/usr/bin/env bash#!/bin/bash#!/bin/shNo shebang

Uses env to find bash in $PATH. Survives if bash is installed in a non-standard location — common on macOS, BSD, or NixOS. The portable choice.

#!/usr/bin/env bash

Absolute path to bash on most Linux systems. Slightly faster (skips the env lookup). Fine for scripts you know will only run on standard Linux.

#!/bin/bash

POSIX shell — not Bash. More portable across Unix systems but loses Bash-specific features like [[ ]], arrays, and process substitution. Only use this if you genuinely need POSIX portability.

#!/bin/sh

The shell that called the script runs it. If your user's shell is zsh, the script runs as zsh. Unpredictable in automated contexts. Don't do this for scripts you'll share or schedule.

The rule of thumb: Use #!/usr/bin/env bash unless you have a specific reason to do otherwise.

---

Making It Executable

A new file isn't executable by default. Two steps to run it:

chmod +x system-info.sh
./system-info.sh

The ./ prefix tells the shell "look here, not in PATH." Without it, the shell searches PATH and won't find your script unless you've added its directory.

Read scripts before running them

chmod +x and ./run.sh is a common pattern in installation instructions. Read the script before executing it — it runs with your permissions.

See File Permissions for the full explanation of chmod and permission bits.

Running Without chmod +x

You can also run a script by passing it directly to bash:

bash system-info.sh

This works even without chmod +x. Useful for quick tests, but the executable bit is the right approach for scripts you'll deploy or share.

---

Where to Store Scripts

Where a script lives determines who can run it and how easily:

flowchart TD
    S["A finished script"] --> Q{"Who needs to run it?"}
    Q -->|"Just you"| P["~/bin/<br/>add to your own PATH"]
    Q -->|"Every user on this box"| SW["/usr/local/bin/<br/>survives package updates"]
    Q -->|"Your whole team"| T["/opt/company/bin/<br/>added to PATH via /etc/profile.d/"]

    style S fill:#2d3748,stroke:#cbd5e0,stroke-width:2px,color:#fff
    style Q fill:#1a202c,stroke:#cbd5e0,stroke-width:2px,color:#fff
    style P fill:#2f855a,stroke:#cbd5e0,stroke-width:2px,color:#fff
    style SW fill:#2f855a,stroke:#cbd5e0,stroke-width:2px,color:#fff
    style T fill:#2f855a,stroke:#cbd5e0,stroke-width:2px,color:#fff

Personal ScriptsSystem-Wide ScriptsTeam Scripts

For scripts only you need to run, install them to ~/bin and add it to your PATH:

mkdir -p ~/bin
cp system-info.sh ~/bin/system-info
chmod +x ~/bin/system-info

Add ~/bin to your PATH in ~/.bashrc:

export PATH="$HOME/bin:$PATH"

Now you can run system-info from anywhere without ./.

For scripts that all users on the system should access:

sudo cp system-info.sh /usr/local/bin/system-info
sudo chmod +x /usr/local/bin/system-info

/usr/local/bin/ is already in PATH for all users. Scripts here survive package manager updates (unlike /usr/bin/).

For shared tooling in a team environment:

sudo mkdir -p /opt/company/bin
sudo cp system-info.sh /opt/company/bin/system-info
sudo chmod +x /opt/company/bin/system-info

Add /opt/company/bin to PATH system-wide via /etc/profile.d/company.sh. Putting shared scripts under /opt/company/ keeps them out of package-managed paths and makes them easy to find.

---

Practice Exercises

Exercise 1: Write a Health Check Script

Write a script called health-check.sh that prints the following in a formatted block:

• Current user and hostname
• Load average (use uptime)
• Disk usage on / (use df -h)
• Whether a specific process is running (use pgrep -x sshd)

Solution

#!/usr/bin/env bash

echo "=== Health Check: $(hostname) ==="
echo "User:    $(whoami)"
echo "Load:    $(uptime | awk -F'load average:' '{print $2}')"
echo "Disk:    $(df -h / | awk 'NR==2 {print $5 " used (" $3 "/" $2 ")"}')"

if pgrep -x sshd &>/dev/null; then
    echo "sshd:    running"
else
    echo "sshd:    NOT RUNNING"
fi

Exercise 2: Script Location Practice

Create a script called whoami-full.sh that prints your username, your primary group, and your home directory. Install it as a personal tool so you can run whoami-full from any directory without ./.

Solution

#!/usr/bin/env bash

echo "User:  $(whoami)"
echo "Group: $(id -gn)"
echo "Home:  ${HOME}"

Install it:

mkdir -p ~/bin
cp whoami-full.sh ~/bin/whoami-full
chmod +x ~/bin/whoami-full
whoami-full            # (1)!

1. This only resolves by name if ~/bin is on your PATH. If it isn't, add export PATH="$HOME/bin:$PATH" to ~/.bashrc and open a new shell first.

---

Quick Recap

• The shebang line (#!/usr/bin/env bash) tells Linux which interpreter to use — always include it
• chmod +x script.sh makes the file executable; ./script.sh runs it
• bash script.sh runs a script without the executable bit — useful for one-off testing
• ~/bin/ for personal scripts, /usr/local/bin/ for system-wide, /opt/company/bin/ for team tooling
• Add the directory to $PATH so you can call scripts by name from anywhere

What's Next?

Head to Variables and Quoting — how to declare variables, why quoting prevents catastrophic bugs, and how command substitution captures runtime values.

---

Further Reading

Command References

• man bash — the full Bash reference; the "INVOCATION" section covers how scripts are started
• man chmod — file permission bit reference

Deep Dives

• Google Shell Style Guide — the de-facto standard for team Bash scripts
• The Art of Command Line — command line mastery, including scripting fundamentals

Official Documentation

• GNU Bash Manual — the authoritative Bash reference
• Filesystem Hierarchy Standard — official spec for where things go on Linux

Exploring Python

• Why Python (Not Just Bash) — When your script grows into something bigger: the signals that mean Python is the right next step