不贪婪的 sed

mhss

我可以做，但是写这个东西很有必要吗？
如果你想自己做的话，可以看我注释的 grep.c，看懂了就可以随心所欲怎么改都行了。
http://mhss.nease.net/unix/grep.c

飞灰橙

谢谢 回去钻研 ：）

lightspeed

ssed is a version of sed that supports a few new features, including Perl regular expressions and much greater speed than GNU sed.

Visit http://sed.sourceforge.net/

mhss

居然还有个 ssed, 佩服外国同行的敬业精神。

mhss

我注释的 ken 的 grep.c 中定义的正则表达式与 posix 标准有一些出入，毕竟是 1969 年 ken 搞 pdp7 unix 时候做的东西了，在 1979 年发行的 unix v7 中增加了 aho 的 egrep.y，介入了扩展正则表达式，称它为扩展，则 ken  的定义就只好叫基本正则表达式了，他的扩展主要是再次加入了 | 和 () 分别表示多选和组合，其中的 (...) 与 ken 的 \(...\) 的本质区别是 (...)* 表示子表达式的闭包，而\(...\)* 中的 * 是个普通字符， 就是说\(...\) 不起到组合作用。
在1979 年 unix v7 中引入的 sed 采用的是 ken 的正则表达式，这是必须的，因为作为编辑器，它需要后引用机制，aho 的定义不支持后引用，并且严肃的说后引用超出了纯粹的有穷自动机的表达能力。ken 定义中 \(...)\ 作用就是表示引用的开始和结束,以被后引用所引用。
经历了无休无止的功能扩展，新近的 sed 如 gnu sed 的\(...)\ 也起到了组合作用，比如
echo '333444' | sed 's/\(3\)*/<\1>/'
打印 <3>444
echo '333444' | sed 's/\(34*\)*/<\1>/'
打印 <3444>
这表明了后引用捕获的是与闭包中子表达式相匹配的最后的那个匹配串。
依据现存的发展和 posix 标准的明文。我增改了 ken 的 grep.c 。同时也就使 sed 的行为与标准相一致了。
我修订的 sed 的与 gnu sed 有一个明显的语义差别。
echo '333444' | ./sed 's/\(34\)*/<\1>/'
打印 33<34>44
而 gnu sed 中
echo '333444' | sed 's/\(34\)*/<\1>/'
打印 <>333444
期盼仁者指正。
我做的算法修订还需要严肃的调试和测试，不过我认为没有继续这种努力的必要。

Lanma

不是很理解为什么是这个结果,sed我研究的不多:

echo '333444' | sed 's/\(34\)*/<\1>/'
打印 <>333444
比较一下感觉这个结果这"合理"?
echo '333444' | ./sed 's/\(34\)*/<\1>/'
打印 33<34>44

请指教.

mhss

我对 gnu sed 的这种输出持保留态度，要知道为什么就要分析它的源代码了；就算它的算法有问题，成千上万的 sed 脚本就是对这个事实的认可，存在即合理。

killua

[quote]原帖由 "mhss"]我注释的 ken 的 grep.c 中定义的正则表达式与 posix 标准有一些出入，毕竟是 1969 年 ken 搞 pdp7 unix 时候做的东西了，在 1979 年发行的 unix v7 中增加了 aho 的 egrep.y，介入了扩展正则表达式，称它为扩展，则..........[/quote 发表：

1. echo '333444' | sed 's/\(34\)/<\1>/'
   
2. print :  33<34>44

复制代码

mhss

如果任务是要找出 333444 中的 34 当然是这么写。一个具体问题可以使用有多种机制来解决，我关心的是某个机制本身的问题。

skydog2002

原帖由 "Lanma" 发表：
不是很理解为什么是这个结果,sed我研究的不多:

echo '333444' | sed 's/\(34\)*/<\1>/'
打印 <>333444
比较一下感觉这个结果这"合理"?
echo '333444' | ./sed 's/\(34\)*/<\1>/'
打印 33&..........

因为\(34\)*还匹配0个\(34\)