Linux regular expressions-write Regular Expressions

Linux regular expressions-write Regular Expressions

For all practical purposes, you can use programs to produce correct results. However, it does not mean that the program always works as correctly as you wish. In most cases, if the program cannot produce the desired output, you can determine how the real problem (excluding input or syntax errors) describes what you want.

In other words, the problem should be corrected by describing the expression of the expected result. The expression is incomplete or the formula is incorrect. For example, if the program calculates the following expression:
PAY = WEEKLY_SALARY * 52

And know the value of these variables, it will calculate the correct result. However, some people will disagree, because the formula does not indicate the salesperson, and he also gets a commission. Therefore, to describe this situation, this expression needs to be represented by the formula again:
PAY = WEEKLY_SALARY * 52 + COMMISSION

You may think that the person who writes the first expression does not fully understand the scope of the problem, so it cannot be well described. It is important to know how to describe in detail. If you ask someone to take a book for you, and if there are many books in front of you, you need to describe the book you want more clearly (or the process of satisfying and uncertain choice ).

This also applies to regular expressions. Programs (such as grep) are simple and easy to use. It is not difficult to understand the elements of a regular expression. Regular Expressions allow you to write simple or complex schema descriptions. The factor that makes writing regular expressions difficult (and interesting) is the complexity of the application: The pattern appears in different situations and contexts. Complexity is inherent in the language itself, just as you may not always get a correct understanding of a semantic by querying the dictionary.

The process of writing a regular expression involves three steps:
1. Know the content to be matched and how it appears in the text.
2. Write a pattern to describe the content to be matched.
3. view the Matching content in test mode.

This process is essentially similar to the process of developing a program by a programmer. Step 1 can be regarded as a specification, which reflects understanding the problem to be solved and how to solve it. Step 2 is similar to writing program code, and step 3 is equivalent to running the program and testing it according to the specification. Steps 2 and 3 need to be repeated until the program is satisfied.

Testing the matching description ensures that the description is the same as expected. It usually reveals some surprising things. Check the test results, comparison output, and input carefully, which greatly improves the understanding of the regular expression. You can parse the results of the pattern match as follows:
Hits (hit)
-- This is the line I want to match.
Misses (not hit)
-- This is the line I don't want to match.
Omissions (omitted)
-- This is the row that I cannot match but want to match.
False alarms (False alarm)
-- This is a line that I don't want to match but matches.

Try to improve the description of the pattern can also be resolved from the opposite segment; you can try to eliminate false alarms by limiting possible matches, and usually extend the possible matches to try to capture omissions.

It is especially difficult to use a fixed string description mode. Deleting each character from the fixed string mode increases the number of possible matches. For example, if you search for a string "what" and decide to match "What", the only fixed string pattern that matches "What" and "what" at the same time is "hat ", that is, the longest string shared by the two. Obviously, searching for "hat" will produce unwanted matches. Adding each character to the fixed string mode may reduce the number of matching characters. The string "them" is generally less matched than the string ".