Regular expression to match a line that doesn't contain a word
I know it's possible to match a word and then reverse the matches using other tools (e.g.
grep -v). However, is it possible to match lines that do not contain a specific word, e.g.
hede, using a regular expression?
hoho hihi haha hede
grep "<Regex for 'doesn't contain hede'>" input
hoho hihi haha
The notion that regex doesn't support inverse matching is not entirely true. You can mimic this behavior by using negative look-arounds:
The regex above will match any string, or line without a line break, not containing the (sub)string 'hede'. As mentioned, this is not something regex is "good" at (or should do), but still, it is possible.
And if you need to match line break chars as well, use the DOT-ALL modifier (the trailing
s in the following pattern):
or use it inline:
/.../ are the regex delimiters, i.e., not part of the pattern)
If the DOT-ALL modifier is not available, you can mimic the same behavior with the character class
A string is just a list of
n characters. Before, and after each character, there's an empty string. So a list of
n characters will have
n+1 empty strings. Consider the string
┌──┬───┬──┬───┬──┬───┬──┬───┬──┬───┬──┬───┬──┬───┬──┬───┬──┐ S = │e1│ A │e2│ B │e3│ h │e4│ e │e5│ d │e6│ e │e7│ C │e8│ D │e9│ └──┴───┴──┴───┴──┴───┴──┴───┴──┴───┴──┴───┴──┴───┴──┴───┴──┘ index 0 1 2 3 4 5 6 7
e's are the empty strings. The regex
(?!hede). looks ahead to see if there's no substring
"hede" to be seen, and if that is the case (so something else is seen), then the
. (dot) will match any character except a line break. Look-arounds are also called zero-width-assertions because they don't consume any characters. They only assert/validate something.
So, in my example, every empty string is first validated to see if there's no
"hede" up ahead, before a character is consumed by the
. (dot). The regex
(?!hede). will do that only once, so it is wrapped in a group, and repeated zero or more times:
((?!hede).)*. Finally, the start- and end-of-input are anchored to make sure the entire input is consumed:
As you can see, the input
"ABhedeCD" will fail because on
e3, the regex
(?!hede) fails (there is
"hede" up ahead!).
Read more... Read less...
Note that the solution to does not start with “hede”:
is generally much more efficient than the solution to does not contain “hede”:
The former checks for “hede” only at the input string’s first position, rather than at every position.
If you're just using it for grep, you can use
grep -v hede to get all lines which do not contain hede.
ETA Oh, rereading the question,
grep -v is probably what you meant by "tools options".
^the beginning of the string,
( group and capture to \1 (0 or more times (matching the most amount possible)),
(?! look ahead to see if there is not,
hede your string,
) end of look-ahead,
. any character except \n,
)* end of \1 (Note: because you are using a quantifier on this capture, only the LAST repetition of the captured pattern will be stored in \1)
$ before an optional \n, and the end of the string
The given answers are perfectly fine, just an academic point:
Regular Expressions in the meaning of theoretical computer sciences ARE NOT ABLE do it like this. For them it had to look something like this:
This only does a FULL match. Doing it for sub-matches would even be more awkward.
If you want the regex test to only fail if the entire string matches, the following will work:
e.g. -- If you want to allow all values except "foo" (i.e. "foofoo", "barfoo", and "foobar" will pass, but "foo" will fail), use:
Of course, if you're checking for exact equality, a better general solution in this case is to check for string equality, i.e.
myStr !== 'foo'
You could even put the negation outside the test if you need any regex features (here, case insensitivity and range matching):
The regex solution at the top of this answer may be helpful, however, in situations where a positive regex test is required (perhaps by an API).