Shell Scripting for Beginners: Automate Tasks on a Linux Server

The fastest way to automate Linux administration is to turn a command sequence that already works into a small Bash script, test it safely, then run it from a scheduler such as cron. Start with ordinary commands in an interactive terminal. Save them in a text file with a Bash shebang, add variables and argument checks, make failures visible, and only then schedule the script. This approach keeps every step inspectable instead of hiding server changes behind an opaque tool.

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

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 says that “a Unix shell is both a command interpreter and a programming language.” That combination lets one script call standard utilities, make decisions, repeat work, and report an exit status to another program.

#	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

As an Amazon Associate I earn from qualifying purchases.

What a shell script is

A shell script is a text file containing shell commands. Bash can execute that file non-interactively, accept values supplied on the command line, and run it as a program after you give the file its execute permission. The shell parses each line, expands variables and patterns, starts commands, connects their input and output, and returns a status code.

Interactive work is useful while discovering a procedure: you can see output immediately and correct a command before running the next one. A script records the procedure so it can be reviewed, repeated, logged, and scheduled. Non-interactive execution also means you must make assumptions explicit. A script cannot rely on your current directory, your interactive aliases, or a prompt waiting for an answer.

#1 Best Overall

Sale

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

$27.94

Buy on Amazon

How Bash fits around Linux commands

Bash does not replace utilities such as find, tar, df, or awk. It coordinates them. Parameters hold values, expansions insert those values into commands, pipelines pass output between processes, redirections send output to files, and control structures decide what happens next. The GNU reference manual groups syntax, commands, functions, parameters, expansions, redirections, and script execution among Bash’s basic features.

Write your first Bash script

Choose a harmless, user-owned task while learning. This example creates a dated report directory and records disk usage; it does not alter system files.

#!/usr/bin/env bash

report_root="$HOME/server-reports"
today="$(date +%F)"
report_dir="$report_root/$today"

mkdir -p -- "$report_dir" || exit 1
df -h > "$report_dir/disk-usage.txt"
printf 'Wrote report to %sn' "$report_dir"
exit 0

The first line is the shebang. /usr/bin/env bash asks the system to locate Bash using the environment’s PATH, while the rest of the file uses Bash syntax. Quoting "$report_root", "$today", and the path protects spaces and wildcard characters. $(date +%F) is command substitution: Bash runs date and inserts its output. mkdir -p creates missing parent directories and succeeds when the directory already exists, which makes this operation safe to repeat.

Save, inspect, and run it

1. Create the file with an editor, for example nano disk-report.sh, and paste the script.
2. Read it back before execution: sed -n '1,120p' disk-report.sh.
3. Check syntax without running commands: bash -n disk-report.sh.
4. Run it explicitly through Bash: bash disk-report.sh.
5. When the behavior is correct, set the execute bit: chmod +x disk-report.sh.
6. Run the executable from its directory: ./disk-report.sh.

The execute bit changes who may run the file as a program; it does not make unsafe commands safe. Keep scripts writable only by the account that should maintain them, especially when a privileged scheduler will execute them.

Accept arguments instead of editing the file

Positional parameters make one script reusable. $1 is the first argument, $2 the second, and $# is the number supplied. Validate required input before making changes.

#!/usr/bin/env bash

