On 11/1/06 8:21, Gergely Sánta <[EMAIL PROTECTED]> wrote: > --Quanah Gibson-Mount wrote: > >> >> --On Tuesday, January 10, 2006 5:29 PM +0100 Gergely Sánta >> <[EMAIL PROTECTED]> wrote: >> >>> Hi! >>> >>> It seems, the problem is in my perl-experience.. I generated an >>> another, >>> bigger bug with my change, the trailing '\n'-s of lines wasn't >>> removed.. >>> So those lines wasn't equivalent at all :( >>> >>> I'm attaching a diff of my changes, which now works fine for me.. >> >> >> Generally the standard is to use "diff -u" not just "diff", as the >> default output is pretty useless to use to apply as a patch. >> >> --Quanah >> > Ok, sorry, I didn't know.. Here is the "diff -u" with another little change. > After some googling on $INPUT_RECORD_SEPARATOR ($/), I found that the > difference between '$/ = undef' and '$/ = ""' is, that the second one > will treat two or more consecutive empty lines as a single empty line. > For this reason I added an additional line '$ln =~ s/\n\n+/\n\n/sg;'. > > Maybe this isn't the best solution for accepting memory-files too, but > it works fine. I hope, it is not generating another bug to code.. Now > this works for buffers too:
What happens if your string contains lines terminated by "\r\n" (DOS-style) or just "\r" (Classic MacOS-style) instead of just "\n" (Unix-style)? I'm not sure if LDIF allows the Classic MacOS-style, but I'm sure it allows the other two. I'm too lazy too look ;-) and since you've got the code in your editor... :-)) Cheers, Chris
