It is a bug in Net::LDAP::LDIF, try
http://svn.goingon.net/repos/perl-ldap/trunk/lib/Net/LDAP/LDIF.pm
Or you can workaround with
$fh = \*STDOUT;
Net::LDAP::LDIF->new($fh,"w", wrap => 999_999_999)->write($schema-
>entry);
Graham.
On Feb 27, 2007, at 7:29 PM, Eric Nichols wrote:
On Tue, February 27, 2007 7:51 pm, Graham Barr wrote:
On Feb 27, 2007, at 3:40 PM, Peter Marschall wrote:
On Monday, 26. February 2007 15:34, Eric Nichols wrote:
I've upgraded to .34 of perl-ldap and I tried to dump the schema
of an
Active Directory Global Catalog. All that shows is about 20
lines of
carriage returns.
All other functions seem to work fine.
Help?
Although there has work been gone into perl-ldap to make some/most
of the
schema fucntions work with AD to, I guess dump() relies on the
standard.
I should not matter. ::Schema, after successful parse, remembers the
entry and dump just does an LDIF dump on that entry.
So the question is, was the parse successful ?
I guess some digging around inside of $schema is in order to see what
is there. And if there is no entry stored I guess we need to
determine why.
Graham.
I did a cursory check and was able to dump an attribute (sn) so the
data is
there. I made a work around and was able to use Storable to get it
to a file.
The save/restore is remarkably fast. Graham, I can send over the
storable
blob which will give you my schema object I generated.