if [[ $# -ne 2 ]]; then
    printf 'Usage: %s SOURCE_DIR DEST_DIRn' "$0" >&2
    exit 2
fi

source_dir=$1
dest_dir=$2

if [[ ! -d $source_dir ]]; then
    printf 'Source is not a directory: %sn' "$source_dir" >&2
    exit 1
fi

mkdir -p -- "$dest_dir" || exit 1
printf 'Ready to process %s into %sn' "$source_dir" "$dest_dir"

$0 is the script name. The example exits before creating anything when the argument count or source path is wrong. Always quote a parameter when it is used as a pathname, and decide deliberately whether an option should accept a relative path or require an absolute one.

Rank #2

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

$11.34

Buy on Amazon

Bash building blocks to learn first

Quoting and expansions

Unquoted expansions can be split into multiple words or interpreted as filename patterns. Use double quotes around variable expansions by default: cp -- "$source" "$destination". Double quotes still allow parameter and command substitution. Single quotes preserve literal text, which is useful for patterns that Bash must not expand. Braces clarify a variable’s boundary, as in "${name}.log".

Command substitution captures output, not an exit status: output=$(command). Check the command’s status separately when failure matters. Arithmetic expansion, $((count + 1)), is useful for counters, while parameter expansion can supply defaults such as ${CONFIG_DIR:-/etc/myapp}.

Conditionals and exit status

Every command returns an integer status; zero conventionally means success and a nonzero value means failure. The special parameter $? contains the status of the command that ran most recently, so inspect it immediately if you need it.

if tar -czf -- "$archive" -C "$config_dir" .; then
    printf 'Backup created: %sn' "$archive"
else
    status=$?
    printf 'Backup failed with status %sn' "$status" >&2
    exit "$status"
fi

Bash’s [[ ... ]] conditional syntax avoids many word-splitting surprises. Common tests include -f for a regular file, -d for a directory, -r for readable, and numeric comparisons such as -gt. Use a clear failure branch rather than assuming a command succeeded.

Loops

A for loop handles a known collection, while a while loop repeats while a condition remains true.

for config in /etc/myapp/*.conf; do
    [[ -e $config ]] || continue
    printf 'Checking %sn' "$config"
done

count=0
while IFS= read -r line; do
    ((count++))
done < input.txt
printf 'Read %s linesn' "$count"

The [[ -e $config ]] || continue guard prevents a nonmatching glob from being treated as a literal filename. IFS= read -r preserves leading whitespace and backslashes when reading lines.

Rank #3

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

$1.99

Buy on Amazon

Functions, pipelines, and redirection

Functions package a repeatable operation and make the main procedure easier to read.

write_log() {
    local message=$1
    printf '%s %sn' "$(date --iso-8601=seconds)" "$message" >> "$log_file"
}

write_log 'job started'
find "$source_dir" -type f -print0 | wc -c > "$report_file"
write_log 'job finished'

A pipeline sends one command’s standard output to the next command’s standard input. The > operator replaces a file, while >> appends to it. Use 2> for standard error and &> when Bash-specific syntax should combine standard output and standard error. Redirect deliberately: a report file should usually be replaced, while a log should usually be appended.

Safe defaults and validation

Syntax checking is not behavior testing

bash -n script.sh parses the file without executing its commands. POSIX documents the equivalent set -n behavior as reading commands without executing them for syntax checking. This catches missing quotes, parentheses, and control-structure terminators, but it cannot prove that a path exists or that a backup is restorable.

Test in a temporary directory with sample data. Exercise success and failure paths: a missing argument, an unreadable file, a full destination, an empty glob, and an interrupted command. Verify generated archives by listing their contents and inspect report files rather than assuming a zero status means the intended result was produced.

Use strictness deliberately

You will often see set -euo pipefail. set -u treats an unset parameter as an error, and pipefail makes a pipeline fail when an earlier command fails. POSIX specifies exceptions for set -e, including contexts such as conditional tests and parts of pipelines, so set -e is not a complete error-handling strategy by itself. Check important commands explicitly and test the branches that matter.

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

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

ShellCheck can review a script for common quoting, expansion, and portability mistakes. Treat its output as advice to investigate, not proof that the program is correct. A clean lint report cannot know whether a deletion policy is appropriate or whether a service can tolerate a restart.

Rank #4

Sale

The Linux Command Line Beginner's Guide

$2.99

Buy on Amazon

Server automation patterns that are safe to adapt

Create a dated configuration backup

Use explicit configuration variables, an absolute destination, and a temporary archive name so a partial write is not mistaken for a finished backup.

#!/usr/bin/env bash

config_dir=/etc/myapp
backup_dir=/var/backups/myapp
stamp=$(date +%Y%m%d-%H%M%S)
tmp="$backup_dir/.myapp-$stamp.tar.gz.tmp"
final="$backup_dir/myapp-$stamp.tar.gz"

mkdir -p -- "$backup_dir" || exit 1
tar -czf "$tmp" -C "$config_dir" . || {
    rm -f -- "$tmp"
    exit 1
}
mv -- "$tmp" "$final"
printf 'Created %sn' "$final"

Replace paths, service names, users, and package-manager commands with values from your server. Do not run a command involving /etc or another system directory until you understand its ownership and required privileges. Prefer a dedicated service account with only the permissions needed; avoid running an entire script as root when one narrowly scoped operation can be delegated.

Remove old files only after a dry run

Retention jobs are destructive. First print candidates, then enable deletion only after reviewing the output. Restrict the search to a known directory and specify the file type.

find /var/tmp/myapp -type f -mtime +14 -print
# After reviewing the list, add the deletion action:
find /var/tmp/myapp -type f -mtime +14 -print -delete

Use an application-specific directory rather than a broad path such as /tmp. If filenames may contain unusual characters, use null-delimited output and a tool that consumes it safely. Keep retention in a named variable and document whether “14 days” means modification time older than 14 complete 24-hour periods.

Prevent overlapping runs and record outcomes

Two copies of a backup or cleanup script can race, consume extra disk space, or delete data while another process is reading it. A lock file or an operating-system locking utility can serialize runs. Log a start timestamp, the selected configuration, each major action, and a final success or failure status. Send errors somewhere an operator will see, such as a protected log file or cron mail, rather than silently discarding standard error.

Schedule a 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.” Jobs run with the permissions of the crontab owner. Cron supplies a daemon-controlled environment, not the full environment of your interactive terminal, and the command is normally interpreted by /bin/sh unless the SHELL variable is set.

Best Value

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

$8.99

Buy on Amazon

Use the five time fields

A user crontab line has five schedule fields followed by the command:

The expression 15 2 * * * requests 02:15 every day according to the machine’s local time. Verify the host’s timezone before relying on that interpretation.

Install and inspect a user crontab

1. Make the script reliable interactively using an absolute path, such as /home/alex/bin/disk-report.sh.
2. Ensure it is executable and has a Bash shebang: chmod 750 /home/alex/bin/disk-report.sh.
3. Open the current user’s crontab editor: crontab -e.
4. Add a schedule with an absolute script path and a log redirection, for example:
   15 2 * * * /home/alex/bin/disk-report.sh >> /home/alex/logs/disk-report.log 2>&1
5. Save the file, then confirm installation with crontab -l.

Create the log directory first and ensure the crontab owner can write it. If the script uses Bash arrays, [[ ]], or other Bash-only features, its shebang must select Bash; do not rely on cron’s default shell to do that. Use absolute paths for commands or set a deliberate PATH near the top of the script, because aliases and interactive startup files are not guaranteed.

Calendar edge cases and overlap

Local-time schedules have daylight-saving edge cases. Linux’s crontab documentation states that nonexistent local times do not match, while repeated local times can cause a job to run twice. For a job that must run exactly once, make the operation idempotent, record a unique run identifier, or use a scheduler with explicit timezone and missed-run behavior. Add a lock so a long execution cannot overlap the next invocation.

Why a script works in the terminal but fails in cron

Environment differences

Print diagnostic values to a temporary log when investigating: pwd, id, env, and the effective PATH. Replace relative paths with absolute paths, set required variables in the script, and do not assume your shell profile was loaded. A command found interactively may not be found by cron.

Shell and permission differences

Confirm that the file is executable, the shebang points to an installed Bash, and every directory in the path is searchable by the cron user. A user crontab cannot read root-only files. If a privileged task is required, use a carefully scoped system service or root-owned schedule and protect the script from edits by unprivileged users.

Missing output or hidden errors

Redirect both output streams while diagnosing: >> /path/to/job.log 2>&1. Check the cron daemon’s own logs using the logging system provided by your distribution. Remove verbose diagnostics after fixing the issue, but keep useful start, finish, and failure records.

Choosing a trigger and execution model

Evaluate more than the schedule syntax. Consider who owns the process and its blast radius, how failures reach an operator, whether rerunning is safe, whether overlapping executions are prevented, and whether the script uses portable POSIX sh or Bash-specific syntax. A calendar entry is convenient, but it does not by itself provide locking, rollback, or monitoring.

A practical learning path

1. Practice command discovery, standard input and output, pipelines, redirection, and exit statuses interactively.
2. Write a small script with #!/usr/bin/env bash, quoted variables, one clear purpose, and an explicit exit status.
3. Add positional-argument validation, functions, conditionals, and loops only when the task needs them.
4. Run bash -n, review with ShellCheck, and test both success and failure paths in a disposable directory.
5. Make server behavior predictable with absolute paths, explicit configuration, least privilege, logs, idempotence, and a lock.
6. Schedule the proven script with crontab -e, inspect it with crontab -l, and verify its log after the first run.

For deeper practice, a Linux command line book or a Bash scripting reference can provide progressively harder exercises. The essential first milestone is not memorizing every Bash feature: it is being able to explain what each command does, what happens when it fails, and how you will know whether the scheduled run succeeded.

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.