Cheers - L~R

All I had to remove the whitespace before the : characters and change the 'key:' field to 'dn:'. Instant perl objects!

This code is almost identical to the code in the synopsis for Net::LDAP::LDIF. I just added a call to Data::Dumper to print the object and its structure.

use strict;
use warnings;
use diagnostics;
use Data::Dumper;

use Net::LDAP::LDIF;

my $ldif = Net::LDAP::LDIF->new( "file.ldif", "r", onerror => 'undef' 
+);

while( not $ldif->eof() ) {
  my $entry = $ldif->read_entry();
  if ( $ldif->error() ) {
    print "Error msg: ",$ldif->error(),"\n";
    print "Error lines:\n",$ldif->error_lines(),"\n";
  }
  else {
    print Dumper($ldif);
  }
}
$ldif->done();
[download]

Here is the modified input file:

dn: /C=US/A=BOGUS/P=ABC+DEF/O=CONN/OU=VALUE1/S=Region/G=Limbic/I=_/
type: UR
flags: DIRM ADMINM ADIC ADIM
Alias-2: wL_Region
Alias-3: Limbic Region
Alias-4: Limbic._.Region@nowhere.com
Alias-5: Limbic._.Region
Alias-6: Limbic.Region@nowhere.com
Alias-7: ORG
Alias-8: CMP
Alias-10: O=ORG/OU=Some Big Division/CN=Limbic _. Region
Alias-11: Region
Alias-12: Region, Limbic _
Alias-14: Limbic _. Region at WT-CONN
Alias-15: ex:/o=BLANK/ou=ORG/cn=Recipients/cn=Mailboxes/cn=LRegion
Alias-16: WT:Limbic_Region
Alias-17: SMTP:Limbic._.Region@nowhere.com
Alias-18: /o=A.B.C.D./ou=Vermont Ave/cn=Recipients/cn=wt/cn=Limbic_Reg
+ion
Full Name: Region, Limbic _.
Post Office: WT-CONN
Description: 999-555-1212 Some Big Company
Tel: 999-555-1212
Dept: Some Big Division
Location: EMWS
Address: 123 nowhere street
City: everywhere
State: MD
Zip Code: 20874
Building: BLAH
Building-Code: MD-ABC
owner: CONN
[download]

It should work perfectly the first time! - toma

toma,
While my sample entry appeared to be LDIF format, it was not. It would only take a few lines of data munging code to transform my sample entry into what you have shown, but there are too many error handling exceptions to think about. The data needs to come in and go out in a VERY specific format. For instance - if I had to do something to get it to handle the imbedded \/ in the key (which you converted to dn), I would have to know how to reverse this process on the output.

The point to this project was not to manipulate my data to look like some other format so that I could use someone else's modules and have to worry making sure I do not break anything along the way.

I do not want to give the wrong impression - I am very grateful as I mentioned in the CB in our running conversation. Those who are reading this that were not in the CB may not understand why this isn't a viable approach for me. The propietary database has 0 similarities with LDAP/LDIF. The fact that the flat file export resembles LDIF is probably a coincidence since the database is used as a meta-directory to cross reference numerous different directory architectures. I do assure you though that it plays by its own rules and does not adhere to the same standards.

• The data has to come out exactly like it went in, so that it can be imported into this propietary database.
• My example was a typical record/format, but does not represent all of the possibilities
• Any data munging to get the LDIF to work has to be remembered and reversed on the way out
• There were a few others, but I am getting tired
• The existing sed code will be my validator.

  Again - thank you very much and I am sure there will be some valuable information in links. I may even be able to use the LDIF module to handle simple cases and only code for the tough ones.

  Cheers - L~R

That sample input looks almost exactly like LDAP. It may be an offshoot of DAP. Net::LDAP can almost access that data, it just a little more coaxing. Well, ok, not Net::LDAP, but the LDIF modules included with it. I really think this route should be investigated thouroughly.

I refer you to this.
Thanks - L~R