grep: Editing text on the command line
grep searches and filters. It doesn't edit anything. This article explains what grep actually does, how you combine it with other commands to modify files, and why that combination gives you more control than a direct edit ever would.
REQUIREMENTS
- A Linux or Unix environment with grep installed (grep 3.11 or newer).
- Access to a terminal.
- Basic knowledge of the command line: navigating, viewing files.
- Optional: a Dutch manpage, available via
man grepin Debian trixie.
STEPS
1. Search for a pattern in a file.
The simplest form: grep "error" logfile.txt shows all lines in logfile.txt that contain the word "error". Grep reads the file, filters the lines, and prints them to the terminal. The original remains untouched.
grep "error" logfile.txt
This is a read-only operation. You can't break anything with it, which makes it a safe first step in any analysis.
2. Redirect the output to a new file.
grep prints to stdout. With > you capture that output and write it to a file. This way you create a filtered copy without modifying the original.
grep "error" logfile.txt > errors.txt
Note: > overwrites an existing file. If you want to append to an existing file, use >>. The original remains intact, which makes this approach suitable for safely splitting logs.
3. Combine grep with pipes.
The real power lies in the pipe (|). It sends the output of one command as input to the next. This way you filter not only files, but also the output of other commands.
sudo dmesg | grep net
This command shows only kernel messages that contain the word "net". With network problems, you immediately see the relevant lines instead of the full dmesg output. This works with any command that writes to stdout: ps, ss, journalctl, you name it.
4. Use regular expressions for more precise patterns.
Grep accepts regular expressions. Where grep "error" only finds the exact word, grep "^error" searches for lines that start with "error". The caret (^) is an anchor that marks the beginning of a line.
grep "^error" logfile.txt
Regular expressions make grep a precision tool. You can search with them for word boundaries, repetitions, or character classes. The syntax is extensive, but the basics can be learned in an afternoon.
5. Show only the number of matches.
Sometimes you don't want to know which lines match, but how many there are. The -c flag counts them.
grep -c "error" logfile.txt
This is faster than counting in an editor and suitable for scripting. Combine it with a pipe to count in the output of another command.
6. Search recursively in a directory structure.
With -r, grep scans all files in a directory and its subdirectories. This is indispensable when searching through configuration directories or source code.
grep -r "timeout" /etc/
Grep shows the filename and the line for each match. Note: -r does not follow symlinks. Use -R if you want to follow them too. This takes more time, but is more thorough.
7. Show context around a match.
A single line often doesn't say enough. With -C 3, grep shows three lines before and after each match. This way you see the context of an error message without opening the entire file.
grep -C 3 "error" logfile.txt
This is standard in any log analysis. If you only want lines after (-A) or before (-B), you can use those flags separately.
8. Modify a file via a workaround.
Grep itself cannot modify a file. But by writing the filtered output to a temporary file and copying it back, you achieve the same effect.
grep -v "debug" logfile.txt > tmp.txt && mv tmp.txt logfile.txt
The -v flag inverts the match: grep shows everything except lines with "debug". You write the result to tmp.txt, and mv replaces the original. This is a manual implementation of what sed does in one step — for one-off edits it's fine. For repeated edits, sed is faster and less error-prone.
VERIFICATION
Check that grep works correctly:
grep --version
This shows the version, for example grep (GNU grep) 3.11. To check whether a filter has been applied correctly:
grep -c "debug" logfile.txt
If this shows 0 after step 8, all lines with "debug" have been removed. You can also use diff to compare the original and the result:
diff logfile.txt tmp.txt
No output means the files are identical — or that grep found nothing.
COMMON PROBLEMS
1. Grep finds nothing, but the text is there.
Check whether the pattern is not a regular expression that you meant literally. The dot (.) matches any character, and the caret (^) marks the beginning of a line. Use grep -F to treat the pattern literally, or escape the special characters with a backslash.
2. Grep complains about "Binary file matches".
Grep recognizes binary files and refuses to show the output. Use grep -a to treat the file as text, or grep -I to skip binary files. The first option is risky with large binary files — the output can be unreadable.
3. The output of grep is too large to read.
Pipe the output to less to browse, or to a file to analyze later. grep "error" logfile.txt | less is the quickest solution for long outputs.
---
Grep is not a text processor. It is a filter. And filters are most valuable when you combine them: with pipes, with redirection, with other tools. History does not help here — that grep emerged from the ed editor in the 1960s explains the name g/re/p, but not why you would use it today. What does matter: grep is on every server, in every container, on every network device. It is part of the POSIX standard and present on nearly every Linux installation.
Whoever masters grep searches logs in seconds that an editor would take minutes to handle. Whoever combines grep with sed or awk edits files without opening them. The question is not whether you need grep. The question is how long you will work without it.