bug-sed
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#19586: sed bug?


From: Davide Brini
Subject: bug#19586: sed bug?
Date: Tue, 13 Jan 2015 19:59:32 +0100

On Sun, 11 Jan 2015 17:05:40 +0100, "E.Fennema" <address@hidden>
wrote:

> I am running
>     sed (GNU sed) 4.2.2
> 
> address@hidden:~/> echo "Here 345 is a number" | \
>      sed 's,.*\([23456]\).*,I found \1,;q'
> I found 5

Here you captured *exactly* one character matching [23456] which, due to
the previous .* greedy expression, happens to be the "5" in "345" (in
detail: .* tries to match the whole thing until the end, then the engine
backtracks trying to find a match for the [23456], which it finds when it
hits the "5", which is captured). The following .* deletes the rest of the
input, so what goes into \1 is "5".

> So far so good.
> 
> address@hidden:~/> echo "Here 345 is a number" | \
>      sed 's,.*\([23456]*\).*,I found \1,;q'
> I found

Here you capture *zero or more* instances of [23456]. "Zero or more"
includes "zero". A zero-length match is found at the beginning of the
pattern space, at the end, and between any two characters.
What happens here, likely, is that the first .* tries to match the whole
line; then sed sees that [23456]* _also_ matches at the end, since a
zero-length match always matches, and finally the other .* _also_ matches,
since it can match zero characters as well. So the overall LHS matches, but
what gets captured and replayed in \1 is zero characters long.

In short, no bug.

-- 
D.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]