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

Comment on Re: Re: Re: Re: My first package - need help getting started