Shell Scripting for Beginners: Automate Tasks on a Linux Server

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.

The quickest way to automate a Linux server is to turn a command sequence you already trust into a small Bash script, add arguments and checks, test its failure paths, and then run it from cron or another scheduler. This guide takes you from your first executable script to a daily, logged job that runs with predictable permissions and paths.

What a shell script is and why it helps

Bash is both a command interpreter and a programming language. The GNU Bash Reference Manual describes it as “the shell, or command language interpreter, for the GNU operating system” and notes that “A Unix shell is both a command interpreter and a programming language.” When you type a command at a terminal, Bash parses it, expands variables and wildcards, starts programs, connects pipelines, and reports an exit status.

#	Preview	Product	Price
1		The Linux Command Line, 3rd Edition: A Complete Introduction	$27.94	Buy on Amazon
2		The Linux Command Line, 2nd Edition: A Complete Introduction	$11.34	Buy on Amazon
3		Linux Command Line: A Simple Beginner’s Guide to Linux Commands and Terminal Basics	$1.99	Buy on Amazon
4		The Linux Command Line Beginner's Guide	$2.99	Buy on Amazon
5		Linux Command Line Power: A Practical Guide to Navigating, Scripting, and Automating Linux Like a...	$8.99	Buy on Amazon

A shell script is a text file containing shell commands. Bash can execute that file non-interactively, without a person entering each command. A script can accept positional arguments such as $1 and $2, make decisions, repeat work, and return a status that another program or scheduler can inspect.

Interactive commands are useful while you discover the exact operation. A script makes the operation repeatable and reviewable. Before scheduling anything, run every command manually, record the intended input and output, and decide what should happen when a command fails.

#1 Best Overall

Sale

The Linux Command Line, 3rd Edition: A Complete Introduction

$27.94

Buy on Amazon

Your smallest useful Bash script

#!/usr/bin/env bash

name="Linux administrator"
printf 'Hello, %sn' "$name"
exit 0

The first line is a shebang. It asks the operating system to locate Bash through env. The variable is quoted when expanded, so spaces in its value remain part of one argument. printf writes predictable output, and exit 0 explicitly reports success. If a command fails, a nonzero status conventionally indicates an error.

Write and run your first script

Use a harmless, user-owned task while learning. This example creates a dated report directory and writes a short status file. It does not modify system files or require root privileges.

1. Create a directory for personal scripts: mkdir -p "$HOME/bin".
2. Open a file such as $HOME/bin/make-report.sh in your editor and enter:

#!/usr/bin/env bash

if [ "$#" -lt 1 ]; then
    printf 'Usage: %s OUTPUT_DIRECTORYn' "$0" >&2
    exit 2
fi

output_root="$1"
stamp="$(date +%F)"
report_dir="$output_root/report-$stamp"

if ! mkdir -p -- "$report_dir"; then
    printf 'Cannot create %sn' "$report_dir" >&2
    exit 1
fi

{
    printf 'Report date: %sn' "$stamp"
    printf 'Host: '
    hostname
} > "$report_dir/status.txt"

printf 'Wrote %sn' "$report_dir/status.txt"

3. Save the file and make it executable: chmod +x "$HOME/bin/make-report.sh".
4. Run it with an explicit destination: "$HOME/bin/make-report.sh" "$HOME/reports".
5. Inspect the result with cat "$HOME/reports/report-$(date +%F)/status.txt".

$# is the number of arguments and $0 is the script name. Checking required arguments before creating files prevents an accidental empty path from becoming the destination. The -- after mkdir -p marks the end of options, which is safer when a path begins with a hyphen.

Bash building blocks to learn first

Quoting, variables and expansions

Use double quotes around variable expansions unless you intentionally want word splitting or wildcard expansion. path="$HOME/logs" preserves spaces; rm $path can turn one value into several arguments and can expand wildcard characters. Single quotes prevent all expansions, while double quotes allow substitutions such as $name and $(command).

Command substitution captures output: today="$(date +%F)". Arithmetic expansion handles integers: next=$((count + 1)). Parameter defaults are useful for optional settings: target="${1:-$HOME/reports}" uses the first argument unless it is missing or empty.

Conditionals

An if statement tests a command’s exit status. The bracket form is a command, so spaces are required:

Rank #2

The Linux Command Line, 2nd Edition: A Complete Introduction

$11.34

