grep Command in Linux with Examples

Logs, configuration files, and command output get noisy fast; the grep command in Linux cuts them down to the lines that match a word, phrase, or regular expression. Use grep when triaging service failures, checking configuration drift, or validating deployment output without opening an editor.

Most systems already include GNU grep, while minimal containers and BusyBox environments may expose a smaller implementation. Once availability is clear, the same patterns cover OR searches, first-match limits, recursive scans, binary-file handling, and regular expressions.

For stream editing or live log monitoring, pair grep with sed command examples or tail for real-time log watching to build repeatable troubleshooting workflows.

Understand the grep Command

What grep Means and How It Works

If grep is new to you, think of it as a command-line search engine for plain text. The name stands for “Global Regular Expression Print,” which describes exactly what it does. It processes text globally using patterns, then prints matching results. It scans input line by line, compares each line against a pattern, and prints only the matches unless you ask for the inverse.

Basic Syntax and Components

grep [OPTIONS] PATTERN [FILE...]

Before layering on options, break down the syntax:

• OPTIONS: Flags that adjust behavior, such as -i for case-insensitive matches or -R for recursive directory traversal.
• PATTERN: The text or regular expression you want to match. Use -F when you need a literal string match.
• FILE…: One or more files to scan. When omitted, grep reads from standard input, making it useful in pipelines.

grep 'nginx' /etc/nginx/nginx.conf

For example, that simple command prints every line in /etc/nginx/nginx.conf that contains the word nginx, preserving the surrounding text for quick inspection.

Common grep Options Reference

Task	Command Pattern	What It Does
Ignore character case	grep -i 'error' file	Matches the pattern regardless of case, useful for logs with inconsistent capitalization.
Match whole words only	grep -w 'root' file	Prevents false matches such as root matching rootkit.
Match exact lines	grep -x 'PermitRootLogin no' file	Prints only lines that match the full pattern from start to end.
Search for OR conditions	grep -E 'error|warning' file	Uses extended regular expressions so either alternative can match.
Show line context and numbers	grep -n -C 2 'pattern' file	Adds line numbers plus two lines before and after each match.
Search directories selectively	grep -R --include '*.py' 'pattern' path	Walks subdirectories while limiting matches to selected file types.
List matching files	grep -R -l 'pattern' path	Prints filenames instead of every matching line.
Print only matching text	grep -o 'regex' file	Returns just the portion of each line that matches.
Limit to first matches	grep -m 10 'pattern' file	Stops after the first 10 matching lines in each searched file.
Handle binary files	grep -a or grep -I	Treats binary input as text with -a or suppresses binary matches with -I.

Check and Install the grep Command on Linux

Most general-purpose Linux installations ship with GNU grep. Minimal containers, Alpine-based images, and rescue environments may expose only BusyBox grep or no standalone package, so check the implementation first.

grep --version

Relevant output starts with:

grep (GNU grep) 3.x

If the command is missing, or if BusyBox lacks a GNU-only option you need, install the distro package that provides GNU grep.

Ubuntu and Debian-Based Distributions

sudo apt update
sudo apt install grep

GNU grep lives in the grep package, so the standard apt workflow reinstalls or updates it on demand.

Fedora

sudo dnf install grep

Fedora’s grep package provides the GNU implementation, including the GNU-only options covered later.

RHEL, Rocky Linux, AlmaLinux, and CentOS Stream

sudo dnf install grep

These distributions also use dnf, so the same install command applies.

Arch Linux and Manjaro

sudo pacman -S grep

Pacman keeps GNU grep in sync with the core toolchain packages on rolling-release systems.

openSUSE Leap and Tumbleweed

sudo zypper install grep

Zypper installs the GNU grep build packaged for your release channel.

Alpine Linux

sudo apk add grep

BusyBox grep supports common options such as -i, -E, -F, -m, and context flags, but it does not support every GNU option. Install the grep package on Alpine when you need GNU-only options such as -P, --include, --exclude-dir, or --line-buffered.

Gentoo

sudo emerge --ask sys-apps/grep

Gentoo installs GNU grep from the sys-apps/grep package selected by your configured repositories and USE flags.

Void Linux

sudo xbps-install -S grep

Void’s XBPS package manager pulls the pre-built GNU grep binary and registers it in the system package database.

Essential grep Command Examples

Example 1: Search logs for case-insensitive errors

