>> Will start spitting out "Found <dn>" lines immediately. In fact, it
>> doesn't - there is a rather long sleep period between "Here", and the
>> first "Found" line.
>> Is it because of the "foreach" loop?
>No, it is because calling entries() will block until all the entries have
>been returned :-)
I see. :-)
>Also the async option is only valid in the constructor as it is a per
>connection option. You can also call $ldap->async to turn on/off the
>connection's async flag. It isn't correct to pass async=>1 in a normal
>operation.
Well, I wasn't sure where to put it, so I've actually put it "everywhere"
(connect/bind/search) in the hope that it wan't do any harm if not needed.
:-)
It's only in constructor now...
>You might want to look at the Net::LDAP::Search man page, in particular
the
>pop_entry() and shift_entry() methods.
Ah, thx.
>Depending on what you're trying to achieve you might also consider
passing a
>callback to the search method, which will get called as every search
result
>is returned. See the CALLBACKS section of the Net::LDAP man page for some
>details of (oddly enough) callbacks.
Well, I'm browsing trough manpages all the time, and so I tried the
callback method in the meantime (looks nice, would in fact like to use
it), but that doesn't work the way I expected it will.
my $KMUsers = $KMLdap->search(filter=>'(uid=*)', scope=>'sub',
base=>$base,
attrs=>'1.1', sizelimit=>10,
callback=>\&myCallback);
print "END\n";
sub myCallback
{
my $mesg = shift;
my $entry = shift;
my $count = $mesg->count;
print "HERE\n";
printf "%5d Found (%s)\n", $count, $entry->dn;
}
I expected to see a lot of "HERE", followed by one "END", and possibly
even some DNs. Reality was different:
END
HERE
Hm. So the function exits first, and calls the callback afterwards? Don't
understand. :-(
help?
