What is it? #
Almost everything you do on a server involves files: reading configuration, checking logs, copying a release, finding where something lives.
The commands are few and they compose well. Navigate with cd and ls, inspect with cat, less, head and tail, manage with cp, mv, mkdir and rm, and search with find and grep.
Two of them deserve caution. rm -rf deletes without confirmation and without a recycle bin, and mv silently overwrites an existing destination.
The search commands are what save real time. Being able to find every file modified today, or every config mentioning a port, turns a long hunt into one line.
Think of it like this #
A filing cabinet with no undo drawer. Moving papers around is easy; shredding them is instant and permanent.
Which is why experienced people check what they are pointing at before pulling the lever.
Simple example #
A deployment failed. You need to find which configuration file mentions the old port, check when it was last modified, look at the end of a large log, and see what is filling the disk.
Code #
# Moving around and looking
cd /var/www/app # change directory
cd - # back to the previous directory
ls -lah # long listing, all files, human-readable sizes
tree -L 2 # two levels deep, if tree is installed
# Reading files
cat config.yml # whole file (small files only)
less /var/log/syslog # page through; / to search, q to quit
head -20 access.log # first 20 lines
tail -50 error.log # last 50 lines
tail -f error.log # follow as it grows — the most used log command
# Creating, copying, moving, deleting
mkdir -p releases/2026/09 # create nested directories
cp -r config/ config.backup/ # copy a directory
mv old-name.conf new-name.conf # rename or move (overwrites silently)
rm file.txt # delete a file
rm -rf directory/ # delete a directory and contents — no undo
# Safer habits
cp config.yml config.yml.bak # keep a copy before editing
ls /path/to/delete # look before you rm -rf
rm -i file.txt # prompt before deleting
# Finding things
find /etc -name "*.conf" # by name
find /var/log -type f -mtime -1 # modified in the last day
find /var/www -size +100M # larger than 100 MB
find . -name "*.log" -delete # find and delete (check first!)
grep -r "8080" /etc/nginx/ # search file contents recursively
grep -rn "DATABASE_URL" . --include="*.py" # with line numbers, filtered
grep -i "error" app.log | tail -20 # case-insensitive, last 20
# What is using the disk?
du -sh /var/* | sort -rh | head # biggest directories under /var
du -h --max-depth=1 /var/log | sort -rh # drill down
df -h # free space per filesystem
Wildcards and paths
* any characters *.log
? one character log?.txt
{a,b} either file.{yml,yaml}
~ your home directory ~/app
. current directory
.. parent directory
How it works #
ls -lah is the everyday listing: long format shows permissions, owner and size; -a includes hidden files starting with a dot, which is where most configuration hides; -h makes sizes readable.
less is preferable to cat for anything large, because cat dumps the whole file into your terminal. Inside less, / searches, G jumps to the end and q quits.
tail -f follows a file as it grows. It is the single most used command when watching a service during a deploy or reproducing a bug.
mkdir -p creates intermediate directories and does not complain if they already exist, which makes it safe in scripts.
mv overwriting silently is worth internalising. There is no confirmation, and the destination file is simply gone.
find filters by name, type, age and size, and can act on the results. Always run it without -delete first to see what it matches.
grep -rn searches recursively and prints line numbers, which is how you locate a setting across a configuration tree.
du -sh /var/* | sort -rh | head answers "what is filling the disk" in one line. It is usually logs, an old release directory, or a database file.
Real-world use #
Disk full is one of the most common server incidents, and it is usually logs or Docker images. du narrows it down in seconds, and log rotation prevents the repeat.
tail -f on an application log during a deployment is the standard way to confirm a release started cleanly.
grep -r through /etc is how you answer "where is this configured", which is faster than remembering which file owns which setting.
Making a backup copy before editing configuration is a habit that pays for itself the first time a change breaks a service at an inconvenient hour.
The famously destructive command is rm -rf with a variable that turned out to be empty. Checking the path with ls first, and quoting variables in scripts, avoids it.
Common mistakes #
- Running
rm -rfwithout checking the path first, especially with a variable. - Using
caton a huge log file and flooding the terminal. - Forgetting
-aand missing hidden dotfiles when looking for configuration. - Overwriting a file with
mvorcpbecause there is no confirmation. - Editing configuration without a backup copy.
Practice #
On a test machine, find all files under /etc modified in the last seven days, search /etc for a port number, list the five largest directories under /var, and follow a log file as it grows. Then create a nested directory, copy it, rename the copy and delete it.