Buy on Amazon

if [ -f "$config" ]; then
    printf 'Found %sn' "$config"
elif [ -d "$config" ]; then
    printf '%s is a directoryn' "$config"
else
    printf 'Missing: %sn' "$config" >&2
    exit 1
fi

Use [[ ... ]] for Bash-specific tests and pattern matching, but remember that such syntax is not portable to plain POSIX sh. Test commands directly when possible: if curl ...; then is clearer than running a command, ignoring its status, and checking $? later.

Loops

A for loop is appropriate for a known list. Use a quoted array when filenames may contain spaces:

files=("$HOME/logs/app.log" "$HOME/logs/worker.log")
for file in "${files[@]}"; do
    [ -e "$file" ] || continue
    printf '%s: ' "$file"
    wc -l < "$file"
done

A while loop suits repeated checks or line-by-line input. Prefer reading with while IFS= read -r line so backslashes and leading whitespace are preserved.

Functions

Functions keep repeated operations in one place and make the main flow readable:

log() {
    printf '%s %sn' "$(date --iso-8601=seconds)" "$*"
}

log 'backup started'

Function arguments are still positional: $1 inside the function is its first argument. Use local variables with local filename="$1" to avoid changing a global value.

Pipelines and redirection

The pipe operator sends one command’s standard output to another command’s standard input: du -sh -- "$HOME" | sort -h. Redirect output with > to replace a file, >> to append, and 2> for standard error. Combine streams for a cron log with >> /path/job.log 2>&1. A here-document can provide configuration text without a temporary file.

Rank #3

Linux Command Line: A Simple Beginner’s Guide to Linux Commands and Terminal Basics

$1.99

Buy on Amazon

Exit status

Immediately after a command, $? contains its status. Save it before running another command if you need it. In most Linux tools, zero means success and a nonzero value means failure. Design your own functions to return meaningful nonzero values and let the caller decide whether to stop, retry, or continue.

Safe defaults, syntax checks and testing

Start with a syntax-only check: bash -n "$HOME/bin/make-report.sh". POSIX documents set -n as reading commands without executing them for syntax checking; invoking bash -n is the same practical check for a Bash file.

You will often see this header:

set -euo pipefail

• set -u treats an unset variable as an error, exposing misspellings early. Give intentional optional variables a default such as ${name:-}.
• set -o pipefail makes a pipeline fail when an earlier command fails, not only when the final command fails.
• set -e can stop a script after an error, but POSIX specifies exceptions. Commands used as conditional tests, some pipeline components, and other contexts can be exempt. It is not a complete error-handling strategy by itself.

Check important operations explicitly, especially destructive or privileged ones:

if ! tar -czf "$archive" -C "$source_parent" "$source_name"; then
    printf 'Backup failedn' >&2
    exit 1
fi

Run a linter such as ShellCheck after the script parses. Treat its messages as advice to investigate, not proof that the program is correct. Test success, missing arguments, nonexistent files, permission failures, empty input, and interrupted runs. Test in a temporary directory before pointing a script at production data.

Patterns for useful server automation

Back up a configuration directory

Set paths in clearly named variables and create the destination before archiving. This example assumes you have read permission for the source and write permission for the destination; replace every path with values appropriate to your server.

#!/usr/bin/env bash
set -u

source_dir="$HOME/app-config"
backup_dir="$HOME/backups"
stamp="$(date +%Y%m%d-%H%M%S)"
archive="$backup_dir/app-config-$stamp.tar.gz"

if [ ! -d "$source_dir" ]; then
    printf 'Source directory does not exist: %sn' "$source_dir" >&2
    exit 1
fi
mkdir -p -- "$backup_dir" || exit 1
if ! tar -czf "$archive" -C "$(dirname -- "$source_dir")" "$(basename -- "$source_dir")"; then
    printf 'Archive failedn' >&2
    exit 1
fi
printf 'Created %sn' "$archive"

Keeping the archive in a separate directory makes the operation easier to verify. For system configuration under directories such as /etc, permissions may require a dedicated service account or root; do not add sudo until you understand the exact files and ownership involved.

Rank #4

Sale

The Linux Command Line Beginner's Guide

$2.99

Buy on Amazon

Disk-usage report

A reporting script should write to a known absolute path and include a timestamp. Capture command failures rather than producing an apparently complete report from partial data. If a report is consumed by another program, use a stable format such as one record per line and document the units.

