------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1315 --- Comment #3 from Christoph Anton Mitterer <[email protected]> 2012-11-08 23:55:43 --- Hey Zoltan. (In reply to comment #1) > next time you should be a little more polite. That could help a lot. I don't see any particular place that I'd consider impolite?! Perhaps a bit stiff... well it was very late in the morning and I was already nearly falling asleep. Anyway, be assured, that I didn't meant anything impolitely :) > What you misunderstand here is that $ is not a character range, such as [a-z], > it is a zero-width assertion. So you mean in the sense as "till/at the end of the line"?! > e.g: /a$[^x]b/m matches to a\nb, since $ itself just checks a condition, but > does not change the character position. Uhm... not yet sure whether I understand... > \r[^\n] this pattern matches to two character long strings. E.g, it matches to > \rx but not to \r or \r\n. Here, [^\n] is a character range, so it does not > match at the end of the input. So ok... that means basically a pattern like \r[^\n] needs at least to characters to match. Am I right then, that \r\n is _not_ matched here, because \n doesn’t appear at all as a character (because it’s considered not a character in that sense but the "mark up" for line separating)? > \r[^$] also requires two characters, the first one is \r, followed by anything > which is not $ (here, $ is a plain character), so it matches to \r\n, but not > to \r$. Ah.... ok so [...] always means there needs to be a character... and if I put in ^$ it just says "at that position, there must be a character, but the end-of-line condition must NOT be met. > I hope now everything is clear. Let me just re-evaluate my cases... a) It's still not clear why a plain $ doesn't match... I would expect it to _always_ match... as I would for ^ b) The case: $ hd $file 00000000 41 0d 0a |A..| 00000003 $ pcregrep '\n' $file ; echo $? 1 Is that, because in UNIX (or rather when the end-of-line is set to \n... \n will never match, because again, the \n is not considered a char but rather the condition "end-of-line". This goes now rather towards support and less towards (invalid) bug reporting: Is there a way in PCRE to do what I wanted... e.g. matching a CR, that is not followed by an LF? Or can I check for e.g. LFCRs, who are not actually just CRLFCR i.e. checking for LFCR which are not prefixed by another CR. So basically a way to check for the end-of-line character by itself and not as a condition. -- Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
