![]() ![]() Also, the match is actually not on the level of single characters but "collation elements" which means in some locales, even combinations of several letters may match (e.g. zZ so a-z would also match most upper-case letters. In other locales (and in particular in the usually set system locales such as en_US.UTF-8) the collation order is something like aAbB. Naively one might expect them to match all characters that lie between the start and end character on the ASCII table, but that is only true for the C locale. Note that you can get rid of the opening and closing anchors by using the -x flag to enforce "whole-line" matching: grep -x -E '.+' filename.txtĬharacter lists containing ranges (such as a-z) are dangerous because they might not give you what you think. You should use grep -E '^.+$' filename.txt Other characters that are special to the shell ( >, #, and the like) might lead to even more unexpected behavior. If your pattern contains $ or globbing characters ( *, ? and character lists!), the shell may try to perform variable expansion (thereby replacing parts of your RegEx) or expand globbing patterns into possibly multiple filenames, so that in the end you would have more arguments on the command-line that you originally intended. That means any characters are open to interpretation by the shell before they are passed to the grep command. In your example, you use the regular expression unquoted. (1)for what it might actually do, see below
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |