grep command: cheat sheet for -i, -v, -r and regex

Short answer: grep PATTERN FILE prints every line in FILE that matches PATTERN. Pipe anything into it to filter command output the same way: ps aux | grep nginx, journalctl | grep error. The flags people reach for constantly are -i (ignore case), -v (invert — show lines that don’t match), -r (recurse into a directory) and -n (show the line number).

grep nginx /etc/services                 # lines containing "nginx"
ps aux | grep nginx                       # filter a command's output
grep -rn "TODO" ./src                     # recurse a directory, with line numbers

Every flag below was checked against GNU grep’s man page on Debian 12.

Cheat sheet: the flags you actually use

-i and -v: the two most common flags

-i ignores case in both the pattern and the input, so grep -i error matches Error, ERROR and error alike. -v inverts the match entirely — it prints every line that does not contain the pattern, which is the usual way to strip noise out of a log before reading it:

journalctl -u nginx | grep -vi "GET /health"   # hide routine health checks

Recursive search: -r, and narrowing it

grep -rn "function deploy" ./app

Plain -r follows symlinks only when they are named directly on the command line, reads every file it finds, and silently skips binary files by default unless they look like they contain only text — a binary match prints binary file FILENAME matches instead of the line itself. Narrow a big tree before it gets slow or noisy:

grep -rn --include='*.ts' "TODO" ./src              # only .ts files
grep -rn --exclude-dir={node_modules,.git} "TODO" .  # skip whole directories
grep -rln "console.log" ./src                        # filenames only, for piping into another command

egrep -r and fgrep -r still work on Debian and Ubuntu for backward compatibility, but they are deprecated upstream in favour of grep -Er and grep -Fr.

Basic vs extended regex: -E, and why + and | need it

Plain grep uses Basic Regular Expressions (BRE) by default, where +, ?, | and parentheses are literal characters unless you escape them with a backslash. -E (or the egrep alias) switches to Extended Regular Expressions (ERE), where those characters work unescaped — the form most people expect from other tools:

-F is the opposite move: it turns off regex interpretation entirely and matches the pattern as a literal string, which is what you want for a pattern containing ., [, $ or other characters that mean something in a regex but nothing in your search term — a literal IP address or a file path, for instance.

Colour, context lines and line numbers

grep -n --color=always "error" app.log | less -R

grep auto-colours matches when writing straight to a terminal and turns colour off automatically once the output is piped — --color=always overrides that, which is why it shows up paired with less -R (the flag that tells less to render colour codes instead of showing them as literal escape sequences). For context around a match rather than just the matching line itself:

grep -B 2 -A 5 "panic" app.log    # 2 lines before, 5 lines after
grep -C 3 "panic" app.log         # 3 lines of context on both sides

grep in a pipeline

Three combinations come up constantly on a server:

ps aux | grep '[n]ginx'                 # the [n] trick excludes grep's own matching line
sudo ss -tlnp | grep ':443'             # what is listening on port 443
history | grep rsync                    # find a command you ran before

ps aux | grep nginx on its own always matches one extra line — the grep nginx process itself, since ps sees it too. Writing the first character of the pattern as a single-character bracket expression, [n]ginx, matches the literal character n but no longer matches the literal string nginx that appears in grep’s own command line, so it drops out of the results. pgrep nginx avoids the whole problem by not matching itself in the first place; see finding and killing a process for that approach when the goal is a PID rather than just a count.

grep’s exit status, in scripts

grep returns 0 when it finds at least one match, 1 when it finds none, and 2 on an actual error (a missing file, bad syntax). That makes it useful directly inside a condition, with -q to suppress the output you don’t need:

if grep -q "^export PATH" ~/.bashrc; then
  echo "already set"
else
  echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
fi

When grep isn’t the right tool

• Structured logs (JSON, columns). grep matches text, not fields — jq for JSON or awk for columns will get you the actual field instead of a line that happens to contain the right string.
• Watching a growing log live. Pair it with tail -f: tail -f /var/log/nginx/error.log | grep --line-buffered error (--line-buffered stops grep from waiting to fill an output buffer before printing, which otherwise delays matches on a live stream).
• High CPU from a process you found with grep. See VPS high CPU usage for what to do once you’ve identified it, and checking disk usage if you were grepping logs because the disk is filling up.

Frequently asked