Peter wrote:Maybe Christian Ghisler can explain if it is the first end-of-line after the founded text - or some end-of-line somewhere?
Not
somewhere! Exactly at the place the "$" is located, but
not only at this place. Actually, it depends on how the program treats the "." meta-character. For example, EmEditor has even a separate option if the dot is allowed to match newlines or not.
Let's suppose it is. Then the expression
would match each of the following text samples:
started in 2005
started
in 2005
started in 2005 and
finished elsewhen
started in
2005
and
finished
elsewhen
because the sub-expression ".*" would eat as much as possible, including newlines, if necessary, and the "$" sign would only match the very end of the text, no matter how many lines it took before the end was reached: all these lines have already been matched (eaten) by the ".*" sub-expression.
A completely different case is when dot is
not allowed to match newlines. In this case your original expression (and my example above, as well), indeed, would mean that the "$" marks the position of the
first newline.
BUT! It's not because it is the nature of the "$" meta-character, but simply because you did not include any newline in the previous sub-expression.
So, your phrase from the very first post
it seem that the sign" $" (for CR/LF; end of line) is ignored
is not correct: the "$" sign is
not ignored, it is matched and matched absolutely correctly, at the end of line! What was wrong was dot matching newlines in one case and not matching in another. That was what I found in my experiment, and that, I'm sure, should be the correct description of the bug: not the "$" sign but the "." sign.