Why does GNU sed
not catch as expected below in [1], while [2] and above all [3] are OK?
[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
Try as I might to browse the GNU info
on regexps for sed
, I still cannot make sense of this output in [1].
The blank space at the right of the first part of the substitution regexp in [1] was expected to block expansion of the catch just at the space in between a and t , yielding a as a match.
Supposing this rightmost blank space in the first-part regexp actually does not count for some reason unclear to me, I expected the match to behave as in [2], yielding at .
But then [3] shows that blank spaces do act as contextual filters for the match, as a leftmost blank space added to the first-part regexp blocks any match.
sed
version is 4.7 under Ubuntu 20.04.
I sure must be missing something somewhere. Any idea?
In [1], the regex c([^ ]+)
matches ca
capturing a
as \\1
, which means the substring ca
is replaced with a
and the pattern space will turn into at
.
In [3], the regex c([^ ]+)
does not match the pattern space due to the leading space and the pattern space is printed unmodified.
I hope my explanation is clear enough.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.