ls -laExample: Use this inside a directory when you need permissions, ownership, and hidden files in one view.
Gotcha: Directory listings can be aliased in your shell. If output looks unusual, check your aliases.
Use this page for common Linux tasks that come up during development, deployment, and troubleshooting. Each entry favors the task wording people actually search for.
ls -laExample: Use this inside a directory when you need permissions, ownership, and hidden files in one view.
Gotcha: Directory listings can be aliased in your shell. If output looks unusual, check your aliases.
du -sh *Example: Useful when you need to spot the largest folders in the current location quickly.
Gotcha: This excludes hidden entries. Use `du -sh .[!.]* *` if you also need hidden items and your shell supports that safely.
ps aux | grep nginxExample: Useful when you need to confirm whether a service or script is running.
Gotcha: This will also show the `grep` process itself. Use a more precise pattern or `pgrep` when available.
kill 12345Example: Use the default signal first before moving to a forceful kill.
Gotcha: Prefer `kill` before `kill -9`. A forceful signal can skip cleanup logic and leave partial state behind.
tar -czf backup.tar.gz app/ storage/Example: A practical way to package project files for backup or transfer.
Gotcha: Be explicit about included paths so you do not accidentally archive unnecessary directories like `node_modules`.
A Linux command reference is most valuable when it helps you answer operational questions fast: what is taking disk space, which process owns a port, what permissions does this file have, where is the log I need, and what changed in the current directory tree? This page is for that layer of work. It favors commands you can apply immediately in local development environments, servers, containers, and CI shells.
If you have searched for Linux Commands, Unix/Linux Command Reference, Linux Complete Command Reference, or even community recommendations for a solid Linux command reference, you probably want a practical shortlist rather than an encyclopedia. That is the goal here.
| Task | Command | What it tells you |
|---|---|---|
| Show current directory | pwd |
Confirms where you are before you act |
| List files with details | ls -lah |
Size, mode bits, ownership, hidden files |
| Find large directories | du -sh * | sort -h | Fast disk-usage triage |
| Check free disk space | df -h | Filesystem capacity and pressure |
| View running processes | ps aux | Snapshot of processes and owners |
| Search open ports | ss -tulpn | Listening sockets and bound programs |
| Show file ownership | stat file.txt | Permissions, timestamps, inode details |
| Follow logs | tail -f app.log | Live view of a changing log file |
```bash
pwd
ls -lah
du -sh ./*
df -h
ps aux | grep myservice
ss -tulpn | grep 8080
```
This sequence is intentionally boring. That is a feature. In Linux work, boring commands prevent expensive mistakes. You verify location, list what exists, estimate space, check overall disk pressure, inspect processes, and then confirm port usage. That flow solves many “something is wrong on this box” moments without touching configuration yet.
Much of Linux administration is really about understanding who can read, write, or execute a path. ls -l gives you a first pass, but stat is often the clearer command when timestamps and exact metadata matter. chmod changes permission bits, and chown changes owner and group. These are powerful commands, so the reliable workflow is: inspect, verify the target path, then apply the narrowest change possible.
Remember that directories behave differently from files. Execute permission on a directory affects traversal. Read permission affects listing. That is why a file might look readable while the path above it blocks access. A good Linux command reference keeps those everyday details visible.
When a service appears unhealthy, three questions usually matter first:
ps, ss, and tail form a dependable answer path. On systems using systemd, journalctl often becomes the next step, especially if logs are not written to a file directly. On containerized systems, you may pair these habits with runtime-specific tooling, but the Linux side of the inspection logic stays similar.
| Habit | Why it helps |
|---|---|
Run pwd before destructive commands |
Prevents acting in the wrong location |
Use ls or find before rm or chmod -R |
Confirms the target set |
| Prefer explicit paths in scripts | Reduces accidental scope expansion |
Inspect with du before cleaning disk |
Shows what is actually large |
Filter ps and ss output thoughtfully |
Avoids chasing the wrong process |
A solid reference organizes commands by task, not alphabetically only. You need to move from “I have a disk problem” or “a port is occupied” to the right inspection command immediately.
Start with navigation and inspection: pwd, ls, cd, cat, grep, find, du, df, ps, ss, and tail. These commands solve a wide range of real issues before you ever need more specialized tools.
The overlap is large enough for daily work. Many practical references mix the two because the shell habits transfer well. What matters is understanding the behavior on the actual system in front of you.
Inspect first, modify second. Verify the current directory, verify the target path, and then make the smallest possible change.
Use the Bash reference for shell composition and loops, the Git reference when filesystem changes are happening inside a repository, the Developer Reference Hub to switch domains quickly, or the Vim reference when you move from inspection into editing.
Strong Linux command habits are less about memorizing exotic tools and more about sequencing simple ones well. Read the directory before changing it. Read the service state before restarting it. Read disk usage before deleting anything. A practical reference earns its place by reinforcing that order every time.
A short Linux reference stays valuable because it reduces hesitation. When you are on a remote host, inside a container, or troubleshooting under time pressure, clarity matters more than completeness. The best command is often the simple one that confirms the next step safely.
Make everything as simple as possible, but not simpler.