Am 2. Januar 2018 18:58:50 MEZ schrieb Chris Ridd <chrisr...@mac.com>: > >> On 2 Jan 2018, at 13:36, Burns, Victor M via perl-ldap ><perl-ldap@perl.org> wrote: >> >> Thanks for getting back to me. I suspect I confused the version >number. As you know perl-ldap is a large set of classes. I am using the >latest perl-ldap-0.65 and the class in Question Net::LDAP::Entry is >0.27 and is confirmed both on my system and on CPAN at this link; >http://search.cpan.org/~marschap/perl-ldap-0.65/lib/Net/LDAP/Entry.pod >which shows it is version 0.27 and is part of perl-ldap-0.65 > >OK. > >> As I mentioned it might be nice if the ldif method supported >additional options. I found it useful to have a wrap => 0 option to >disable wrapping. For now I get around the issue by cheating. In a >class I've written I fudge a new method, ldif_nowrap, into the >Net::LDAP::Entry namespace, "God bless PERL!" that hardcodes the ( wrap >=> 0 ) into it and I call it in the place of the regular ldif method. I >do it this way and avoid the Perl redefined subroutine warning all >together. I'm a huge fan of strict and warnings! I don't write anything >without them. :) > >Disabling LDIF wrapping is pretty useful when you’ve got long values >getting output, and you’re eyeballing the output, or even passing it to >tools that aren’t LDIF-aware (e.g. grep!) > >We (ForgeRock) even changed the default in ForgeRock's ldapsearch tool >to not wrap as of DS 5.x. > >IMO changing Net::LDAP::LDIF to be able to not wrap would be useful. > >Chris
Hi, Please have a look at * Net::LDAP::Entry->update I consider it the better interface as it does not create an Net::LDAP::LDIF imstande vor every call. This method supports everything you need with an appropriately opened LDIF object * The changes in https://github.com/marschap/perl-ldap/tree/next I expect this to become the next perl-ldap release. Please test the changes in Net::LDAP::Entry. Improvement ideas welcome. Especially if they hinder the user from making stupid mistakes like calling LDIF(version=>1) Peter -- Peter Marschall <pe...@adpm.de>
