Sheri, here's your answer: > > I wonder if he could just simply make . the equivalent of [^\r\n] when > > CRLF is in effect.
I do not like this, though of course you can always write [^\r\n] yourself. > As for myself, I think that's too complicated. I think a new option that > defines CR as well as LF as newline characters would be easier to understand > and wouldn't break anyone's scripts. There is such an option in PCRE 7.0. It defines all Unicode line sequences as meaning "end of line". In this environment, when PCRE_DOTALL is not set, dot will not match if the current position is at a CR or an LF (or several other characters). I am, however, planning on making the following change before releasing PCRE 7.0: If line endings are set to CRLF or ALL, and an unanchored match has failed, and the next two characters are CRLF, then skip two characters instead of one before trying again. The only time I think this might be a problem is when processing binary data, where line endings don't matter - the advice there would be not to use the CRLF setting. Philip
