This series is dedicated to exploring little-known—and occasionally useful—trinkets lurking in the dusty corners of UNIX-like operating systems.

Imagine, if you will, a Jane Austen novel about three sisters. The first is well-known and celebrated by everyone; the second, while slightly smarter and more capable, is significantly less popular; and the third languishes in near-total isolation and obscurity. These three sisters live on any UNIX-like system, and their names are grep , egrep , and fgrep .

We will assume you are already familiar with grep — egrep works pretty much the same, except she handles e xtended regular expression syntax. (When writing shell scripts intended to be portable, be careful to call egrep if your expression uses + , ? , | , or braces as metacharacters. Some versions of GNU grep make no distinction between basic and extended regular expressions, so you may be surprised when your script works on one system but not another.)

But our subject for today is poor, unnoticed fgrep . While the plainest sister of the three, she really doesn't deserve to be ignored. The "f" in her name stands either for f ixed-string or f ast, depending on who you ask. She does not handle regular expressions at all; the pattern she is given is taken literally. This is a great advantage when what you are searching for contains characters having special meaning in a regular expression.

Suppose you have a directory full of PHP scripts and want to find references to an array element called $tokens[0] . You can try grep (note that the single quotes are necessary to prevent the shell from interpreting $tokens as a shell variable):

$ grep '$tokens[0]' *.php

But there is no output. The reason is that the brackets have special significance to grep ; [0] is interpreted as a character class containing only 0. Therefore, this command looks for the string $tokens0 , which is not what we want. We would have to escape the brackets with backslashes to get the correct match (some implementations may require you to escape the dollar sign also):

$ grep '$tokens\[0\]' *.php
parser.php:   $outside[] = $tokens[0];

Instead of fooling with all that escaping (which might get tedious if our pattern contains many special characters), we can just use fgrep instead:

$ fgrep '$tokens[0]' *.php
parser.php:   $outside[] = $tokens[0];

One place where fgrep can be particularly handy is when searching through log files for IP addresses. With ordinary grep , the pattern 43.2.1.0 would match 43.221.0.123, 43.2.110.123, and a bunch of other IP addresses you're not interested in because the dot metacharacter will match any character. To make sure you only matched a literal dot you'd have to escape each one with a backslash or, better yet, use fgrep .

But what about the claim that fgrep is fast? On GNU systems, there is usually one single binary that changes its behavior depending on whether it is called as grep , egrep , or fgrep . (Actually, this is in line with the POSIX standard ¹ , which deprecates egrep and fgrep in favor of a single grep command taking the -E option for using extended regular expressions and the -F option for doing fixed-string searches.)

In testing, we found that when specifying a single pattern on the command line, fgrep wasn't really any faster than grep . However, when using the -f option to specify a file containing a list of a couple dozen patterns, fgrep could consistently produce a 20% time savings. On systems where grep and fgrep are different binaries, there can potentially be a more dramatic difference in speed and even memory usage.

In our hypothetical Austen novel, the neglected sister would probably be driven to a bad end, to be only spoken of afterward in hushed whispers. Don't let that happen! Whenever you need to search for a string, but don't require the power of regular expressions, get into the habit of calling on fgrep . She can be very helpful and deserves more attention than she gets. You'll save yourself the trouble of worrying about metacharacters and maybe some running time as well.

References:

1. Grep specification https://pubs.opengroup.org/onlinepubs/009695399/utilities/grep.html#tag_04_63_18

This article was originally written in June 2010. The podcast episode was recorded in February 2026.