Script Structure, Variables, and Control Flow

Why Script Structure Matters for DBAs

As a database administrator, you will repeat the same checks dozens of times a week: Is this server reachable? Does this database exist? How many connections are active? Writing those checks by hand every time wastes time and introduces human error. A well-structured Bash script turns a ten-step manual procedure into a single command that runs the same way every time. That consistency is what employers expect and what the credentials you are working toward reward.

The Shebang Line

Every Bash script must begin with a shebang line:

```bash

#!/usr/bin/env bash

```

This line tells the operating system which interpreter to use. Without it, the shell may run your script under a different interpreter (sh, dash, etc.) that does not support all Bash features. The `env bash` form finds Bash wherever it lives on the system, making the script more portable across Linux distributions — important when you manage servers at multiple sites.

Always place the shebang on line 1, column 1, with no leading spaces.

Comments

Comments begin with `#` and are ignored by the interpreter. Use them to explain why the script does something, not just what it does. At minimum, every script should have a header block:

```bash

#!/usr/bin/env bash

```

Inline comments after code are fine: `psql -lqt # list databases, quiet, tuples only`

Variables and Positional Parameters

A variable stores a value you want to reuse. Name it in UPPER_CASE by convention for environment-level or script-wide values:

```bash

LOG_FILE="/var/log/db_status.log"

MIN_CONNS=5

```

Assign with `=` and no spaces around the equals sign. Reference with a leading `$`, and always double-quote the reference to prevent word-splitting on values that contain spaces:

```bash

echo "Log is at: $LOG_FILE"

```

Positional parameters are arguments passed on the command line. `$1` is the first argument, `$2` the second, `$0` is the script name. Use `$#` to check how many arguments were supplied:

```bash

if [[ $# -lt 1 ]]; then

echo "Usage: $0 <database_name>" >&2

exit 1

fi

DB_NAME="$1"

```

Redirecting the error message to `>&2` (standard error) is correct practice — it keeps error output separate from normal output and makes pipelines behave predictably.

if / elif / else Logic

Bash uses double brackets `[[ ]]` for conditional tests. Common operators:

• `-z "$VAR"` — true if the string is empty
• `-f "$FILE"` — true if the file exists and is a regular file
• `-eq`, `-lt`, `-gt` — numeric comparisons
• `==` — string equality inside `[[ ]]`

Structure:

```bash

if [[ condition_one ]]; then

elif [[ condition_two ]]; then

else

fi

```

Always close with `fi`. Each branch should either produce output or set an exit code.

for and while Loops

A for loop iterates over a list:

```bash

for HOST in $(cat servers.txt); do

ping -c 1 -W 2 "$HOST" &>/dev/null && STATUS="UP" || STATUS="DOWN"

echo "$(date '+%Y-%m-%d %H:%M:%S') $HOST $STATUS" >> "$LOG_FILE"

done

```

A while loop runs as long as a condition is true, useful for reading a file line by line safely:

```bash

while IFS= read -r HOST; do

done < servers.txt

```

The `while read` pattern is preferred over `for $(cat ...)` when hostnames might contain spaces or special characters.

Exit Codes

Every command returns an exit code: 0 means success, anything else means failure. Your script should return a meaningful exit code with `exit 0` on success and `exit 1` (or higher) on failure. Tools like monitoring systems and CI pipelines rely on these codes to determine whether a job succeeded.

Syntax Checking with bash --norc -n

Before running any script on a production database server, check its syntax:

```bash

bash --norc -n check_db.sh

```

The `-n` flag parses the script without executing it. `--norc` prevents your personal `.bashrc` from interfering. A clean check produces no output. Any error is printed with a line number — fix it, recheck, and document the change in your lab journal. This is a low-risk habit that prevents embarrassing (and potentially damaging) script errors on live systems.

Safety Notes

Scripts that connect to databases carry real risk. Follow these rules:

• Never hard-code passwords. Use a `.pgpass` file, environment variables set by a secrets manager, or a PostgreSQL connection service file (`pg_service.conf`).
• Test on a non-production instance first. Label the script's intended environment in the header comment.
• Restrict permissions. Set `chmod 700` on scripts that contain sensitive logic so only the owning account can read or execute them.
• Quote all variables. Unquoted variables that expand to empty strings can cause commands to run with unexpected arguments — on a database server, that can mean running a query against the wrong target.
• Validate input. If the script accepts a database name from the command line, confirm it matches expected characters (letters, digits, underscores) before passing it to `psql`. This guards against accidental injection of shell metacharacters.

Good scripting habits are not just about efficiency — they are the first line of defense for the systems you are responsible for protecting.