When a Linux system misbehaves, good guesses aren't enough. You need fast facts, shown in plain text, right from the terminal. That's why Linux informational commands sit at the center of CompTIA A+ Core 2 (220-1202), Domain 1, Objective 1.9. These commands help you confirm what's running, what's full, and what a file contains, before you change anything.
In this guide, you'll learn what each command reveals, which common flags matter most, and how to read the output like a help desk technician. You'll also see short, realistic examples, such as checking free disk space when updates fail, or spotting a runaway process.
Commands can vary a little by distribution and version. Still, the core ideas stay the same, so your troubleshooting habits transfer well across systems.
How to read Linux command help fast (so you don't guess)
Linux commands look simple until you hit a flag you've never used. The trick is to read help the same way every time, using a clear mental model. Most commands follow this structure:
- Command: the program you run (for example,
df). - Options (flags): switches that change behavior (for example,
-h). - Arguments: the target, such as a file, directory, or device (for example,
/var/log). - Output: what the command prints, often in columns.
Once you see that pattern, new commands feel less random. For example, du -sh /var reads like a sentence: "disk usage, summarize, human-readable, for /var." That one line already tells you what it will do, before you run it.
Safe habits matter, especially in support roles. First, read the help before you run a command you don't know. Second, test on a lab VM when possible. Third, keep a "no surprises" rule on production systems. Informational commands are usually safe, yet even safe commands can produce side effects in practice (for example, a long du run can add load on a busy server).
A good workflow is simple: check syntax, run a small version of the command, then widen the scope. For instance, try du -sh /var before you scan all of / and wait ten minutes. In addition, pay attention to error lines like "Permission denied," because those tell you what data you didn't collect.
When you feel stuck, don't guess a flag. Read the help, confirm the syntax, then run the smallest safe check first.
Use man pages to confirm syntax, options, and exit status clues
The man command is the default reference for Linux tools. It answers three questions quickly: what the command does, which options exist, and what the output means. Start with man ps or man df, then scan the sections that matter.
Most man pages follow a common layout:
- NAME: a one-line summary.
- SYNOPSIS: the official syntax pattern.
- DESCRIPTION: what the command does and how options behave.
- EXAMPLES (when included): working patterns you can copy.
Inside a man page, search with /term, jump to the next match with n, and exit with q. This saves time when the page is long.
The SYNOPSIS line deserves special attention. Brackets usually mean "optional." For example, if you see [OPTION]..., you can run the command with no options, or with one, or with many. Parentheses or pipes may show choices, depending on the tool's formatting.
Man pages also hint at "exit status," which matters in scripts and troubleshooting. A command often returns 0 for success and non-zero for errors. Not every man page explains exit codes well, but when it does, you get stronger clues than the screen output alone.
If you don't remember a command name, use man -k keyword. This works like apropos on many systems. For example, man -k disk may list tools related to storage. Results vary by distro because the database depends on installed documentation.
Use simple output tricks to make results easier to scan
Terminal output can feel like a wall of text. Two small habits make it readable: paging and filtering.
Paging means sending output through a viewer like less, so you can scroll without losing your place. For example, ps aux | less lets you move through processes one screen at a time. Likewise, large help output becomes manageable when you page it.
Filtering means showing only the lines you care about. A common tool is grep, which searches text. For example, df -h | grep -i tmp limits the display to filesystems that include "tmp" in the line. The -i flag ignores case, which prevents missed matches.
These tricks are not "advanced scripting." They are basic reading aids. Still, treat filters with care. A filter can hide a line you needed, so it's smart to run the command once without filtering if the stakes are high.
Here are three practical patterns that stay readable:
ps aux | lessto scan processes without flooding your screen.df -h | grep -i hometo check space tied to user storage.man df | lesswhen your terminal doesn't keep scrollback well.
File and text viewing with cat (and what to watch out for)
The cat command prints file contents to standard output. It's simple, direct, and common in support work. If a user reports a broken app, you might check a config file line. If a network name won't resolve, you might verify /etc/hosts. If a script fails, you might confirm it still contains the right settings.
Because cat only reads and prints, it's usually safe. Even so, don't treat it as harmless in every context. First, you can expose sensitive data by printing secrets into a shared terminal session or a logged console. Second, you can freeze your session by dumping a huge file, which wastes time during an incident.
In addition, remember that reading a file doesn't mean you understand it. Some files include invisible characters that change behavior, such as stray tabs, carriage returns, or trailing spaces. Those issues appear often when a file was edited on another system.
Although Objective 1.9 focuses on informational commands, it pairs well with basic editor awareness.