A terminal is a way to ask a Linux computer precise questions and give it repeatable instructions. You do not need to memorize hundreds of commands to start doing useful work.

Series: Introduction, followed by six practical parts.
Applies to: Linux with Bash; GNU utilities unless stated otherwise.
Verification: Example output is illustrative unless explicitly labelled as locally verified. Hostnames, paths, versions and resource figures vary.

Let’s start with a familiar problem

Someone says, “The application was working yesterday.” You have a server, a directory full of logs, and a ticket that needs an answer. You could click through several dashboards. You could also ask the server where you are, which files changed, what the logs say, and whether the application is listening on its expected port.

That is where Linux commands become useful. A command is a program or shell builtin that performs a particular job. Some inspect information; others create files, start processes or change the system. The terminal displays your session, while the shell interprets what you type. Bash is one shell; Linux itself is the kernel underneath it all.

Start with a question that cannot change anything:

pwd

Illustrative output:

/home/alex

pwd means “print working directory.” Your shell has a current directory, and relative paths are interpreted from there. pwd tells you which directory that is. This matters before copying a file or reading a log: a correct command against the wrong path is still the wrong operation.

How to read a command

Most commands follow this pattern:

command options operands

In ls -l /var/log, ls is the command, -l selects a detailed listing and /var/log is the directory being inspected. Options are command-specific; the same letter can mean different things in different programs. Many GNU tools accept -- to end option processing, useful before a filename beginning with a hyphen.

Use quotes around paths and variable expansions:

ls -ld -- "My Project"

The quotes keep the space inside one argument. An unquoted * is expanded by the shell into matching filenames; a quoted '*' is a literal asterisk. Understanding that distinction prevents a surprising number of mistakes.

For builtins, try help cd. For installed programs, use man ls or ls --help. Check the manual available on your own machine when flags differ between distributions.

Make a tiny log and ask it a question

Run this in an ordinary user account. It creates a new private temporary directory and one small file; it does not touch application logs.

lab=$(mktemp -d)
printf 'INFO startup\nERROR database timeout\nINFO ready\n' > "$lab/app.log"
grep -n 'ERROR' "$lab/app.log"
wc -l < "$lab/app.log"

Expected output for this exact fixture:

2:ERROR database timeout
3

printf writes predictable text. > redirects standard output into a file and would truncate an existing destination; the fresh temporary directory makes that safe here. grep -n finds matching lines and prints line numbers. wc -l counts newline characters. We created three newline-terminated records, so it reports three.

These tools work well together because they accept and produce streams of data. A pipe connects one program’s standard output to another program’s standard input:

grep 'ERROR' "$lab/app.log" | wc -l

This reports 1. Standard error is a separate stream for diagnostics. A program also returns an exit status: zero usually means success, while nonzero needs interpretation. For example, grep uses 1 for no matches and 2 for an error. A monitoring script should distinguish those outcomes.

Why enterprises still depend on the command line

An operator can run the same observation on a development VM, a remote server and a small container image. A reviewed script can turn a repeated incident investigation into a consistent checklist. Commands are also easy to capture in runbooks, code review and automation logs.

The value is consistency, not typing speed alone. A capacity report can identify which filesystem is full, attach the findings to a ticket, and give the next shift the same starting point. A package inventory can support a patch assessment without installing anything. A bounded network check can distinguish “name resolution failed” from “TCP connection failed.”

There are limits. Command histories are not a complete audit trail. Local observations do not establish fleet-wide health. Shell scripts need input validation, error handling and appropriate permissions. At scale, approved orchestration, configuration management and observability systems help distribute the work and control access; command-line knowledge helps you understand what those systems are doing.

The six parts

  1. Directory and file operations: navigate paths and prepare a release workspace.
  2. Search and text processing: turn logs into a useful incident summary.
  3. Permissions and administrative rights: inspect access and prepare private handover files.
  4. System monitoring and process management: collect evidence before changing a running system.
  5. Networking and connectivity: follow the path from interfaces to an application endpoint.
  6. Package management: identify installed software and plan controlled changes.

Each part introduces the subsystem, explains the commands from our outline, gives examples and ends with a practical Bash script. Examples that change ownership, send signals, connect remotely or install packages are identified explicitly. Learn those on an authorized lab machine before adapting them to a work environment.

A useful first script: the support-ticket starter

Save this as ticket-starter.sh and run it with bash ticket-starter.sh. It prints a small report to your terminal. It changes no system settings and requires no administrative privileges.

#!/usr/bin/env bash
set -euo pipefail
printf 'Working directory: '
pwd
printf '\nKernel and architecture:\n'
uname -srmo
printf '\nUptime and load:\n'
uptime
printf '\nFilesystem containing this directory:\n'
df -h -- .

The working directory gives context, uname identifies the kernel environment, uptime provides uptime and load averages, and df reports the filesystem holding the current directory. Read the report before sharing it: directory names and system details can be internal information. This is an incident starting point, not a health verdict.

Next step and references

Continue with Part 1: directories and files. Keep the temporary lab directory until you are done inspecting it; no automatic cleanup is performed.

References: Bash builtins, GNU Coreutils manual, GNU grep manual.

FILED UNDER