When triaging application crashes or service failures, highlight any line that mentions an error, regardless of how the application cased it.

grep -i --color=auto 'error' /var/log/syslog

Here, the -i flag matches ERROR, Error, and similar variants, while --color=auto highlights the hits when you are working interactively.

2025-11-05T10:23:45.123456+00:00 server systemd[1]: Failed to start nginx.service: Unit nginx.service not found.
2025-11-05T10:24:12.456789+00:00 server kernel: [  123.456789] usb 1-1: device descriptor read/64, error=-110
2025-11-05T10:25:33.789012+00:00 server sshd[1234]: error: PAM: Authentication failure for user admin from 192.168.1.100

The highlighted lines show three separate services reporting issues on November 5, 2025: systemd cannot find the nginx unit, the kernel records a USB timeout, and SSH reports a failed login for admin, confirming the command zeroed in on critical events.

Example 2: Audit SSH configuration lines quickly

Check if root login is disabled without scrolling through the entire configuration file. This is particularly useful when hardening servers or auditing security policies across multiple systems.

grep -n 'PermitRootLogin' /etc/ssh/sshd_config

In this case, the -n option prints the line number, so you can jump straight to the relevant stanza in your editor if changes are required.

32:PermitRootLogin no

Because -n is enabled, the output reports that line 32 explicitly disables root logins, so you know exactly where the directive lives in sshd_config.

Example 3: Show lines after a match

When diagnosing application failures, see what the program attempted immediately after an error to understand the cascading effects.

grep -A 4 'Exception' /var/log/application.log

The -A 4 flag prints four lines after each match, revealing stack traces, retry attempts, or error handling that followed the exception. This context often pinpoints whether the application recovered gracefully or crashed completely.

2025-11-05 14:23:45 ERROR Exception in thread "main" java.lang.NullPointerException
    at com.example.App.processData(App.java:45)
    at com.example.App.main(App.java:12)
    at java.base/java.lang.Thread.run(Thread.java:829)
2025-11-05 14:23:46 INFO Retrying operation in 5 seconds...

The exception stack trace shows exactly where the Java application crashed, and the trailing INFO line confirms a retry kicked in immediately after the error, illustrating how -A 4 surfaces post-failure behavior.

Example 4: Show lines before a match

Understand what led to a specific event by examining the preceding log entries.

grep -B 5 'Connection timeout' /var/log/nginx/error.log

The -B 5 option displays five lines before the timeout, typically showing the request URL, client IP, and any warnings that preceded the failure. This historical context helps identify whether timeouts correlate with specific endpoints or user agents.

2025-11-05 14:22:10 [warn] 1234#1234: *5678 upstream server temporarily disabled while reading response header from upstream, client: 203.0.113.45, server: api.example.com, request: "POST /api/v1/process HTTP/1.1", upstream: "http://127.0.0.1:8080/api/v1/process", host: "api.example.com"
2025-11-05 14:22:08 [info] 1234#1234: *5678 client 203.0.113.45 closed keepalive connection
2025-11-05 14:22:05 [info] 1234#1234: *5678 client sent HTTP/1.1 request, server: api.example.com, request: "POST /api/v1/process HTTP/1.1"
2025-11-05 14:22:05 [info] 1234#1234: *5678 using configuration ""
2025-11-05 14:22:05 [info] 1234#1234: *5678 client connected from 203.0.113.45
2025-11-05 14:22:15 [error] 1234#1234: *5678 Connection timeout

Reading from the bottom up, you see the client connect, send a POST request, trigger an upstream warning, and ultimately hit a timeout. This is exactly the context -B 5 is designed to surface before the failure itself.

Example 5: Show lines surrounding a match

When investigating HTTP errors, see what happened immediately before and after a failing request. This is especially useful when log rotation means you cannot scroll backward through live output.

grep -C 2 ' 404 ' /var/log/nginx/access.log

In this example, the -C 2 flag prints two lines of context on both sides of the match, giving you a complete picture of the request sequence without overwhelming output.