Retention cleanup

Deletion deserves a dry run. First list candidates with a command such as find "$backup_dir" -type f -name '*.tar.gz' -mtime +14 -print. Review the list, then add -delete only when the path, file type and age rule are correct. Keep the retention period in a variable, refuse an empty directory variable, and never run an unreviewed cleanup as root.

Logging and overlapping runs

Log start time, key inputs, completion, and failures. Use absolute log paths and rotate logs separately if they can grow without limit. A scheduled job can overlap itself when one run takes longer than its interval. A simple lock directory is atomic on local filesystems:

lock_dir="/tmp/my-report.lock"
if ! mkdir "$lock_dir" 2>/dev/null; then
    printf 'Another run is activen' >&2
    exit 1
fi
trap 'rmdir -- "$lock_dir"' EXIT

Choose a lock location writable by the account running the script, and consider stale locks after crashes. For higher-risk jobs, use the locking facility supplied by your operating system or service manager.

Run a shell script every day with cron

A crontab contains instructions for the cron daemon in the simplified form “run this command at this time on this date.” Each user can have a crontab, and commands run with that user’s permissions. Make the script reliable interactively before scheduling it.

The five schedule fields

An asterisk means every value. To run a report at 02:15 every day, edit your user crontab with crontab -e and add:

Best Value

Linux Command Line Power: A Practical Guide to Navigating, Scripting, and Automating Linux Like a Pro

$8.99

Buy on Amazon

15 2 * * * /home/alice/bin/make-report.sh /home/alice/reports >>/home/alice/logs/make-report.log 2>&1

Create the log directory first, then verify the installed entry with crontab -l. Replace the username and paths; do not copy this line unchanged. The script’s execute bit, destination permissions, and parent directories must all be correct.

Why cron differs from your terminal

Cron supplies a limited, daemon-provided environment. The current working directory, PATH, home directory assumptions, language settings, and exported variables may differ from an interactive login. A crontab command is normally interpreted by /bin/sh unless the SHELL variable is set. Keep the Bash shebang in the script and use absolute paths for commands when predictable behavior matters. If a Bash-only feature is required, invoke Bash explicitly in the crontab, for example /usr/bin/env bash /home/alice/bin/job.sh, using the actual Bash path on your system.

Redirect both output streams while diagnosing. Add a temporary line that records date, id, pwd and PATH, then remove it after finding the discrepancy. Check file permissions, missing environment variables, relative paths, shell syntax, and whether the cron service is running. Never rely on an interactive alias or function.

Local-time schedules have edge cases around daylight-saving changes: nonexistent local times do not match, while repeated local times can run twice. Avoid placing an irreversible operation exactly at a transition if a duplicate or missed run would be harmful.

Choosing an automation approach

For a simple daily user job, cron is often sufficient. For jobs that need dependency ordering, centralized logs, restart handling, or resource limits, a service or timer manager may be a better operational fit. The script itself should remain inspectable and safe regardless of the trigger.

A practical learning path

1. Run individual commands interactively and read their manual pages.
2. Save a short, harmless sequence in a file with a Bash shebang.
3. Learn quoting, variables, expansions, exit statuses, redirection and pipelines.
4. Add argument validation, conditionals, loops and functions.
5. Use absolute paths, explicit configuration variables, least privilege and clear logs.
6. Check syntax with bash -n, review with ShellCheck, and test failure paths in a temporary location.
7. Prevent overlapping runs and make reruns safe where possible.
8. Schedule only after an interactive run succeeds; inspect cron logs and the job’s redirected output.

A Linux command line book or Bash scripting reference can provide longer exercises once these fundamentals are familiar. Focus first on scripts you can explain line by line; complexity should be earned by a real administrative need.

Quick Recap

SaleBestseller No. 1

The Linux Command Line, 3rd Edition: A Complete Introduction

$27.94

Bestseller No. 2

The Linux Command Line, 2nd Edition: A Complete Introduction

$11.34

Bestseller No. 3

Linux Command Line: A Simple Beginner’s Guide to Linux Commands and Terminal Basics

$1.99

SaleBestseller No. 4

The Linux Command Line Beginner's Guide

$2.99

Bestseller No. 5

Linux Command Line Power: A Practical Guide to Navigating, Scripting, and Automating Linux Like a Pro

$8.99

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.