Dumping Net::LDAP::Entry to a string
Heiko Jansen
using Net::LDAP I had a problem when I wanted to hand of a stringified version
of a single result record (object of type Net::LDAP::Entry): it seems like
it's only possible to dump a record directly to a file handle
(Net::LDAP::Entry->dump)?!
So in case anyone else finds this useful (and in case I didn't miss something)
I've appended a small patch to Net/LDAP/Entry.pm (and Net/LDAP/Entry.pod)
which provides a dumpstr() method to return a stringified record.
Heiko
Graham Barr
I am in two minds as whether to accept this as a change. As the docs state
This method is intended for debugging purposes and does not treat binary attributes specially
See Net::LDAP::LDIF on how to generate LDIF output
so this really should not be used for passing around entries
Also, anything that can dump to a filehandle can dump to a string.
open(my $fh,">",\my $buffer);
then pass $fh as the file handle
Having said that maybe Net::LDAP::Entry could use an ->ldif method
something like (untested)
sub ldif {
my $self = shift;
require Net::LDAP::LDIF;
open(my $fh, ">", \my $buffer);
my $changes = $self->changes ? 1 : 0;
my $ldif = Net::LDAP::LDIF->new($fh,"w", changes => $changes);
$ldif->write_entry($self);
return $buffer;
}
Graham.
Heiko Jansen
> I am in two minds as whether to accept this as a change. As the docs state
>
> This method is intended for debugging purposes and does not treat
> binary attributes specially
>
> See Net::LDAP::LDIF on how to generate LDIF output
>
> so this really should not be used for passing around entries
I didn't intend to pass around the stringified entry - but you're right:
people would quite probably try to use it that way.
As for not treating binary attributes specially: If dump() could live without,
I concluded that dumpstr() could do so, either....
> Also, anything that can dump to a filehandle can dump to a string.
>
> open(my $fh,">",\my $buffer);
>
> then pass $fh as the file handle
I consider that a not so well known solution. At least I had to look it up
yesterday - well, given my programming skills that's probably not a sensible
criterion.... ;-)
Regarding Christophers reference to it lacking backward compatibility: One
might use IO::String instead. But that would add another module dependency.
> Having said that maybe Net::LDAP::Entry could use an ->ldif method
>
> something like (untested)
>
> sub ldif {
> my $self = shift;
> require Net::LDAP::LDIF;
> open(my $fh, ">", \my $buffer);
> my $changes = $self->changes ? 1 : 0;
> my $ldif = Net::LDAP::LDIF->new($fh,"w", changes => $changes);
> $ldif->write_entry($self);
> return $buffer;
> }
Well, that works. Output does not look as nicely formatted and readable as the
original dump() output, but that's certainly an acceptable trade-off for being
more complete and "correct". Which makes me think that it could be used inside
dump(), too.
Heiko
Graham Barr
> Graham Barr wrote:
>
>> Also, anything that can dump to a filehandle can dump to a string.
>> open(my $fh,">",\my $buffer);
>> then pass $fh as the file handle
>
5.8.0 was released nearly 8 years ago. Anyone who is still using a version of perl that old will not mind using an old version of Net::LDAP IMO.
Graham.
acon...@comcast.net
can someone remove me from your emails??????
Christopher Bongaarts
> Also, anything that can dump to a filehandle can dump to a string.
>
> open(my $fh,">",\my $buffer);
>
> then pass $fh as the file handle
Only in perl >= 5.8. Perl 5.6 and earlier won't support this syntax, so
I would advise against using this to implement and ldif() method
unless you are OK with breaking compatibility with older perls...
--
%% Christopher A. Bongaarts %% c...@tc.umn.edu %%
%% OIT - Identity Management %% http://umn.edu/~cab %%
%% University of Minnesota %% +1 (612) 625-1809 %%
Christopher Bongaarts
It doesn't present any syntactic difficulties for old perls (it will
compile and execute the statement; it just won't store or read any
data), so perhaps having a runtime version check that carps an
appropriate warning would be appropriate.
Quanah Gibson-Mount
<c...@umn.edu> wrote:
> Graham Barr wrote:
>> On Feb 10, 2010, at 9:35 AM, Christopher Bongaarts wrote:
>>> Graham Barr wrote:
>>>
>>>> Also, anything that can dump to a filehandle can dump to a string.
>>>> open(my $fh,">",\my $buffer);
>>>> then pass $fh as the file handle
>>> Only in perl >= 5.8. Perl 5.6 and earlier won't support this syntax,
>>> so I would advise against using this to implement and ldif() method
>>> unless you are OK with breaking compatibility with older perls...
>>
>> 5.8.0 was released nearly 8 years ago. Anyone who is still using a
>> version of perl that old will not mind using an old version of Net::LDAP
>> IMO.
I disagree with this statement. ;) RHEL4, for example, ships with perl
5.8.5, and remains one of the most widely deployed Linux distributions in
the corporate environment. Not to stop the march of progress or anything,
as 5.10+ modules are growing, but there will be people who mind. We build
our own perl module stack for shipping with Zimbra because we need to know
the modules behave consistently across all OSes and to resolve bugs we've
hit with with the vendor distributed versions. For Net::LDAP, I will have
to peg it at whatever is the last release that works with 5.8 which is
fine, since I have no known issues with it at this point. But there's
probably someone who'll not like the change. ;)
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount
<pe...@peknet.com> wrote:
> Quanah Gibson-Mount wrote on 2/16/10 11:58 AM:
>> --On Monday, February 15, 2010 2:21 PM -0600 Christopher Bongaarts
>> <c...@umn.edu> wrote:
>>
>>> Graham Barr wrote:
>>>> On Feb 10, 2010, at 9:35 AM, Christopher Bongaarts wrote:
>>>>> Graham Barr wrote:
>>>>>
>>>>>> Also, anything that can dump to a filehandle can dump to a string.
>>>>>> open(my $fh,">",\my $buffer);
>>>>>> then pass $fh as the file handle
>>>>> Only in perl >= 5.8. Perl 5.6 and earlier won't support this syntax,
>>>>> so I would advise against using this to implement and ldif() method
>>>>> unless you are OK with breaking compatibility with older perls...
>>>>
>>>> 5.8.0 was released nearly 8 years ago. Anyone who is still using a
>>>> version of perl that old will not mind using an old version of
>>>> Net::LDAP IMO.
>>
>> I disagree with this statement. ;) RHEL4, for example, ships with perl
>> 5.8.5, and remains one of the most widely deployed Linux distributions
>> in the corporate environment.
>
> I didn't hear the OP referring to 5.8.x as "old" but as anything prior to
> 5.8.0 as old. The 5.6.x line is officially unsupported[0] so I think
> Christopher is correct.
Ah, okay, my mistake. I misread that as 5.8.x instead of 5.8.0. ;)
Peter Karman
> <c...@umn.edu> wrote:
>
>> Graham Barr wrote:
>>> On Feb 10, 2010, at 9:35 AM, Christopher Bongaarts wrote:
>>>> Graham Barr wrote:
>>>>
>>>>> Also, anything that can dump to a filehandle can dump to a string.
>>>>> open(my $fh,">",\my $buffer);
>>>>> then pass $fh as the file handle
>>>> Only in perl >= 5.8. Perl 5.6 and earlier won't support this syntax,
>>>> so I would advise against using this to implement and ldif() method
>>>> unless you are OK with breaking compatibility with older perls...
>>>
>>> 5.8.0 was released nearly 8 years ago. Anyone who is still using a
>>> version of perl that old will not mind using an old version of Net::LDAP
>>> IMO.
>
> I disagree with this statement. ;) RHEL4, for example, ships with perl
> 5.8.5, and remains one of the most widely deployed Linux distributions
> in the corporate environment.
I didn't hear the OP referring to 5.8.x as "old" but as anything prior to 5.8.0
as old. The 5.6.x line is officially unsupported[0] so I think Christopher is
correct.
[0] http://www.perl.com/download.csp#previous
--
Peter Karman . http://peknet.com/ . pe...@peknet.com