Bash Fundamentals

What Is Bash Scripting?

Bash (Bourne Again SHell) is both an interactive shell and a scripting language. A Bash script is just a text file of the same commands you’d type interactively, saved so they can be run repeatedly, automated, and version-controlled.

flowchart LR A[Write commands in a .sh file] --> B["Make it executable: chmod +x"] B --> C["Run it: ./script.sh"] C --> D[Bash interprets line-by-line, executes]

The Shebang Line

#!/usr/bin/env bash

The first line of every script tells the kernel which interpreter to use. #!/usr/bin/env bash finds bash wherever it lives on $PATH, which is more portable than hardcoding #!/bin/bash (bash isn’t always at that exact path, e.g. on some BSD/macOS setups).

Making a Script Executable

touch deploy.sh
chmod +x deploy.sh      # add execute permission
./deploy.sh               # run it (must include ./ unless it's on $PATH)

bash deploy.sh              # alternative: run without execute permission, explicitly via bash
sh deploy.sh                   # runs it with /bin/sh instead — may break bash-only syntax

Anatomy of a Real Script

#!/usr/bin/env bash
set -euo pipefail   # fail fast: exit on error, undefined var, or failed pipe stage

# --- Configuration ---
APP_NAME="myapp"
LOG_DIR="/var/log/$APP_NAME"

# --- Functions ---
log() {
    echo "[$(date +'%Y-%m-%d %H:%M:%S')] $*"
}

# --- Main ---
log "Starting deployment for $APP_NAME"
mkdir -p "$LOG_DIR"
log "Deployment complete"

set -euo pipefail is the single most important line in production Bash — covered in depth in the Exit Codes & Error Handling tutorial.

Comments

# This is a single-line comment
echo "hello"   # inline comment after a command

: '
This is a multi-line comment trick.
Everything between the quotes is ignored.
'

Running Scripts: Three Ways

Method	What Happens
`./script.sh`	Runs in a new subshell using the shebang interpreter — needs execute permission
`bash script.sh`	Explicitly runs with bash, in a new subshell — works without execute permission
`source script.sh` (or `. script.sh`)	Runs in the current shell — variables/functions it sets persist after it finishes

# Example: source is used to load environment variables into your CURRENT shell
source .env
echo $DATABASE_URL   # now available in this shell session

Production Considerations

Always start production scripts with #!/usr/bin/env bash and set -euo pipefail — silent partial failures are the #1 cause of “the deploy script half-ran and left things broken.”
Never assume sh and bash are interchangeable — many CI systems default to sh (often dash), which doesn’t support bash-only syntax like [[ ]] or arrays.
Keep configuration (variables, paths) at the top of the script, clearly separated from logic — makes scripts easier to review and modify safely.

Quick Interview Answer

“A Bash script is a text file of shell commands with a shebang line (#!/usr/bin/env bash) telling the kernel which interpreter to use, made executable with chmod +x. ./script.sh runs it in a new subshell; source script.sh runs it in the current shell so variable/environment changes persist — that distinction matters a lot for scripts meant to modify your current session.”

Common Mistakes

Forgetting chmod +x and then being confused why ./script.sh says “permission denied.”
Using #!/bin/bash instead of #!/usr/bin/env bash, reducing portability.
Not knowing the difference between running a script normally vs. source-ing it, and being surprised environment variables don’t persist.