Literal characters
Write a pattern, match text
A regular expression is a sequence of characters that specifies a match pattern in text. You build one by combining literal characters, metacharacters and classes, then test it against lines that should match and lines that should not.
Literal characters
Dot
Repetition operators
Character class
Anchors
Alternation and grouping
A regular expression is a sequence of characters that specifies a match pattern in text.
The string you type is read by the engine left to right. Literal characters must appear verbatim; metacharacters instruct the engine to repeat, group, anchor or choose. The engine reports a match at the first position where the whole pattern can be satisfied.
Because the pattern is a specification rather than a search string, the same characters can carry two meanings. The dot matches any character in most engines, but a dot inside a character class or preceded by a backslash behaves differently. Knowing which mode you are in is the first matching rule you need.
Look up each symbol in the syntax table before you use it, because two symbols can look similar and behave differently.
A dot stands for any single character except a newline in most engines. The star repeats the preceding element zero or more times, the plus one or more times, and the question mark zero or one time. A character class in square brackets matches one character from the listed set.
Anchors do not consume characters; they assert a position. The caret asserts the start of a line, the dollar sign the end. Alternation with a vertical bar lets the engine try either branch, and grouping with parentheses makes a repeated unit larger than one character.
The engine scans candidate positions and accepts the first one where every token in order is satisfied.
Backtracking is the common strategy: when a repetition consumes too much input and a later token fails, the engine gives back one character and tries again. This is why a greedy star can swallow a suffix you meant to keep, and why an anchored pattern can be much faster than an unanchored one.
Anchoring early in the pattern cuts the number of candidate positions. A pattern that must match at the start of a line tests one position per line instead of every position, which is the difference between a search that returns in milliseconds and one that stalls on a large file.
Each card covers one token type with its matching rule and one-line example.
Write the literal text first, then add one feature at a time and re-test after each change.
Start with the exact substring you want, escape any character that has a special meaning, and confirm the pattern matches. Only then introduce a character class for the parts that vary, and only after that add repetition. Anchor the pattern last, once the body already matches the right lines.
At each step, test against a set of matching lines and a set of non-matching lines. A pattern that matches everything is as wrong as one that matches nothing; the failure modes differ but both mean the same thing: the specification is incomplete.
| Year or period | What happened | Why it matters now |
|---|---|---|
| 1950s | Stephen Cole Kleene formalized the concept of a regular language | The theoretical notation the modern tokens descend from |
| 1968 | Ken Thompson built Kleene's notation into the editor QED | First popular use: pattern matching in a text file |
| 1968 | Regular expressions entered popular use in a text editor and in lexical analysis in a compiler | Two uses that set the shape of modern engines |
| 1980s | Different syntaxes existed, among them the IEEE POSIX basic and extended standards | A parallel standard family still found in system tools |
| 1986 | Henry Spencer wrote a regex library that Perl originally derived from | The origin of the Perl-style token set |
| 1997 | Philip Hazel began developing PCRE, Perl Compatible Regular Expressions | A widely distributed attempt to mimic Perl's functionality |
The list below collects the documented milestones cited on this page.