Knowledge base
Linux Commands & Shell Skills
The commands and scripting habits that decide whether an administrator operates a server or fights it: search, transform, transfer, and supervise text and processes with the tools that live in every base install.
17 topics · 17 articles
- grep: Searching Linux Like a Professional
grep survives every toolchain refresh because the job never changes: find the lines that matter inside text that grows faster than…
- sed: Editing Streams Without Opening an Editor
sed edits sideways: whole streams of text pass through it, come out transformed, and no editor opens. Its reputation comes from -i…
- find: The Linux Search That Does Everything
find is the most dangerous command on a production server, and that is exactly why it deserves mastery. It enumerates, filters, an…
- awk: When Columns Become Programs
awk is what you reach for when columns become the unit of work: nginx access logs, /etc/passwd, df output, anything that lives in …
- curl: The Command-Line Web Client That Runs the Web
curl is the pocket HTTP client of every operations toolbox: diagnostic, pipeline-friendly, and honest about what came back. Its fl…
- wget: The Downloader That Never Sleeps
wget is curl for jobs measured in hours: mirrors, archives, recursive pulls, and cron batches that run while nobody watches. It re…
- ssh: The Connection That Runs Your Infrastructure
ssh is not a convenience, it is the transport every operation on every server rides on, and ~/.ssh/config is a contract with your …
- ip: The Interface Command That Replaced ifconfig
The iproute2 suite (ip, ss, and friends) replaced net-tools years ago, and half the internet is still teaching the old commands. i…
- sftp: File Transfer on an SSH Budget
sftp rides inside SSH, which is exactly why it outlived its peers: keys, chroots, jump hosts, and the audit trail all come along f…
- top vs htop vs btop: Process Monitors Compared
Every live server question starts with a process monitor, and the trio of top, htop, and btop is a readability-versus-ubiquity tra…
- tmux vs screen: Session Managers Compared
tmux and screen solve the same ancient problem: your work should not die when your network does. Sessions live on the server, surv…
- Bash Scripting: From 'works on my box' to Production
Bash earns its slot when a task is glue: orchestrate commands, wrangle simple text, and stay entirely on the box. Its industry rep…
- Python for Server Scripting: Where Bash Ends
Python shows up the moment a bash script grows hands: JSON payloads, REST calls, retries with backoff, and parsing that should not…
- Perl Scripting: The Sysadmin's Swiss Army Knife, Still Sharp
Perl earned its place by being the best text-processing tool available in the 1990s and then never left: it ships in every base in…
- htop: Reading the Server's Pulse
htop is the interactive process viewer that turned 'top' from a periodic report into a live diagnosis surface: colored meters, a s…
- tmux: Sessions That Outlive Your Connection
tmux is the terminal multiplexer that keeps long-running work alive when your SSH connection dies: a detached server process holds…
- GNU screen: The Session Wrapper That Refused to Die
GNU screen predates tmux server-client multiplexing by a decade and remains preinstalled in more rescue images, older hosts, and m…
Field notes
Command-line skill is infrastructure under all other infrastructure: every fix we ship ends up as a command sequence somewhere, whether typed at 3 a.m. or embedded in the nightly script. This category exists because those sequences are not trivia, they are reflexes, and reflexes decide whether an admin operates a server or fights it under pressure.
Stability is the quiet reason these tools matter: grep, find, awk, sed, ssh, and the ip suite have kept their interfaces across decades of kernel and distro churn. Skills written against them pay off on every distribution, every rescue console, every legacy box a client drags out of a closet. That is why we teach them ahead of whatever dashboard came out this quarter.
Production scripts differ from one-off hacks in exactly three ways: they announce intent (logging, stderr, exit codes), they refuse ambiguity (quoting, set -u, dry-run modes), and they survive their author being on vacation. Every habit in this category, the sed -i.bak suffix, the -print0 pipe, shellcheck in CI, tmux before a long deploy, exists because somewhere somebody skipped it and we paid for the pager notification.
Several topics here are honest comparisons: top against htop against btop, tmux against screen, bash against Python against Perl. Our answer is always the same shape: pick by workload and by what your team can operate half-asleep, then standardize hard. Tool debates mostly measure familiarity, not capability, and familiarity is a real production resource that budget meetings never count.
The fastest way to destroy a server is not a bad tool; it is a good tool aimed with a wrong flag: find -delete on a misquoted pattern, sed -i on the only copy, rm -rf with an unset variable. We treat every destructive line as something that runs twice, once on a copy and once for real. The habit is cheap; the lessons that taught us were not.
Related areas
Related services
Server problem? Hacked site? Slow website?
Critical issues answered within 30 minutes, 24 hours a day, 7 days a week.