according to my Camel (3rd edition), on page 150, you can use a /s modifier to allow '.' to also match newlines..

So try something like this?
/cn=(.+),ou=(.+),ou=(.+),c=(.+)/s

C.

Not a bad suggestion, BUT:

1. As the file to be read in is so large, it will have to be dealt with line by line.
2. The lines will break at the 80th position.
3. Using the /s-switch in the regex will solve nothing as you will only find the newline-character at the end of the line just read in.

I would suggest rather to first normalize the file, i.e. remove the newlines at the 80th positions and concatenating the various parts of each DN together so as to have one line per DN.

Then you can use the regex /cn=(.+),ou=(.+),ou=(.+),c=(.+)/

Finally you de-normalize the DN's again by adding -if necessary- newlines at position 80 so as no to break the other tools.

CountZero

"If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

In that case the regex would have look like this:


/c\n?n\n?=\n?([^,]*)\n?,\n?…
[download]

etc, etc. One suggestion is to take the basic regex above and auto-generate the necessary one by interpolating optional newlines after each character, but I think the poster is looking for a neater hack. I wish I could think of one!

I always try to find some sort of reliable landmark in the format I'm reading and use it to disambiguate other parts of the "markup" on a syntatictal level, rather than going into the semantics (like "does the sum of tags I have here constitue a complete DN yet?" as BrowserUk did).

In this case the (almost) reliable landmark is the commas separating the tags. If we read the file from comma to comma, there is only one ambiguous case: we can read across the newline that separates the tag at the end of one DN from that which begins the other DN. This is the one case we need to care about. How can we unambiguously conclude that is what the newline at hand means? If and only if the newline is followed by \w+=.

Update: This doesn't quite work. / \n \w+ = /x is not strong enough - what happens if it's the tag itself that's broken up? Then we get a dangling beginning of the tag as the end of the current DN and the rest of the tag with equals sign and value, newline and the second tag as the beginning of the new DN. However, since we read from comma to comma, we can garantuee that we always get the beginning of a tag at the start of the string. Therefor requiring that an equals sign precede the newline clarifies this corner case:

local $/ = ",";

my $dn = "";
while(<>) {
    my $complete_dn;

    if(m/ \A (.+ = .+) \n ( \w+ = .+ ,) \z /sx) {
        $complete_dn = $dn . $1;
        $dn = $2;
    }
    else {
        $dn .= $_;
    }

    if($_ = $complete_dn) {
        s/\n+//g;
        print $_, "\n";
    }
}
[download]

Here's my "test suite":

Makeshifts last the longest.

1. strip those \n's caused by 80-char restriction. (You may have two types of \n's, one is the logical record separator, one is caused by the 80-char restriction. This is not clearly described in your post, I just go with a more complete thinking.)
2. do a s///, you don't need any fancy one, just a plain normal one, which anyone can come up in one second.
3. Reformat to satisfy the 80-char restriction.

This seems to deal with al the pathelogical break points I tried.

#!perl -slw
use strict;

my @lines;
my $buffer;
while( <DATA> ){
    chomp;
    $buffer .= $_;                         #! Accumulate in buffer
    if ($buffer =~ /^(cn=.+?)cn=/) {    #! When we have a full line+
        push @lines, $1;                #! save it
        substr($buffer, 0, $+[1], '');  #! and strip from the buffer
    }
}
push@lines,$buffer;

print for @lines;
[download]

Test data

$/ = 'dn:';

With this, you can apply regexes as necessary to any data within each multiline "dn:" record without having to worry about the newlines.