Linux Command Line for Beginners: Safe, Practical Exercises

Examples assume a Bash-like shell on a common Linux distribution. Package managers, service names and defaults vary. Read the local manual with man command or command --help before applying an unfamiliar option.

Create a safe Linux practice workspace

mkdir -p "$HOME/linux-lab/inbox"
cd "$HOME/linux-lab"
printf 'name,status\nalpha,ready\nbeta,hold\n' > inbox/jobs.csv
printf 'first log line\nwarning: sample only\n' > inbox/app.log
pwd
find . -maxdepth 2 -type f -print

Every exercise file is now under ~/linux-lab. Confirm the path printed by pwd before any command that moves or removes data. Quoting paths protects spaces and prevents some accidental shell expansion.

Navigate and inspect before changing anything

pwd
ls -la
ls -lh inbox
file inbox/jobs.csv
wc -l inbox/jobs.csv
head -n 3 inbox/jobs.csv

ls -l shows file type, permissions, owner, size and modification time. file examines the content type, while wc -l counts lines. These checks answer basic questions before you edit or process a file.

Search text and files precisely

grep -n 'warning' inbox/app.log
grep -Rni --include='*.log' 'warning' .
find . -type f -name '*.csv' -print
find . -type f -size +1M -print

grep searches content and find locates filesystem entries. Narrow searches are faster and reduce irrelevant output. When filenames might contain spaces or special characters, avoid parsing ls output in scripts; use tools and options designed for filenames.

Copy and move with verification

mkdir -p backup processed
cp -v inbox/jobs.csv backup/jobs.csv
cmp --silent inbox/jobs.csv backup/jobs.csv && echo 'backup verified'
mv -v backup/jobs.csv processed/jobs-copy.csv
find processed -maxdepth 1 -type f -print

cmp --silent returns success when the files match. In a script, verification should happen before an original is removed or overwritten. For valuable data, use a real backup system with retention and restore testing; a second file on the same disk is only an exercise copy.

Understand exit status and command chaining

Linux commands report success or failure through an exit status. Zero normally means success; a non-zero value reports a failure.

grep -q 'alpha' inbox/jobs.csv
printf 'exit status: %s\n' "$?"

test -f inbox/jobs.csv && echo 'input exists'
test -f missing.csv || echo 'missing.csv was not found'

&& runs the next command only after success. || runs it after failure. Do not build long chains that hide which step failed; use a script with explicit checks when the workflow matters.

Redirect output without losing data

A single > replaces a file; >> appends. Practice with disposable output:

grep 'ready' inbox/jobs.csv > processed/ready.txt
printf 'reviewed at %s\n' "$(date -Iseconds)" >> processed/ready.txt
cat processed/ready.txt

Before redirecting into an existing path, inspect it and consider writing to a temporary file first. A reliable program validates temporary output before replacing the destination.

Use pipes as visible processing stages

cut -d, -f2 inbox/jobs.csv | tail -n +2 | sort | uniq -c
printf '%s\n' alpha beta gamma | sort -r | nl -ba

A pipe sends one command’s standard output to the next command. Build and test a pipeline one stage at a time. If an early command can fail, check its behavior instead of assuming the final output proves that every stage worked.

Read permissions without reaching for 777

touch run-report.sh
ls -l run-report.sh
chmod u+x run-report.sh
ls -l run-report.sh

The first permission triplet applies to the owner, the second to the group and the third to others. chmod u+x adds execute permission for the owner only. Avoid chmod 777 as a troubleshooting reflex; it grants broad access and often conceals the real ownership problem.

Write a small Bash script that fails safely

Create summarize.sh with the following content:

#!/usr/bin/env bash
set -euo pipefail

if (( $# != 1 )) || [[ ! -f "$1" ]]; then
  printf 'Usage: %s FILE\n' "$0" >&2
  exit 2
fi

input="$1"
printf 'File: %s\n' "$input"
printf 'Lines: %s\n' "$(wc -l < "$input")"
printf 'Ready rows: %s\n' "$(grep -c ',ready$' "$input" || true)"

chmod u+x summarize.sh
./summarize.sh inbox/jobs.csv
./summarize.sh missing.csv

set -euo pipefail catches several common failure modes, but it does not replace validation or testing. The explicit missing-file check gives the user a useful message and a deliberate exit code.

Inspect processes, memory and storage

ps -ef | head
free -h
df -h
du -sh "$HOME/linux-lab"
uptime

free reports memory, df reports filesystem capacity and du estimates space used by a path. High memory use is not automatically a fault because Linux uses available memory for caching. Look for trends and evidence before killing processes.

Diagnose a systemd service with evidence

On a systemd-based system, replace ssh with a service you are authorized to inspect:

systemctl status ssh --no-pager
journalctl -u ssh --since '30 minutes ago' --no-pager
journalctl -p warning --since today --no-pager

systemctl status shows service state and recent messages. journalctl -u filters the journal for one unit. Access depends on local permissions. Read logs before restarting a service; a restart can erase useful symptoms without fixing the cause.

Update software through the distribution

Package commands vary. On Ubuntu and Debian-derived systems, an administrator may use:

sudo apt update
apt list --upgradable
sudo apt upgrade

apt update refreshes package metadata; it does not install upgrades. Review prompts and release notes on production systems. Do not paste third-party repository commands or remote scripts into a privileged shell unless you have verified the source and understand every step.

A safe troubleshooting ladder

1. Write the exact symptom, time and expected behavior.
2. Confirm the current directory, user and environment.
3. Reproduce once with the smallest input.
4. Read the command’s exit status and error output.
5. Inspect relevant files, permissions, capacity and logs.
6. Change one variable.
7. Run the same verification again.
8. Record the result and restore the previous state if the change failed.

This process is slower than guessing for the first minute and much faster over an hour. It also creates evidence another person can review.

Common Linux mistakes

• Running a copied command with sudo before understanding it.
• Using recursive delete, move or permission changes with an unverified path.
• Assuming filenames never contain spaces or special characters.
• Editing system configuration without a backup and syntax check.
• Restarting a service before reading its logs.
• Changing several settings at once and losing the ability to identify the cause.
• Disabling security controls to make an error disappear.

Practice project: build a read-only system report

Create a script that writes the timestamp, hostname, kernel version, uptime, memory summary and filesystem capacity to a dated file under ~/linux-lab/reports. It should create the directory if missing, refuse to overwrite an existing report and return a non-zero status if a required command fails.

Add a README, an example report with private host details removed, and three tests: normal execution, a pre-existing output file and an unwritable destination. This is a better portfolio artifact than a command list because it demonstrates input handling, safe output and verification.

Continue learning

Use these terminal foundations in the DevOps learning path, the cloud computing course and the cybersecurity course.

Official references

• Ubuntu Server: command-line cheat sheet
• Ubuntu Server: terminal tutorial
• GNU Coreutils manual
• systemd: journalctl manual
• Linux man-pages: systemctl