in reply to Re: Re: My first package - need help getting started
in thread My first package - need help getting started

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();
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
It should work perfectly the first time! - toma

Replies are listed 'Best First'.
Re: Re: Re: Re: My first package - need help getting started
by Limbic~Region (Chancellor) on Feb 27, 2003 at 05:53 UTC
    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