Linux Fundamentals

Overview

Almost everything distinctive about working with Linux happens through a small set of composable command-line building blocks: navigating and manipulating files, understanding the permission model that decides who can do what to them, inspecting and controlling running processes, and configuring the networking and background services a machine actually runs. Every other Linux topic on this site - the Filesystem Hierarchy Standard, process management internals, storage, networking, users and groups, logging - goes deep on one of these areas. This one is the map: the everyday commands from each area, in the shape you'll actually reach for them, before you need the deeper dive.

Quick Reference

The commands below are grouped by task, not alphabetically - not exhaustive (see the GNU Coreutils manual for every flag), but the set that covers almost all daily shell work.

Syntax

command [options] [arguments]
# e.g.
grep -r --include="*.log" "ERROR" /var/log/app

# Chaining: pipe output from one command into the next
# The [n]ode bracket trick keeps grep's own process out of its own match
ps aux | grep [n]ode | awk '{print $2}'

Examples

find /var/log -name "*.log" -mtime -1
grep -c "ERROR" /var/log/app/current.log

journalctl -u nginx.service --since '1 hour ago'

Visual Diagram

Common Mistakes

• Running rm -rf with a mistyped or unset variable in the path, deleting far more than intended; there is no undo, so double-check any command with -rf before running it.
• Reaching for kill -9 as the default, skipping the graceful SIGTERM shutdown that lets a process close files and finish in-flight work cleanly.
• Editing a config file directly as root over SSH without a backup, discovering a syntax error only after the service that depends on it fails to restart.
• Assuming ping succeeding means an application is reachable; it only confirms network-layer connectivity, not that any specific service is listening or healthy.
• Forgetting systemctl enable, so a manually started service works fine until the next reboot, when it silently doesn't come back.

Performance

• grep -r on a very large directory tree is far slower than a tool that respects .gitignore-style excludes; scope searches to the smallest relevant directory when possible.
• find walks the filesystem tree directly and can be slow across network mounts or very large directories; narrowing with -maxdepth or a more specific starting path helps significantly.
• Piping large outputs through several processes (ps aux | grep ... | awk ...) is usually fine, but each pipe stage is its own process; for performance-sensitive scripts, a single awk or grep invocation with the right flags often replaces a whole pipeline.

Best Practices

• Prefer systemctl enable --now over separate start/enable calls when bringing a new service into permanent use, so you never forget the reboot half of the equation.
• Use journalctl -u <service> and --since/--until filters instead of grepping through raw log files by hand.
• Reach for SIGTERM (kill, not kill -9) first, and only escalate to SIGKILL if a process genuinely won't respond after a reasonable wait.
• Test connectivity at the layer you actually care about - ss -tulpn or curl for "is this application reachable," not just ping.
• Keep destructive commands (rm -rf, chmod -R, chown -R) deliberate: confirm the target path with pwd/ls immediately before running them, especially over SSH on a remote host.