奇怪的捕獲/匹配 sed 行為

Question

為什么 GNU sed在下面的 [1] 中沒有按預期捕獲，而 [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

盡我所能瀏覽關於sed regexps 的 GNU info ，我仍然無法理解 [1] 中的這個輸出。
在替代的regexp的第一部分的右側的空白空間[1]預計只是在A和T之間的空間以阻擋捕獲的擴張，從而產生為匹配。
假設第一部分正則表達式中最右邊的空格實際上由於某種原因而不算數，我預計匹配會像 [2] 中那樣，產生在.
但是 [3] 表明空格確實充當匹配的上下文過濾器，因為添加到第一部分正則表達式的最左邊的空格會阻止任何匹配。
sed版本在 Ubuntu 20.04 下是 4.7。
我肯定在某個地方遺漏了一些東西。 任何的想法？

Answer 1

在[1]，正則表達式c([^ ]+)匹配ca捕獲a作為\\1 ，這意味着子ca被替換為a與圖案空間就會變成at 。

在 [3] 中，正則表達式c([^ ]+)由於前導空格與模式空間不匹配，並且模式空間未修改地打印。

我希望我的解釋足夠清楚。