203.0.113.12 - - [05/Nov/2025:15:30:22 +0000] "GET /api/users/12345 HTTP/1.1" 200 234 "-" "Mozilla/5.0 (compatible; API-Client/1.0)"
203.0.113.12 - - [05/Nov/2025:15:30:23 +0000] "GET /api/users/99999 HTTP/1.1" 404 152 "-" "Mozilla/5.0 (compatible; API-Client/1.0)"
203.0.113.12 - - [05/Nov/2025:15:30:24 +0000] "POST /api/users HTTP/1.1" 201 456 "-" "Mozilla/5.0 (compatible; API-Client/1.0)"
203.0.113.12 - - [05/Nov/2025:15:30:25 +0000] "GET /api/users/99999 HTTP/1.1" 404 152 "-" "Mozilla/5.0 (compatible; API-Client/1.0)"
203.0.113.12 - - [05/Nov/2025:15:30:26 +0000] "GET /health HTTP/1.1" 200 2 "-" "ELB-HealthChecker/2.0"

The 404 response is sandwiched between successful 200 and 201 calls, so the context from -C 2 confirms the same client retried the missing user twice before the load balancer health check succeeded.

Example 6: Match exact configuration lines

When validating configuration files, ensure a directive appears exactly as required, with no extra parameters or trailing comments.

grep -x 'PermitRootLogin no' /etc/ssh/sshd_config

The -x flag matches only lines that contain exactly “PermitRootLogin no” with no additional characters. This catches configuration drift where someone appended comments or extra whitespace that might break parsing in stricter contexts.

PermitRootLogin no

A single matching line means there are no duplicate directives or trailing comments. Your configuration enforces PermitRootLogin no exactly as required.

Example 7: Walk project trees and limit to specific file types

When refactoring a codebase, track down deprecated API usage without searching through build artifacts or dependency caches.

grep -R --include '*.py' -n 'requests.get' ~/projects/app

Here, -R follows subdirectories, --include '*.py' keeps the focus on Python modules, and -n shows exactly where to refactor.

src/api/client.py:45:    response = requests.get(f"https://api.example.com/users/{user_id}")
src/services/payment.py:123:    result = requests.get("https://payment.example.com/verify", params=payload)
src/utils/helpers.py:78:    data = requests.get(config.API_BASE_URL + "/status").json()

Each match reports the relative path, line number, and Python code still calling requests.get, so you can jump straight to the refactor targets.

Example 8: Count literal strings in authentication logs

After a security incident or during routine audits, check how many failed login attempts occurred during a specific timeframe so you can notify the security team or adjust firewall rules.

grep -F -c 'Failed password' /var/log/auth.log

In this command, the -F flag treats the phrase as plain text, avoiding regular expression quirks, and -c returns the number of matching lines.

47

The counter shows 47 failed password events in the log window you searched, which is a clear signal to tighten access controls or investigate the source IPs.

On Fedora, RHEL, Rocky Linux, and AlmaLinux, point the command at /var/log/secure, which stores the same authentication events for RPM-based systems.

Example 9: Exclude noisy lines with inverse matches

Strip out comments or status messages when you only care about active configuration directives.

grep -Ev '^[[:space:]]*(#|$)' /etc/ssh/sshd_config

