I've typed rsync -avz and tar -czvf so many times that my fingers do it without asking my brain first. That's the problem. Muscle memory gets the command to run, but it never told me what those letters actually switch on, or what the defaults quietly did behind my back.
So I spun up a throwaway Debian 13 container alongside the Proxmox LXCs that run my entire home lab and put four everyday terminal commands through their paces: rsync, find, sort, and tar. Some of what I found was a little embarrassing, especially since I need rsync as my only backup tool most days. For example, sort told me a 1.1GB file was the smallest thing in a folder, and I'd trusted it for years.
rsync's -a flag does far more than most people realize
Plain -r skipped my symlink and reset every timestamp
The -a in rsync -avz is archive mode, and it's shorthand for seven other flags: -rlptgoD. That's recursion plus symlinks, permissions, times, group, owner, and devices. I'd never thought about it until I copied the same folder twice, once with -a and once with plain -r.
The -r copy printed a warning I'd have scrolled past on a busy day: skipping non-regular file. My symlink was gone, and every file was stamped with the time of the copy, so a note last touched in January 2025 suddenly looked brand new. To be fair to -r, it kept the 600 permissions on a private file, so it isn't losing everything. But a backup that forgets links and dates isn't much of a backup.
--dry-run and -i show exactly what --delete is about to remove
--delete is the flag that turns rsync into a true mirror, and it's also the one most likely to ruin your afternoon. Pair it with --dry-run and -i (itemize changes), and rsync tells you exactly what it would do without touching a byte. Each line gets an 11-character code, where the first character is the action, the second is the file type, and the rest flag what changed.
In my test, *deleting docs/stray.txt warned me about a file it was about to remove, and >f..t...... told me notes.txt only differed by its timestamp. It reads like gibberish for about five minutes. After that, I can't imagine running --delete without it.
--partial saved the 444MB a Ctrl+C would have thrown away
I throttled a 1GB copy to 20MB/s with --bwlimit and killed it at 40%. Without --partial, rsync quietly deleted the 431MB it had already copied, leaving an empty folder. With -P, which is --partial plus --progress, it kept 444MB on disk, dated January 1, 1970 (the Unix epoch), meaning its timestamp was set to zero.
The resume is where it got interesting. The full 1GB finished in 30 seconds at 33.82MB/s, which is impossible through a 20MB/s cap unless rsync reused what was already there. One catch tripped me up, though: rsync treats local copies as whole-file transfers by default, so I needed --no-whole-file to make it pick up the partial file.
-x keeps a backup of / out of /proc and /sys
This one is for anyone backing up a whole system. A dry run of / counted 120,592 files, while the same run with -x (stay on one filesystem) counted 43,132. The difference is roughly 77,000 entries from /proc, /sys, and /dev, and nobody wants those in a backup.
find already does the work I was piping into other tools
-exec with + ran echo once instead of 1,000 times
Most people learn find -exec with the \; ending, which runs the command once for every single file. Swap it for +, and find packs as many files as it can into each run. Counting output lines made it obvious, with 1,000 runs of echo using \; and exactly one using +.
Timing ls -l across the same 1,000 files took 0.348 seconds with \; and 0.006 seconds with +, roughly 58 times faster. Sure, that's milliseconds on a test folder. But the gap grows with every file, and nearly all of it is the cost of starting a new process each time.
-prune checked 11 entries where -not -path checked 20,011
To skip a folder like node_modules, I used to filter it out with -not -path. That hides the folder from the output, but find still walks every file inside it. -prune tells find not to go in at all.
I logged every entry find touched with -fprint, and the difference was absurd. Both commands found the same six files, but -not -path visited 20,011 entries to get there, while -prune visited 11. I also learned the hard way that adding any action like -fprint or -exec switches off find's default output, so my first attempt printed a big fat zero until I added -print back.
-printf and -newer replace ls, stat, and guesswork
GNU find can format its own output, so -printf '%TY-%Tm-%Td %10s %m %p\n' prints the date, size, octal permissions, and path in tidy columns without a pipe in sight. It's a GNU extension, so don't expect it from the find that ships with macOS.
-newer answers "what changed since?" by comparing against a marker file, and -newermt does the same with a date. After I edited one file, -newer returned exactly that file and nothing else. Its folder didn't show up, because appending to a file doesn't change the folder's timestamp.
sort was quietly getting my lists wrong
sort -n thinks a 1.1GB file is the smallest thing in the folder
This is the one that stung. I piped du -sh into sort -n to find the biggest folders, and the 1.1GB ISO landed at the top as if it were the smallest. -n only reads the leading number, so 1.1 comes before 2.0, 12, and 46, and the G, K, and M suffixes are ignored entirely.
sort -h understands human-readable sizes and puts everything in the right order. It's one letter, and I'd been getting this wrong for years.
Using -V sorts version numbers the way humans read them
Plain sorting compares text, so app-1.10 lands before app-1.2, and app-10.1 lands before app-2.0. -V treats the numbers as numbers and gives you a release history that actually makes sense.
--debug showed me what sort was really comparing
--debug underlines the part of each line sort actually used, and it exposed two things I never asked for. When scores tied, sort broke the tie by comparing the whole line alphabetically, a last-resort rule most people never see.
It also printed "failed to set locale" at the top, meaning sort had silently fallen back to plain byte comparison. That's harmless on my test data, but with accented or mixed-case text, the same command can sort differently on another machine. Without --debug, I'd never have known.
-s keeps the order your first sort worked for
I sorted a roster by score, then by team, expecting each team to stay ranked by score. Without `-s`, that hidden tiebreaker scrambled it, and the red team came out with an 85 above a 90. Adding `-s` (stable sort) put the 90 back on top.
The cleaner fix is a single pass with two keys. sort -t, -k2,2 -k3,3nr sorts by team, then by score in reverse, and gets the same result in one command.
tar no longer needs me to remember compression letters
-a picks the compressor from the file name, and reading needs no flag at all
I've lost count of how often I've typed -z when I meant -J. With -a (auto-compress), tar picks the compressor from the file name, so tar -caf archive.tar.gz makes gzip and tar -caf archive.tar.xz makes xz. Checking the first bytes of each file confirmed it, with gzip's signature on one and xz's on the other.
Reading is even easier, because tar detects compression on its own. tar -tf listed my .tar.xz without -J, and tar -xf works the same way.
--strip-components, -C, and --transform reshape archives on the fly
--strip-components=1 drops the top-level folder on extraction, and -C sends the files wherever you want without a cd. My archive's src/ wrapper vanished, leaving the docs and photos folders right where I wanted them.
--transform works in the other direction, renaming paths as they go into an archive with sed-style syntax. Mine turned every src/ path into backup-2026/, which beats renaming a folder just to archive it.
Reading the flags beat installing another tool
Most advice about a better terminal tells you to install fd, bat, or some other shiny replacement. Every fix here was already sitting in commands I use daily, waiting behind a letter I'd never bothered to look up.
If you only steal two Linux terminal habits from this, make them --dry-run before anything destructive and --debug when the output looks off. Then dig through your shell history and aliases for rsync -avz and tar -czvf, and ask yourself whether you know what every letter does. I didn't, and I'm better off for finding out.