wildcard ＆ regular expression
话说写在shell script里的东东，一旦是头头上添上了sha bang(#! /bin/bash)，通通要经过shell层层剥开皮检查一番，这样以来，参数不再是原来的参数，而是被shell解析程序施加了7层过滤的参数（7 types of expansion），这让我们在传参数时，心里很不踏实。
这里一种办法，用于区分shell展开时对文件名的处理即pathname expansion与命令中参数中常用的正则表达式的处理RE matching。
Part-I: Wildcard
首先, wildcard 也是属于 command line 的处理工序, 作用于 argument 裡的 path 之上.
没错, 它不用在 command_name 也不用在 options 上.
而且, 若 argument 不是 path 的话, 那也与 wildcard 无关.
换句更为精确的定义来讲, wildcard 是一种命令行的路迳扩展(path expansion)功能.
提到这个扩展, 那就不要忘记了 command line 的"重组"特性了!
是的, 这与变量替换(variable substitution)及命令替换(command substitution)的重组特性是一样的!
也就是在 wildcard 进行扩展后, 命令行会先完成重组才会交给 shell 来处理.
了解了 wildcard 的扩展与重组特性后, 接下来, 让我们了解一些常见的 wildcard 吧:
*: 匹配 0 或多个字元
?: 匹配任意单一字元
[list]: 匹配 list 中的任意单一字元(注一)
[!list]: 匹配不在 list 中的任意单一字元
{string1,string2,...}: 匹配 sring1 或 string2 (或更多)其一字串
(注一: list 可以为指定的个别字元, 如 abcd; 也可以为一段 ASCII 字元的起止范围, 如: a-d .)
例:
a*b: a 与 b 之间可以有任意长度的任意字元, 也可以一个也没有, 如: aabcb, axyzb, a012b, ab 等.
a?b: a 与 b 之间必须也只能有一个字元, 可以是任意字元, 如: aab, abb, acb, a0b 等.
a[xyz]b: a 与 b 之间必须也只能有一个字元, 但只能是 x 或 y 或 z, 如: axb, ayb, azb 这三个.
a[!0-9]b: a 与 b 之间必须也只能有一个字元, 但不能是阿拉伯数字, 如: axb, aab, a-b 等.
a{abc,xyz,123}b: a 与 b 之间只能是 abc 或 xyz 或 123 这三个字串之一, 如 aabcb, axyzb, a123b 这三个.
注意:
1) [! ] 中的 ! 只有放在第一顺位时, 才有排除之功. 举例说:
[!a]* 表示当前目录下所有不以 a 开首的路迳名称.
/tmp/[a/!]* 表示 /tmp 目录下以 a 或 ! 开首的路迳名称. (思考: 为何 ! 前面要加 / 呢? 提示: 十三问之 4 )
2) [ -] 中的 - 左右两边均有字元时, 才表示一段范围, 否则仅作 "-"(减号) 字元来处理. 举例说:
/tmp/*[-z]/[a-zA-Z]* 表示 /tmp 目录下所有以 z 或 - 结尾的子目录下以英文字母(不分大小写)开首的路迳名称.
3) 以 * 或 ? 开首的 wildcard 不能匹配隐藏文件(即以 . 开首的文件). 举例说:
*.txt 并不能匹配 .txt 但可匹配 1.txt 这样的路迳名称.
但 1*txt 及 1?txt 均可匹配 1.txt 这样的路迳名称.
基本上, 要掌握 wildcard 并不难, 只要多加练习, 再勤于思考, 就能熟加运用了.
再次提醒: 别忘了"扩充+重组"这个重要特性, 而且只作用在 argument 的 path 上.
比方说, 假设当前目录下有 a.txt b.txt c.txt 1.txt 2.txt 3.txt 这几份文件.
当我们在命令行中下达 ls -l [0-9].txt 的命令行时,
因为 wildcard 处于 argument 的位置上, 于是根据其匹配的路迳, 扩展为 1.txt 2.txt 3.txt ,
再重组出 ls -l 1.txt 2.txt 3.txt 这样的命令行.
因此, 你在命令行上敲 ls -l [0-9].txt 与 ls -l 1.txt 2.txt 3.txt 都是同样的结果, 其原因正是于此了... :)
2．模式表达式
模式表达式是那些包含一个或多个通配符的字。bash除支持一般通配符外，还提供了特有的扩展模式匹配表达式，其形式和含义如下：
（1）*(模式表) 匹配给定模式表中“模式”的0次或多次出现，各模式之间以“|”分开。例如，file*(.c｜.o)将匹配文件file、file.c、file.o、 file.c.c、file.0.0、file.c.o、file.o.c等，但不匹配file.h或file.s等。
（2）+(模式表) 匹配给定模式表中“模式”的1次或多次出现，各模式之间以“|”分开。例如，file+(.c | .o)匹配文件file.c、file.o、file.c.o、file.c.c等，但不匹配file。
（3）?(模式表) 匹配模式表中任何一种“模式”的0次或1次出现，各模式之间以“|”分开。例如，file?(.c｜.o)只匹配file、file.c和file.0，它不匹配多个模式或模式的重复出现，即不匹配file. c. c、file. c. 0等。
（4）@(模式表) 仅匹配模式表中给定“模式”的一次出现，各模式之间以“|”分开。例如，file@(.c｜.0)匹配file.c和file.0，但不匹配file、file.c.c、file.c.o等。
（5）!(模式表) 除给定模式表中的一个“模式”之外，它可以匹配其它任何东西。
可以看出，模式表达式的定义是递归的，每个表达式中都可以包含一个或多个模式。例如file*( .[cho]｜.sh)是合法的模式表达式。但在使用时应注意，由于带“*”和“+”的表达式可以匹配给定模式的组合，若利用此种表达式去删除文件就存在 危险，有可能误将系统配置文件删除。因此，必须小心使用。
Part-II: Regular Expression
接下来的 Regular Expression(RE) 可是个大题目, 要讲的很多, 我这裡当然不可能讲得很完全.
只希望带给大家一个基本的入门概念, 就很是足够了...
先来考一下英文好了: What is expression?
简单来说, 就是"表达", 也就是人们在沟通时所要陈述的内容.
然而, 生活中, 表达方要清楚的将意思描述清楚而让接收方完整且无误的领会, 可不是件容易的事情.
因而才会出现那麽多的"误会", 真可叹句"表达不易"啊....
同样的情形也发生在电脑的资料处理过程中, 尤其是当我们在描术一段"文字内容"的时候...
那麽, 我们不禁要问: 有何方法可以让大家的误会降至最低程度而让表达的精确度达到最高程度呢?
答桉就是"标准化"了, 亦就是我们这裡要谈的 Regular Expression 啦.... ^_^
然而, 在进入 RE 介绍之前, 不防先让我们温习一下 shell 十三问第 4 问, 也就是关于 quoting 的部份.
关键是要能够区分 shell command line 上的 meta 与 literal 这两种不同的字符类别.
然后, 我这裡才跟你讲:
--- RE 表达式裡的字符也是分为 meta 与 literal 这两种!
呵, 不知亲爱的读者是否被我搞溷乱了呢? ... ^_^
这也难怪啦, 因为这的确是最容易溷乱的地方, 刚学 RE 的朋友很多时候都死在这裡!
因此请特别小心理解哦...
简单而言, 除非你将 RE 写在特定程式使用的脚本裡,
否则, 我们的 RE 也是透过 command line 输入的.
然而, 不少 RE 所始用的 meta 字符, 跟 shell meta 字符是冲突的.
比方说, * 这个字符, 在 RE 裡是一个 modifier(后述), 在 command line 上, 却是个 wildcard !
那麽, 我们该如何解决这样的冲突呢? 关键就是看你对十三问第 4 问所提的 quoting 是否够理解了!
若你明白到 shell quoting 就是在 command line 上关闭 shell meta 这一基本原理,
那你就能很轻鬆的解决 RE meta 与 shell meta 的冲突问题了:
--- 用 shell quoting 关掉 shell meta 就是了!
就这麽简单... ^_^
再以刚提到的 * 字符为例, 若在 command line 中没有 quoting 处理的话, 如 abc* ,
那就会被作为 wildcard expansion 来扩充及重组了.
若将之置于 quoting 中, 如 "abc*", 则可避免 wildcard expansion 的处理.
好了, 说了大半天, 还没进入正式的 RE 介绍呢...
大家别急, 因为我的教学风格就是要先建立基础, 循序渐进的... ^_^
因此, 我这裡还要在囉唆一个观念, 才会到 RE 的说明啦... (哈... 别打我....)
当我们在谈到 RE 时, 千万别跟 wildcard 搞溷在一起!
尤其在 command line 的位置裡, wildcard 只作用于 argument 的 path 上.
但是 RE 却只用于"字串处理"的程式之中, 这与路迳名称一点关系也没有!
RE 所处理的字串通常是指纯文档或透过 stdin 读进的内容...
okay, 够了够了, 我已看到一堆人开始出现不大耐烦的样子了.... ^_^
现在, 就让我门登堂入室, 撩开 RE 的神秘面纱吧, 这样可以放过我了吧? 哈哈...
在 RE 的表达式裡, 主要分两种字符(character): literal 与 meta.
所谓 literal 就是在 RE 裡不具特殊功能的字符, 如 abc, 123 这些;
而 meta 在 RE 裡具有特殊的功能, 要关闭之需在 meta 前面使用 escape( / )字符.
然而, 在介绍 meta 之前, 先让我们来认识一下字符组合(character set)会更好些.
所谓的 char. set 就是将多个连续的字符作一个集合, 比方说:
abc: 表示 abc 三个连续的字符, 但彼此独立而非集合. (可简单视为三个 char. set)
(abc): 表示 abc 这三个连续字符的集合. (可简单视为一个 char. set)
abc|xyz: 表示或 abc 或 xyz 这两个 char. set 之一.
[abc]: 表示单一字符, 可为 a 或 b 或 c . (与 wildcard 之 [abc] 原理相同)
[^abc]: 表示单一字符, 不为 a 或 b 或 c 即可. (与 wildcard 之 [!abc] 原理相同)
. : 表示任意单一字符. (与 wildcard 之 ? 原理相同)
在认识了 char. set 这个概念后, 然后再让我们多认识几个 RE 中常见的 meta 字符:
- 锚点(anchor)
用以标识 RE 于句子中的位置所在. 常见有:
^: 表示句首. 如 ^abc 表示以 abc 开首的句子.
$: 表示句尾. 如 abc$ 表示以 abc 结尾的句子.
/<: 表示词首. 如 /<abc 表示以 abc 开首的词.
/>: 表示词尾. 如 abc/> 表示以 abc 结尾的词.
- 修饰字符(modifier)
独立表示时本身不具意义, 专门用以修改前一个 char. set 的出现次数. 常见有:
*: 表示前一个 char. set 的出现次数为 0 或多次. 如 ab*c 表示 a 与 c 之间可有 0 或多个 b 存在.
?: 表示前一个 char. set 的出现次数为 0 或 1 次. 如 ab?c 表示 a 与 c 之间可有 0 或 1 个 b 存在.
+: 表示前一个 char. set 的出现次数为 1 或多次. 如 ab+c 表示 a 与 c 之间可有 1 或多个 b 存在.
{n}: 表示前一个 char. set 的出现次数必须为 n 次. 如 ab{3,}c 表示 a 与 c 之间必须有 3 个 b 存在.{n,}: 表示前一个 char. set 的出现次数至少为 n 次. 如 ab{3,}c 表示 a 与 c 之间至少有 3 个 b 存在.
{n,m}: 表示前一个 char. set 的出现次数为 n 到 m 次. 如 ab{3,5}c 表示 a 与 c 之间有 3 到 5 个 b 存在.
然而, 当我们在识别 modifier 时, 却很容易忽略"边界(boundary)"字符的重要性.
以刚提到的 ab{3,5}c 为例, 这裡的 a 与 c 就是边界字符了.
若没有边界字符的帮忙, 我们很容以作出错误的解读.
比方说: 我们用 ab{3,5} 这个 RE (少了 c 这个边界字符)可以抓到 abbbbbbbbbbc (a 后有 10 个 b )这串字吗?
从刚才的 modifier 我们一般会认为我们要的 b 是 3 到 5 个, 若超出了此范围, 就不是我们要表达的.
因此, 我们或会很轻率的认为这个 RE 抓不到结果...
然而答桉却是可以的! 为甚麽呢?
让我们重新解读 ab{3,5} 这个 RE 看看:
我们要表达的是 a 后接 3 到 5 个 b 即可, 但 3 到 5 个 b 后面我们却没规定是甚麽,
因此在 RE 后面可以是任意的文字, 当然包括 b 也可以啦! (明白了吗?)
同样的, 我们用 b{3,5}c 也同样可以抓到 abbbbbbbbbbc 这串字的.
但我们若使用 ab{3,5}c 这样的 RE 时, 由于同时有 a 与 c 这两个边界字符, 那就截然不同了!
有空再思考一下, 为何我们用下面这些 RE 都可抓到 abc 这串字呢?
x*
ax*, abx*, ax*b
abcx*, abx*c, ax*bc
bx*c, bcx*, x*bc
...(还有更多...)
但, 若我们在这些 RE 前后分别加一个 ^ 与 $ 这样的 anchor, 那又如何呢?
刚学 RE 时, 只要能掌握上面这些基本的 meta 大盖就可以入门了.
一如前述, RE 是一种规范化的文字表达方式, 主要用于某些文字处理工具之间,
如 grep, perl, vi, awk, sed, 等等. 常用以表示一段连续的字串, 捕获之或替换之.
然而, 每种工具对 RE 表达式的具体解读或有一些细微差异, 不过, 基本原则还是一致的.
只要能掌握 RE 的基本原理, 那就一理通百理明了, 只是在实作时稍加变通即可.
比方以 grep 来说, 在 linux 上你可找到 grep, egrep, fgrep 这几个程式, 其差异大致如下:
* grep:
传统的 grep 程式, 在没有参数的情况下, 只输出符合 RE 字串之句子. 常见参数如下:
-v: 逆反模示, 只输出"不含" RE 字串之句子.
-r: 递迴模式, 可同时处理所有层级子目录裡的文件.
-q: 静默模式, 不输出任何结果(stderr 除外. 常用以获取 return value, 符合为 true, 否则为 false .)
-i: 忽略大小写.
-w: 整词比对, 类似 /<word/> .
-n: 同时输出行号.
-c: 只输出符合比对的行数.
-l: 只输出符合比对的文件名称.
-o: 只输出符合 RE 的字串. (gnu 新版独有, 不见得所有版本都支持.)
-E: 切换为 egrep .
* egrep:
为 grep 的扩充版本, 改良了许多传统 grep 不能或不便的操作. 比方说:
- grep 之下不支持 ? 与 + 这两种 modifier, 但 egrep 则可.
- grep 不支持 a|b 或 (abc|xyz) 这类"或一"比对, 但 egrep 则可.
- grep 在处理 {n,m} 时, 需用 /{ 与 /} 处理, 但 egrep 则不需.
诸如此类的... 我个人会建议能用 egrep 就不用 grep 啦... ^_^
* fgrep:
不作 RE 处理, 表达式仅作一般字串处理, 所有 meta 均失去功能.
(顺道一提: eval )
讲到 command line 的重组特性, 真的需要我们好好的加以理解的.
如此便能抽丝剥襺的一层层的将正个 command line 分析得一清二楚, 而不至于含煳.
假如这个重组特性理解下来来, 那麽, 接下来我们介绍一个好玩的命令 --- eval .
我们在不少变量替换的过程中, 常碰到所谓的複式变量的问题, 如:
[code]a=1
A1=abc[/code]
我们都知道 echo $A1 就可得到 abc 这个结果.
然而, 我们能否用 $A$a 来取代 $A1 而同样替换出 abc 呢?
这个问题我们可用很轻鬆的用 eval 来解决:
[code]eval echo /$A$a[/code]
说穿了, eval 只不过是在命令行完成替换重组后, 再来一次替换重组罢了...
就是这麽简单啦~~~ ^_^
---------------------------------------------
另外，关于sed 和 awk 中使用的 正则表达式支持的一些meta 字符和anchor 标签，跟grep（所谓的g/RE/p）类似。
话说写在shell script里的东东，一旦是头头上添上了sha bang(#! /bin/bash)，通通要经过shell层层剥开皮检查一番，这样以来，参数不再是原来的参数，而是被shell解析程序施加了7层过滤的参数（7 types of expansion），这让我们在传参数时，心里很不踏实。
这里一种办法，用于区分shell展开时对文件名的处理即pathname expansion与命令中参数中常用的正则表达式的处理RE matching。
Part-I: Wildcard
首先, wildcard 也是属于 command line 的处理工序, 作用于 argument 裡的 path 之上.
没错, 它不用在 command_name 也不用在 options 上.
而且, 若 argument 不是 path 的话, 那也与 wildcard 无关.
换句更为精确的定义来讲, wildcard 是一种命令行的路迳扩展(path expansion)功能.
提到这个扩展, 那就不要忘记了 command line 的"重组"特性了!
是的, 这与变量替换(variable substitution)及命令替换(command substitution)的重组特性是一样的!
也就是在 wildcard 进行扩展后, 命令行会先完成重组才会交给 shell 来处理.
了解了 wildcard 的扩展与重组特性后, 接下来, 让我们了解一些常见的 wildcard 吧:
*: 匹配 0 或多个字元
?: 匹配任意单一字元
[list]: 匹配 list 中的任意单一字元(注一)
[!list]: 匹配不在 list 中的任意单一字元
{string1,string2,...}: 匹配 sring1 或 string2 (或更多)其一字串
(注一: list 可以为指定的个别字元, 如 abcd; 也可以为一段 ASCII 字元的起止范围, 如: a-d .)
例:
a*b: a 与 b 之间可以有任意长度的任意字元, 也可以一个也没有, 如: aabcb, axyzb, a012b, ab 等.
a?b: a 与 b 之间必须也只能有一个字元, 可以是任意字元, 如: aab, abb, acb, a0b 等.
a[xyz]b: a 与 b 之间必须也只能有一个字元, 但只能是 x 或 y 或 z, 如: axb, ayb, azb 这三个.
a[!0-9]b: a 与 b 之间必须也只能有一个字元, 但不能是阿拉伯数字, 如: axb, aab, a-b 等.
a{abc,xyz,123}b: a 与 b 之间只能是 abc 或 xyz 或 123 这三个字串之一, 如 aabcb, axyzb, a123b 这三个.
注意:
1) [! ] 中的 ! 只有放在第一顺位时, 才有排除之功. 举例说:
[!a]* 表示当前目录下所有不以 a 开首的路迳名称.
/tmp/[a/!]* 表示 /tmp 目录下以 a 或 ! 开首的路迳名称. (思考: 为何 ! 前面要加 / 呢? 提示: 十三问之 4 )
2) [ -] 中的 - 左右两边均有字元时, 才表示一段范围, 否则仅作 "-"(减号) 字元来处理. 举例说:
/tmp/*[-z]/[a-zA-Z]* 表示 /tmp 目录下所有以 z 或 - 结尾的子目录下以英文字母(不分大小写)开首的路迳名称.
3) 以 * 或 ? 开首的 wildcard 不能匹配隐藏文件(即以 . 开首的文件). 举例说:
*.txt 并不能匹配 .txt 但可匹配 1.txt 这样的路迳名称.
但 1*txt 及 1?txt 均可匹配 1.txt 这样的路迳名称.
基本上, 要掌握 wildcard 并不难, 只要多加练习, 再勤于思考, 就能熟加运用了.
再次提醒: 别忘了"扩充+重组"这个重要特性, 而且只作用在 argument 的 path 上.
比方说, 假设当前目录下有 a.txt b.txt c.txt 1.txt 2.txt 3.txt 这几份文件.
当我们在命令行中下达 ls -l [0-9].txt 的命令行时,
因为 wildcard 处于 argument 的位置上, 于是根据其匹配的路迳, 扩展为 1.txt 2.txt 3.txt ,
再重组出 ls -l 1.txt 2.txt 3.txt 这样的命令行.
因此, 你在命令行上敲 ls -l [0-9].txt 与 ls -l 1.txt 2.txt 3.txt 都是同样的结果, 其原因正是于此了... :)
2．模式表达式
模式表达式是那些包含一个或多个通配符的字。bash除支持一般通配符外，还提供了特有的扩展模式匹配表达式，其形式和含义如下：
（1）*(模式表) 匹配给定模式表中“模式”的0次或多次出现，各模式之间以“|”分开。例如，file*(.c｜.o)将匹配文件file、file.c、file.o、 file.c.c、file.0.0、file.c.o、file.o.c等，但不匹配file.h或file.s等。
（2）+(模式表) 匹配给定模式表中“模式”的1次或多次出现，各模式之间以“|”分开。例如，file+(.c | .o)匹配文件file.c、file.o、file.c.o、file.c.c等，但不匹配file。
（3）?(模式表) 匹配模式表中任何一种“模式”的0次或1次出现，各模式之间以“|”分开。例如，file?(.c｜.o)只匹配file、file.c和file.0，它不匹配多个模式或模式的重复出现，即不匹配file. c. c、file. c. 0等。
（4）@(模式表) 仅匹配模式表中给定“模式”的一次出现，各模式之间以“|”分开。例如，file@(.c｜.0)匹配file.c和file.0，但不匹配file、file.c.c、file.c.o等。
（5）!(模式表) 除给定模式表中的一个“模式”之外，它可以匹配其它任何东西。
可以看出，模式表达式的定义是递归的，每个表达式中都可以包含一个或多个模式。例如file*( .[cho]｜.sh)是合法的模式表达式。但在使用时应注意，由于带“*”和“+”的表达式可以匹配给定模式的组合，若利用此种表达式去删除文件就存在 危险，有可能误将系统配置文件删除。因此，必须小心使用。
Part-II: Regular Expression
接下来的 Regular Expression(RE) 可是个大题目, 要讲的很多, 我这裡当然不可能讲得很完全.
只希望带给大家一个基本的入门概念, 就很是足够了...
先来考一下英文好了: What is expression?
简单来说, 就是"表达", 也就是人们在沟通时所要陈述的内容.
然而, 生活中, 表达方要清楚的将意思描述清楚而让接收方完整且无误的领会, 可不是件容易的事情.
因而才会出现那麽多的"误会", 真可叹句"表达不易"啊....
同样的情形也发生在电脑的资料处理过程中, 尤其是当我们在描术一段"文字内容"的时候...
那麽, 我们不禁要问: 有何方法可以让大家的误会降至最低程度而让表达的精确度达到最高程度呢?
答桉就是"标准化"了, 亦就是我们这裡要谈的 Regular Expression 啦.... ^_^
然而, 在进入 RE 介绍之前, 不防先让我们温习一下 shell 十三问第 4 问, 也就是关于 quoting 的部份.
关键是要能够区分 shell command line 上的 meta 与 literal 这两种不同的字符类别.
然后, 我这裡才跟你讲:
--- RE 表达式裡的字符也是分为 meta 与 literal 这两种!
呵, 不知亲爱的读者是否被我搞溷乱了呢? ... ^_^
这也难怪啦, 因为这的确是最容易溷乱的地方, 刚学 RE 的朋友很多时候都死在这裡!
因此请特别小心理解哦...
简单而言, 除非你将 RE 写在特定程式使用的脚本裡,
否则, 我们的 RE 也是透过 command line 输入的.
然而, 不少 RE 所始用的 meta 字符, 跟 shell meta 字符是冲突的.
比方说, * 这个字符, 在 RE 裡是一个 modifier(后述), 在 command line 上, 却是个 wildcard !
那麽, 我们该如何解决这样的冲突呢? 关键就是看你对十三问第 4 问所提的 quoting 是否够理解了!
若你明白到 shell quoting 就是在 command line 上关闭 shell meta 这一基本原理,
那你就能很轻鬆的解决 RE meta 与 shell meta 的冲突问题了:
--- 用 shell quoting 关掉 shell meta 就是了!
就这麽简单... ^_^
再以刚提到的 * 字符为例, 若在 command line 中没有 quoting 处理的话, 如 abc* ,
那就会被作为 wildcard expansion 来扩充及重组了.
若将之置于 quoting 中, 如 "abc*", 则可避免 wildcard expansion 的处理.
好了, 说了大半天, 还没进入正式的 RE 介绍呢...
大家别急, 因为我的教学风格就是要先建立基础, 循序渐进的... ^_^
因此, 我这裡还要在囉唆一个观念, 才会到 RE 的说明啦... (哈... 别打我....)
当我们在谈到 RE 时, 千万别跟 wildcard 搞溷在一起!
尤其在 command line 的位置裡, wildcard 只作用于 argument 的 path 上.
但是 RE 却只用于"字串处理"的程式之中, 这与路迳名称一点关系也没有!
RE 所处理的字串通常是指纯文档或透过 stdin 读进的内容...
okay, 够了够了, 我已看到一堆人开始出现不大耐烦的样子了.... ^_^
现在, 就让我门登堂入室, 撩开 RE 的神秘面纱吧, 这样可以放过我了吧? 哈哈...
在 RE 的表达式裡, 主要分两种字符(character): literal 与 meta.
所谓 literal 就是在 RE 裡不具特殊功能的字符, 如 abc, 123 这些;
而 meta 在 RE 裡具有特殊的功能, 要关闭之需在 meta 前面使用 escape( / )字符.
然而, 在介绍 meta 之前, 先让我们来认识一下字符组合(character set)会更好些.
所谓的 char. set 就是将多个连续的字符作一个集合, 比方说:
abc: 表示 abc 三个连续的字符, 但彼此独立而非集合. (可简单视为三个 char. set)
(abc): 表示 abc 这三个连续字符的集合. (可简单视为一个 char. set)
abc|xyz: 表示或 abc 或 xyz 这两个 char. set 之一.
[abc]: 表示单一字符, 可为 a 或 b 或 c . (与 wildcard 之 [abc] 原理相同)
[^abc]: 表示单一字符, 不为 a 或 b 或 c 即可. (与 wildcard 之 [!abc] 原理相同)
. : 表示任意单一字符. (与 wildcard 之 ? 原理相同)
在认识了 char. set 这个概念后, 然后再让我们多认识几个 RE 中常见的 meta 字符:
- 锚点(anchor)
用以标识 RE 于句子中的位置所在. 常见有:
^: 表示句首. 如 ^abc 表示以 abc 开首的句子.
$: 表示句尾. 如 abc$ 表示以 abc 结尾的句子.
/<: 表示词首. 如 /<abc 表示以 abc 开首的词.
/>: 表示词尾. 如 abc/> 表示以 abc 结尾的词.
- 修饰字符(modifier)
独立表示时本身不具意义, 专门用以修改前一个 char. set 的出现次数. 常见有:
*: 表示前一个 char. set 的出现次数为 0 或多次. 如 ab*c 表示 a 与 c 之间可有 0 或多个 b 存在.
?: 表示前一个 char. set 的出现次数为 0 或 1 次. 如 ab?c 表示 a 与 c 之间可有 0 或 1 个 b 存在.
+: 表示前一个 char. set 的出现次数为 1 或多次. 如 ab+c 表示 a 与 c 之间可有 1 或多个 b 存在.
{n}: 表示前一个 char. set 的出现次数必须为 n 次. 如 ab{3,}c 表示 a 与 c 之间必须有 3 个 b 存在.{n,}: 表示前一个 char. set 的出现次数至少为 n 次. 如 ab{3,}c 表示 a 与 c 之间至少有 3 个 b 存在.
{n,m}: 表示前一个 char. set 的出现次数为 n 到 m 次. 如 ab{3,5}c 表示 a 与 c 之间有 3 到 5 个 b 存在.
然而, 当我们在识别 modifier 时, 却很容易忽略"边界(boundary)"字符的重要性.
以刚提到的 ab{3,5}c 为例, 这裡的 a 与 c 就是边界字符了.
若没有边界字符的帮忙, 我们很容以作出错误的解读.
比方说: 我们用 ab{3,5} 这个 RE (少了 c 这个边界字符)可以抓到 abbbbbbbbbbc (a 后有 10 个 b )这串字吗?
从刚才的 modifier 我们一般会认为我们要的 b 是 3 到 5 个, 若超出了此范围, 就不是我们要表达的.
因此, 我们或会很轻率的认为这个 RE 抓不到结果...
然而答桉却是可以的! 为甚麽呢?
让我们重新解读 ab{3,5} 这个 RE 看看:
我们要表达的是 a 后接 3 到 5 个 b 即可, 但 3 到 5 个 b 后面我们却没规定是甚麽,
因此在 RE 后面可以是任意的文字, 当然包括 b 也可以啦! (明白了吗?)
同样的, 我们用 b{3,5}c 也同样可以抓到 abbbbbbbbbbc 这串字的.
但我们若使用 ab{3,5}c 这样的 RE 时, 由于同时有 a 与 c 这两个边界字符, 那就截然不同了!
有空再思考一下, 为何我们用下面这些 RE 都可抓到 abc 这串字呢?
x*
ax*, abx*, ax*b
abcx*, abx*c, ax*bc
bx*c, bcx*, x*bc
...(还有更多...)
但, 若我们在这些 RE 前后分别加一个 ^ 与 $ 这样的 anchor, 那又如何呢?
刚学 RE 时, 只要能掌握上面这些基本的 meta 大盖就可以入门了.
一如前述, RE 是一种规范化的文字表达方式, 主要用于某些文字处理工具之间,
如 grep, perl, vi, awk, sed, 等等. 常用以表示一段连续的字串, 捕获之或替换之.
然而, 每种工具对 RE 表达式的具体解读或有一些细微差异, 不过, 基本原则还是一致的.
只要能掌握 RE 的基本原理, 那就一理通百理明了, 只是在实作时稍加变通即可.
比方以 grep 来说, 在 linux 上你可找到 grep, egrep, fgrep 这几个程式, 其差异大致如下:
* grep:
传统的 grep 程式, 在没有参数的情况下, 只输出符合 RE 字串之句子. 常见参数如下:
-v: 逆反模示, 只输出"不含" RE 字串之句子.
-r: 递迴模式, 可同时处理所有层级子目录裡的文件.
-q: 静默模式, 不输出任何结果(stderr 除外. 常用以获取 return value, 符合为 true, 否则为 false .)
-i: 忽略大小写.
-w: 整词比对, 类似 /<word/> .
-n: 同时输出行号.
-c: 只输出符合比对的行数.
-l: 只输出符合比对的文件名称.
-o: 只输出符合 RE 的字串. (gnu 新版独有, 不见得所有版本都支持.)
-E: 切换为 egrep .
* egrep:
为 grep 的扩充版本, 改良了许多传统 grep 不能或不便的操作. 比方说:
- grep 之下不支持 ? 与 + 这两种 modifier, 但 egrep 则可.
- grep 不支持 a|b 或 (abc|xyz) 这类"或一"比对, 但 egrep 则可.
- grep 在处理 {n,m} 时, 需用 /{ 与 /} 处理, 但 egrep 则不需.
诸如此类的... 我个人会建议能用 egrep 就不用 grep 啦... ^_^
* fgrep:
不作 RE 处理, 表达式仅作一般字串处理, 所有 meta 均失去功能.
(顺道一提: eval )
讲到 command line 的重组特性, 真的需要我们好好的加以理解的.
如此便能抽丝剥襺的一层层的将正个 command line 分析得一清二楚, 而不至于含煳.
假如这个重组特性理解下来来, 那麽, 接下来我们介绍一个好玩的命令 --- eval .
我们在不少变量替换的过程中, 常碰到所谓的複式变量的问题, 如:
[code]a=1
A1=abc[/code]
我们都知道 echo $A1 就可得到 abc 这个结果.
然而, 我们能否用 $A$a 来取代 $A1 而同样替换出 abc 呢?
这个问题我们可用很轻鬆的用 eval 来解决:
[code]eval echo /$A$a[/code]
说穿了, eval 只不过是在命令行完成替换重组后, 再来一次替换重组罢了...
就是这麽简单啦~~~ ^_^
---------------------------------------------
另外，关于sed 和 awk 中使用的 正则表达式支持的一些meta 字符和anchor 标签，跟grep（所谓的g/RE/p）类似。
扫一扫
872
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