In this example, -v inverts the match, -E enables the OR expression, and ^[[:space:]]*(#|$) matches comments or blank lines. Pair the same pattern with other filters to reject maintenance banners or health checks in log streams.

Include /etc/ssh/sshd_config.d/*.conf
Port 22
AddressFamily any
ListenAddress 0.0.0.0
ListenAddress ::
PermitRootLogin no
StrictModes yes
MaxAuthTries 6
MaxSessions 10

With comments stripped, you are left with only active directives, making it easy to audit listener addresses, authentication limits, and security settings currently enforced by SSH.

Example 10: List only files that contain a pattern

Before rotating API keys or updating credentials, quickly identify which project files still reference legacy secrets.

grep -R --exclude-dir=.git --exclude-dir=node_modules -l 'API_KEY' .

Here, the -l option prints only filenames, while --exclude-dir filters out version control and dependency caches.

config/database.php
src/services/PaymentService.php
.env.production

The filenames make it obvious which application layers still reference API_KEY, so you can rotate secrets confidently without grepping through vendor folders.

Example 11: Match against a maintained pattern file

When managing firewall rules or monitoring suspicious activity, keep an organized blocklist of known malicious IPs or error codes and reuse it across deployments without hardcoding patterns into scripts.

grep -f blocklist.txt /var/log/nginx/access.log

In this scenario, -f blocklist.txt tells grep to read patterns from a file, so you can update the list without editing your command history.

185.220.101.45 - - [05/Nov/2025:16:45:12 +0000] "GET /wp-admin.php HTTP/1.1" 404 162 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
203.0.113.195 - - [05/Nov/2025:16:47:33 +0000] "POST /xmlrpc.php HTTP/1.1" 403 162 "-" "Mozilla/5.0 (compatible; Nmap Scripting Engine; http://nmap.org/book/nse.html)"
45.146.164.110 - - [05/Nov/2025:16:52:01 +0000] "GET /.env HTTP/1.1" 404 162 "-" "python-requests/2.25.1"

Every line corresponds to a blocklisted IP making a suspicious request, so you can quickly decide whether to escalate, block at the firewall, or review WAF rules.

Example 12: Filter command output in pipelines

Trim systemd journal output so only meaningful disconnect events reach your pager. Some distributions use sshd.service instead of ssh.service, so adjust the unit name if needed.

journalctl -u ssh.service | grep -F 'Disconnected from user'

In this pipeline, piping journal output into grep keeps live sessions readable, and the -F switch avoids regular expression interpretation when matching log phrases.

Nov 05 17:12:45 server sshd[2345]: Disconnected from user admin 203.0.113.12 port 22
Nov 05 17:15:23 server sshd[2346]: Disconnected from user developer 203.0.113.45 port 22
Nov 05 17:18:01 server sshd[2347]: Disconnected from user root 203.0.113.67 port 22

The filtered journal stream now shows only disconnect events, making it easy to track whose sessions are closing and from which IPs without the rest of the systemd noise.

Example 13: Match whole words to avoid false positives

When searching security logs for specific user activity, prevent partial matches that pollute your results. For instance, searching for “root” without word boundaries also matches “rootkit”, “groot”, or “chroot”.

grep -w 'root' /var/log/auth.log

The -w flag ensures grep only matches “root” as a standalone word, bounded by spaces, punctuation, or line edges. This reduces noise when auditing user authentication or searching code for specific variable names.

Nov  5 18:23:45 server sshd[3456]: Accepted publickey for root from 192.168.1.10 port 22 ssh2: RSA SHA256:abc123...
Nov  5 18:24:12 server sudo:     admin : TTY=pts/0 ; PWD=/home/admin ; USER=root ; COMMAND=/usr/bin/apt update
Nov  5 18:25:33 server sshd[3457]: Failed password for root from 203.0.113.45 port 22 ssh2

By matching the whole word “root,” you get legitimate and failed root activity without stray results like chroot, giving you a clean audit trail to review.

Example 14: Search for OR Conditions with grep

Instead of running separate grep commands for different severity levels, combine them into a single OR search through your logs.

grep -E 'ERROR|CRITICAL|FATAL' /var/log/application.log

With -E, the pipe character | means OR, so grep prints lines that match any listed severity. For plain fixed strings, repeated -e options such as grep -e 'ERROR' -e 'CRITICAL' file are also valid.

2025-11-05 19:15:22 ERROR Database connection failed: timeout after 30 seconds
2025-11-05 19:16:45 CRITICAL Memory allocation failed in worker process 3
2025-11-05 19:17:12 ERROR Authentication service unavailable
2025-11-05 19:18:33 FATAL Configuration file corrupted, shutting down

The output keeps the events in chronological order while flagging three severity levels, so you can correlate related incidents across your monitoring dashboards.

Example 15: Print the First 10 grep Matches

To print the first 10 matching lines, use grep -m 10 'pattern' file. This is different from head -n 10 file, which prints the first 10 lines of the file whether they match or not.

grep -m 10 'Connection refused' /var/log/nginx/error.log

The -m 10 option tells grep to stop after finding 10 matching lines, saving time and keeping your terminal readable. This is especially useful with context flags like -A or -C that multiply output volume.

2025-11-05 20:01:15 [error] 1234#1234: *1234 connect() failed (111: Connection refused) while connecting to upstream, client: 203.0.113.12, server: api.example.com
2025-11-05 20:01:16 [error] 1234#1234: *1235 connect() failed (111: Connection refused) while connecting to upstream, client: 203.0.113.34, server: api.example.com
2025-11-05 20:01:17 [error] 1234#1234: *1236 connect() failed (111: Connection refused) while connecting to upstream, client: 203.0.113.56, server: api.example.com
2025-11-05 20:01:18 [error] 1234#1234: *1237 connect() failed (111: Connection refused) while connecting to upstream, client: 203.0.113.78, server: api.example.com
2025-11-05 20:01:19 [error] 1234#1234: *1238 connect() failed (111: Connection refused) while connecting to upstream, client: 203.0.113.90, server: api.example.com
2025-11-05 20:01:20 [error] 1234#1234: *1239 connect() failed (111: Connection refused) while connecting to upstream, client: 203.0.113.12, server: api.example.com
2025-11-05 20:01:21 [error] 1234#1234: *1240 connect() failed (111: Connection refused) while connecting to upstream, client: 203.0.113.34, server: api.example.com
2025-11-05 20:01:22 [error] 1234#1234: *1241 connect() failed (111: Connection refused) while connecting to upstream, client: 203.0.113.56, server: api.example.com
2025-11-05 20:01:23 [error] 1234#1234: *1242 connect() failed (111: Connection refused) while connecting to upstream, client: 203.0.113.78, server: api.example.com
2025-11-05 20:01:24 [error] 1234#1234: *1243 connect() failed (111: Connection refused) while connecting to upstream, client: 203.0.113.90, server: api.example.com

These ten lines are the first 10 matches returned before -m 10 stops scanning, confirming the outage is widespread across many clients without drowning you in repetitive entries.

Example 16: Find running processes by name

Quickly identify which processes are running under a specific user or contain a particular keyword in their command line by pairing ps with grep.

ps aux | grep -w '[n]ginx'

The bracket trick inside [n]ginx keeps grep from matching its own process while -w limits results to whole-word matches. This leaves only the nginx master and worker processes in the output.

root         1233  0.0  0.1  15440  3820 ?        Ss   10:15   0:00 nginx: master process /usr/sbin/nginx -g daemon off;
www-data     1234  0.0  0.2  17920  5120 ?        S    10:15   0:00 nginx: worker process
www-data     1235  0.0  0.2  17920  5120 ?        S    10:15   0:00 nginx: worker process
www-data     1236  0.0  0.2  17920  5120 ?        S    10:15   0:00 nginx: worker process

The full ps rows show owners, PIDs, and command lines, so you can confirm the service spawned correctly without scrolling through unrelated daemons.

Using the grep Command with Regular Expressions

Regular expressions let grep match structure instead of only exact text. Use them when a log line, identifier, address, or configuration value follows a pattern but the exact value changes.

grep can run regex searches directly, but it is not an interactive regex tester. If a pattern becomes hard to reason about, test it against a small sample file first, then move it into the full log or project tree.

Basic Regular Expression Metacharacters

By default, grep interprets patterns as basic regular expressions where most characters match themselves, but a few special metacharacters control matching behavior:

• ^ (caret): Matches the start of a line. Use this to find configuration directives or log entries that begin with specific keywords.
• $ (dollar): Matches the end of a line. Use this to identify lines that conclude with particular error codes or status messages.
• . (period): Matches any single character except newline, which helps when you know the shape but not the exact value.
• [ ] (brackets): Matches any one character from the enclosed set. For example, [aeiou] matches any vowel.
• [^ ] (negated brackets): Matches any character not in the set. For instance, [^0-9] matches anything except digits.

Example 1: Find lines starting with specific text

Locate configuration directives that aren’t commented out by searching for lines beginning with the directive name.

grep '^Port ' /etc/ssh/sshd_config

The caret ensures grep only matches “Port” at the beginning of lines, skipping commented entries like # Port 22 or inline documentation mentioning port numbers.

Port 22

The match confirms the live configuration sets SSH to listen on port 22 and that the directive isn’t commented out elsewhere in the file.

Example 2: Find lines ending with specific patterns

Identify log entries that terminated with certain exit codes or status indicators.

grep 'failed$' /var/log/deployment.log

This pattern catches lines ending in “failed” but skips entries like “failed to connect” or “failure detected” that contain the word mid-line.

2025-11-05 21:15:33 Database migration failed
2025-11-05 21:16:12 Service startup failed
2025-11-05 21:17:45 Health check failed

Only lines that end with the word “failed” remain, which helps you isolate final status messages instead of every log entry that merely mentions failure mid-sentence.

Example 3: Match flexible character patterns

When you know the structure but not the exact values, use bracket expressions to match variations.

grep 'error[0-9]' /var/log/syslog

This matches “error0” through “error9”, capturing numbered error categories without listing each variant separately. Combine character classes with other metacharacters for sophisticated pattern matching.

2025-11-05T22:10:15.123456+00:00 server app[1234]: error1: Invalid configuration parameter
2025-11-05T22:11:22.456789+00:00 server app[1234]: error2: Database connection timeout
2025-11-05T22:12:33.789012+00:00 server app[1234]: error3: File system permission denied

The numbered error classes (error1, error2, error3) all match the character range, proving the regex captured every severity bucket without separate searches.

Extended Regular Expressions with -E

For more complex patterns, use the -E flag to enable extended regular expressions, which add operators like +, ?, |, and () without requiring backslash escaping.

grep -E 'warning|error|critical' /var/log/application.log

The pipe operator | works as logical OR, matching any of the specified alternatives. This is cleaner than using multiple -e flags and supports grouping for complex expressions.

If grep 'warning|error' file returns nothing, the command is treating | as a literal character. Add -E, or use separate -e patterns when you do not need a full regular expression.

Example 4: Extract email addresses from files

Combine extended regex with the -o flag to pull structured data from unstructured text.

grep -Eo '[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}' contacts.txt

This pattern captures common email formats, and -o prints only the matched addresses rather than entire lines. It does not cover every possible address format, but it handles standard addresses you are likely to encounter in logs or configuration files.

admin@company.com
support@linuxcapable.com
user.name+tag@example.org
contact@subdomain.example.net

The regex extracts just the email addresses, even ones with plus tags or subdomains, so you can feed the results directly into alerts or scrub them from files.

Advanced grep Command Techniques

Example 1: Preserve safe filenames with find and xargs

Scan entire log archives, even when paths include spaces or unusual characters, by combining grep with find (see our find exec command option guide).

find /var/log -type f -name '*.log' -print0 | xargs -0 grep -H 'panic'

In this command, -print0 and -0 keep null-terminated filenames intact, while -H prints the filename with every match. This pattern is safer than using shell globbing when directory trees contain unpredictable filenames.

/var/log/kern.log:2025-11-05T23:15:22.123456+00:00 server kernel: [ 1234.567890] Kernel panic - not syncing: Fatal exception
/var/log/syslog:2025-11-05T23:15:22.123456+00:00 server kernel: [ 1234.567890] Kernel panic - not syncing: Fatal exception
/var/log/application.log:2025-11-05 23:16:45 ERROR Application panic: unrecoverable state detected

The filename prefix on each line proves -H survived the find/xargs pipeline, letting you see that multiple logs recorded the same panic at the same timestamp.

Example 2: Search compressed logs without extracting

Many rotation policies gzip older logs. Instead of decompressing to disk, use the helper utilities to search compressed files directly.

zgrep -i 'timeout' /var/log/nginx/access.log.1.gz

Here, zgrep wraps grep with on-the-fly decompression, so you can mix it into scripts that sweep historical data.

203.0.113.12 - - [04/Nov/2025:14:22:15 +0000] "GET /api/slow-endpoint HTTP/1.1" 504 162 "upstream timeout" "Mozilla/5.0"
203.0.113.45 - - [04/Nov/2025:14:23:30 +0000] "POST /api/heavy-processing HTTP/1.1" 504 162 "gateway timeout" "API-Client/1.0"
203.0.113.67 - - [04/Nov/2025:14:24:45 +0000] "GET /api/database-query HTTP/1.1" 504 162 "database timeout" "Web-App/2.1"

Even though the file is compressed, zgrep returns full log lines showing three timeout responses from distinct clients on November 4, 2025. That keeps historical incident reviews in the terminal without creating temporary extracted copies.

Example 3: Use Perl-compatible regular expressions for complex rules

Validate IPv4 addresses or other structured tokens with richer pattern syntax.

grep -Po '((25[0-5]|2[0-4][0-9]|1?[0-9]{1,2})\.){3}(25[0-5]|2[0-4][0-9]|1?[0-9]{1,2})' firewall.log

In this example, the -P flag enables PCRE support, while -o prints only the matched IP address. The alternating ranges keep each octet between 0 and 255, so bogus values such as 999.999.999.999 never slip through. Use GNU grep rather than BusyBox grep when a pattern depends on -P.

192.168.1.10
203.0.113.45
10.0.0.1
172.16.0.100

The PCRE pattern strips everything except valid IPv4 addresses, giving you a clean list you can feed into blocklists or inventory reports.

Example 4: Short-circuit scripts with quiet matches

Use grep as a guard clause inside automation so jobs fail fast when prerequisites are missing.

if grep -q 'DATABASE_URL' .env; then
    echo 'Environment ready'
else
    echo 'DATABASE_URL missing' >&2
    exit 1
fi

In this script, -q suppresses normal output and exits with a status you can test in pipelines or CI jobs.

Example 5: Search binary files as text

Occasionally you need to search compiled binaries, database dumps, or other non-text files for specific strings like version numbers, configuration paths, or embedded credentials.

grep -a 'VERSION' /usr/bin/application

The -a flag forces grep to treat the binary as text, displaying matching lines despite the presence of null bytes and control characters. Output may contain unprintable characters, but this technique can reveal embedded strings without a separate tool like strings.

VERSION=2.1.4-build.2025.11.05

Even though /usr/bin/application is a binary, -a surfaced the embedded version string so you can verify the build without launching the program.

Use -I for the opposite behavior when you want to suppress Binary file ... matches messages and skip binary files during broad scans.

grep -I 'VERSION' /usr/bin/application

Performance Optimization Tips

When working with large log files or processing high-throughput streams, these two adjustments can improve grep performance.

• Set LC_ALL=C before heavy searches on ASCII data to speed up pattern matching by disabling locale-specific processing.
• Prefer -F when you do not need regular expressions. Literal matching is faster and avoids accidental metacharacter expansions.

Troubleshoot Common grep Command Errors

Fix grep No Such File or Directory Errors

If the path is wrong, the shell expands a glob to a missing file, or a log does not exist on your distro, grep prints a file error before it searches anything.

grep: /var/log/application.log: No such file or directory

Confirm the path first, then search the file that actually exists. Quote paths that contain spaces so the shell passes them to grep as one argument.

ls -l '/var/log/app logs/application.log'
grep 'ERROR' '/var/log/app logs/application.log'

When the file exists, ls -l shows a normal file row and grep moves on to matching content instead of failing at the path stage.

Fix grep Permission Denied Errors

System logs such as authentication or web-server logs may be readable only by root or a service group.

grep: /var/log/auth.log: Permission denied

Check the file ownership, then use sudo only for files that require elevated read access.

ls -l /var/log/auth.log
sudo grep -F 'Failed password' /var/log/auth.log

A successful search prints matching log lines. If no lines appear, the command ran correctly but the searched phrase was not present in that file.

Fix grep OR Patterns That Return No Matches

Plain grep uses basic regular expressions, so an unescaped pipe character is treated literally instead of as OR.

grep 'ERROR|CRITICAL' /var/log/application.log

If that command returns no output, enable extended regular expressions or repeat -e for each pattern.

grep -E 'ERROR|CRITICAL' /var/log/application.log

Relevant output includes the matching severity lines:

ERROR Database connection failed
CRITICAL Memory allocation failed

Fix grep Binary File Matches Messages

When grep sees null bytes or other binary data, it may avoid printing unreadable output and show a binary-file notice instead.

Binary file application.db matches

Choose the behavior you want: -I suppresses binary-file matches during broad scans, while -a treats binary input as text when the embedded string matters.

grep -I 'VERSION' application.db
grep -a 'VERSION' application.db

If -I stays quiet, the binary was skipped. If -a prints a line, inspect it carefully because control characters can make binary output hard to read.

Fix grep invalid option — P on BusyBox

BusyBox grep supports many common flags, but it does not support GNU grep -P for Perl-compatible regular expressions.

grep: invalid option -- 'P'

Use grep -E when extended regular expressions are enough. Install GNU grep when a pattern genuinely needs PCRE syntax.

grep -E 'warning|error|critical' application.log

Verify the implementation afterward. GNU builds identify themselves with grep (GNU grep) in the first version line.

grep --version

grep (GNU grep) 3.x

Conclusion

grep is ready to turn noisy files and streams into targeted matches: exact strings, OR patterns, context windows, recursive scans, and binary-file checks. Keep -F for literal text, -E for readable alternation, and -m when you only need the first hits; pair it with tail or find when logs or directory trees get larger.