Question

为什么下面[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。
我肯定一定在某处缺少东西。有想法吗？

Answer 1

在[1]中，正则表达式c([^ ]+) 与ca 匹配，将a捕获为\1，这意味着子字符串ca 被a替换，模式空间将变成 at。

在[3]中，正则表达式 c([^ ]+)与模式空间不匹配，原因是前导空间，图案空间未修改地打印。

我希望我的解释很清楚。

奇怪的捕获/匹配sed行为

1 个答案: