为什么下面[1]中的GNU sed
不能按预期捕获,而[2]以及最重要的[3]可以捕获?
[1] $ echo "ca t" | sed -E 's/c([^ ]+) /\1/' # Odd, expected 'a' or possibly 'a t'
at
[2] $ echo "ca t" | sed -E 's/c([^ ]+)/\1/' # OK, expected 'a t'
a t
[3] $ echo "ca t" | sed -E 's/ c([^ ]+)/\1/' # OK, does not catch, but then why on earth is [1]?
ca t
尝试尝试在info
的正则表达式上浏览GNU sed
,但仍然无法理解[1]中的输出。
预期[1]中替换正则表达式第一部分右侧的空白会阻止渔获量扩展,恰好位于 a 和 t 之间的空间,产生 a 作为匹配项。
假设由于我不清楚,出于某种原因,第一部分正则表达式中最右边的空格实际上不算在内,我希望匹配行为与[2]相同,产生 a 。
但随后[3]显示,空格确实充当了匹配的上下文过滤器,因为添加到第一部分正则表达式中最左边的空格会阻止任何匹配。
在Ubuntu 20.04下sed
版本是4.7。
我肯定一定在某处缺少东西。有想法吗?
答案 0 :(得分:1)
在[1]中,正则表达式c([^ ]+)
与ca
匹配,将a
捕获为\1
,这意味着
子字符串ca
被a
替换,模式空间将变成
at
。
在[3]中,正则表达式 c([^ ]+)
与模式空间不匹配,原因是
前导空间,图案空间未修改地打印。
我希望我的解释很清楚。