Regular Expressions Cookbook

4.11. Validate Affirmative Responses

Problem

You need to check a configuration option or command-line response for a positive value. You want to provide some flexibility in the accepted responses, so that true, t, yes, y, okay, ok, and 1 are all accepted in any combination of uppercase and lowercase.

Solution

Using a regex that combines all of the accepted forms allows you to perform the check with one simple test.

Regular expression

^(?:1|t(?:rue)?|y(?:es)?|ok(?:ay)?)$

Regex options: Case insensitive

Regex flavors: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby

JavaScript

var yes = /^(?:1|t(?:rue)?|y(?:es)?|ok(?:ay)?)$/i;

if (yes.test(subject)) {
    alert("Yes");
} else {
    alert("No");
}

Other programming languages

See Recipes 3.4 and 3.5 for help implementing this regular expression with other programming languages.

Discussion

The following breakdown shows the individual parts of the regex. Combinations of tokens that are easy to read together are shown on the same line:

^            # Assert position at the beginning of the string.
(?:          # Group but don't capture...
  1          #   Match a literal "1".
 |           #  or...
  t(?:rue)?  #   Match "t", optionally followed by "rue".
 |           #  or...
  y(?:es)?   #   Match "y", optionally followed by "es".
 |           #  or...
  ok(?:ay)?  #   Match "ok", optionally followed by "ay".
)            # End the noncapturing group.
$            # Assert position at the end of the string.

Regex options: Case insensitive, free-spacing

Regex flavors: .NET, Java, PCRE, Perl, Python, Ruby

This regex is essentially a simple test for one of seven literal, case-insensitive values. It could be written in a number of ways. For example, ‹^(?:[1ty]|true|yes|ok(?:ay)?)$› is an equally good approach. Simply alternating between all seven values as ‹^(?:1|t|true|y|yes|ok|okay)$› would also work fine, although for performance reasons it’s generally better to reduce the amount of alternation via the pipe ‹|› operator in favor of character classes and optional suffixes (using the ‹?› quantifier). In this case, the performance difference is probably no more than a few microseconds, but it’s a good idea to keep regex performance issues in the back of your mind. Sometimes the difference between these approaches can surprise you.

All of these examples surround the potential match values with a noncapturing group to limit the reach of the alternation operators. If we omit the grouping and instead use something like ‹^true|yes$›, the regex engine will search for “the start of the string followed by ‘true’” or “‘yes’ followed by the end of the string.” ‹^(?:true|yes)$› tells the regex engine to find the start of the string, then either “true” or “yes”, and then the end of the string.

See Also

Recipes 5.2 and 5.3