grep and Regular Expressions

grep reads its input line by line and prints the lines that match a pattern. The pattern is a regular expression — a small language for describing sets of strings — and the same language drives sed, awk, and the search in every editor you will touch. Learn the regex model once and it pays off across the entire toolset, which is why this topic is worth more than the size of a single command suggests.

The trap is that there is no single regex. grep defaults to Basic Regular Expressions (BRE), where +, ?, |, and () are literal characters until you backslash-escape them; grep -E switches to Extended Regular Expressions (ERE), where those metacharacters are active without escaping; and grep -P hands the pattern to a Perl-compatible engine with lookarounds and non-greedy quantifiers. A pattern that works in one dialect silently matches the wrong thing — or nothing — in another. Knowing which dialect you are in is half of using grep correctly.

Basic grep

At its simplest grep PATTERN FILE prints matching lines, and with no file argument it reads standard input, which is how it lives in pipelines. The flags that matter day to day are few. -i makes the match case-insensitive, -v inverts it to print non-matching lines, -n prefixes each hit with its line number, -c prints only the count of matching lines, and -o prints just the matched text rather than the whole line — useful when you want to extract tokens, not read context.

# lines mentioning the word, case-insensitive, with line numbers
grep -in error /var/log/syslog

# everything that is NOT a comment or a blank line
grep -v '^#\|^$' /etc/ssh/sshd_config

# count failed SSH logins; -o pulls out just the matched IPs
grep -c 'Failed password' /var/log/auth.log
grep -oE '([0-9]{1,3}\.){3}[0-9]{1,3}' /var/log/auth.log

grep is line-oriented to its core: the unit of matching is a single line, and a pattern can never span a newline. Searching for foo.*bar finds foo and bar only when they sit on the same line. This is the most common surprise for people coming from editor search, and it shapes how you build pipelines — you filter lines first, then reach for sed or awk when the logic crosses line boundaries.

Regex Building Blocks

A regular expression is built from a handful of pieces. Anchors tie a match to a position: ^ is the start of the line, $ is the end, so ^root: matches only lines that begin with root:. Character classes match one character from a set: [0-9] is any digit, [a-zA-Z] any letter, [^0-9] any non-digit, and POSIX names like [[:space:]] and [[:alnum:]] stay correct across locales. A bare . matches any single character except newline.

Quantifiers control repetition. * means zero or more of the preceding atom, + one or more, ? zero or one, and {m,n} a bounded count — [0-9]{1,3} matches one to three digits. Grouping with () applies a quantifier to a whole subexpression and captures it for back-references, while alternation with | matches one branch or another: (GET|POST|PUT) matches any of the three HTTP methods. These atoms compose: ^([0-9]{1,3}\.){3}[0-9]{1,3}$ is a rough IPv4 matcher.

Construct	Meaning	Example
^ $	start / end of line	^Jan, denied$
. [...]	any char / one from a set	[0-9], [^/]
* + ?	0+, 1+, 0-or-1 repetitions	ab*, colou?r
{m,n}	bounded repetition	[0-9]{1,3}
( ) |	group / alternation	(cat|dog)s?
\b \w	word boundary / word char (PCRE)	\bsudo\b

BRE versus ERE versus PCRE

The dialect decides what needs escaping. In BRE — plain grep — the characters +, ?, {, |, (, and ) are ordinary literals, and you must write \+, \?, \{, \|, \(, \) to make them act as metacharacters. ERE — grep -E — reverses this: those characters are active by default, and you backslash them only when you want the literal. ERE is what most people picture when they think "regex," and it is the readable default for anything beyond a fixed string.

# BRE: groups and alternation need backslashes
grep '\(GET\|POST\)' access.log

# ERE: the same pattern, no backslashes
grep -E '(GET|POST)' access.log

# PCRE: lookbehind and non-greedy, unavailable in BRE/ERE
grep -P '(?<=user=)\w+' auth.log

grep -P is a different engine entirely: PCRE, the Perl-compatible library. It adds lookahead and lookbehind ((?=...), (?<=...)), non-greedy quantifiers (*?, +?), and the convenience shorthands \d, \w, \s, and \b. The cost is portability: -P is a GNU extension — the manual flags it as experimental when combined with -z — and on minimal images or BSD it may be absent. On macOS and the BSDs the default grep is the BSD implementation, where -P is unsupported entirely unless you install GNU grep. Reach for -P when ERE genuinely cannot express what you need — and not before.

Context and Recursive Search

A matching line is often useless without the lines around it. -A N prints N lines after each match, -B N N lines before, and -C N N lines on both sides — indispensable for reading a stack trace or a log event that spreads across several lines. For locating files rather than lines, -l prints only the names of files that contain a match and -L the names of files that do not.

# show the matching line plus 3 lines of trailing context
grep -A3 'Traceback' app.log

# recursive code search, only in Python files, case-insensitive
grep -rn --include='*.py' -i 'todo' ./src

# which config files reference the old hostname
grep -rl 'db-old.internal' /etc

grep -r walks a directory tree, and --include and --exclude globs narrow it to the file types you care about, while --exclude-dir=.git keeps you out of version-control noise. For searching a whole codebase this is workable, but it has no concept of a .gitignore and scans every byte of every matched file, which is exactly where the purpose-built code searchers pull ahead.

Fixed Strings and Performance

grep -F — historically the fgrep command — turns off regex entirely and treats the pattern as a literal string. Use it whenever your needle contains regex metacharacters that you mean literally: searching for an IP address 10.0.0.1, a version string 1.2.3, or a path /usr/lib/x86_64. Without -F, every . in those is a wildcard, so grep 10.0.0.1 also matches 1000x010. -F makes the match both correct and faster, because the engine can use a plain string search instead of compiling an automaton.

Performance also turns on the regex itself. Greedy quantifiers like .* backtrack hard on long lines, and a poorly bounded pattern can take seconds where a tight one takes milliseconds. Anchoring with ^ lets the engine reject most lines after the first character, and a fixed-string prefix lets it skip whole lines outright. Setting LC_ALL=C before a byte-oriented search drops Unicode collation work and speeds up large scans measurably — at the cost of locale-correct case folding, so reserve it for ASCII data.