Menu
▾
▴
perl-ldap-dev
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(200) |
Jun
(129) |
Jul
(184) |
Aug
(204) |
Sep
(106) |
Oct
(79) |
Nov
(72) |
Dec
(54) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(83) |
Feb
(123) |
Mar
(84) |
Apr
(184) |
May
(106) |
Jun
(111) |
Jul
(104) |
Aug
(91) |
Sep
(59) |
Oct
(99) |
Nov
(100) |
Dec
(37) |
| 2002 |
Jan
(148) |
Feb
(88) |
Mar
(85) |
Apr
(151) |
May
(80) |
Jun
(110) |
Jul
(85) |
Aug
(43) |
Sep
(64) |
Oct
(89) |
Nov
(59) |
Dec
(42) |
| 2003 |
Jan
(129) |
Feb
(104) |
Mar
(162) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Graham B. <gb...@po...> - 2001-03-29 08:50:58
|
On Thu, Mar 29, 2001 at 09:07:37AM +1000, David Richards wrote: > printf( "Searching...\n" ); > $count = 0; > $res = $ldap->search( base => $LDAP_BASE, filter => > "(objectclass=QUTmailPerson)", > attrs => ['uid', 'mailUID', 'QUTmailbox', > 'mailboxQuota', 'cn' ], > callback => &LDAP_callback() ); That needs to be \&LDAP_callback In its current form you are calling the function and passing its results to ->search() which is NOT what you want. Graham. |
|
From: Graham B. <gb...@po...> - 2001-03-29 08:50:30
|
Yes you can. I suggest you read the the following RFC The String Representation of LDAP Search Filters http://www.ietf.org/rfc/rfc2254.txt Graham. On Wed, Mar 28, 2001 at 01:35:53PM -0500, S Balasubramaniyan wrote: > Can we have a multiple filter , ie,search based on more than one attribute. > S Bala > > > -----Original Message----- > From: Graham Barr [mailto:gb...@po...] > Sent: Wednesday, March 28, 2001 11:51 AM > To: Chris Ridd > Cc: LDAP Mailing List; Balasubramaniyan, S [CAR:0A02:EXCH] > Subject: Re: [Fwd] Perl-LDAP-0.22 > > > On Wed, Mar 28, 2001 at 05:23:46PM +0100, Chris Ridd wrote: > > Graham Barr <gb...@po...> wrote: > > > ----- Forwarded message from S Balasubramaniyan > > > <sb...@no...> ----- > > > > my $result = $ldap->search ( > > > base => "o=nortel", > > > filter => "unique_key=12345", > > > > That is not a legal filter that conforms to RFC 2254. At the very least > > this should be: > > > > filter => "(unique_key=12345)", > > This is such a common mistake that Net::LDAP::Filter does > > $filter = "(" . $filter . ")" > unless $filter =~ /^\(/; > > > Graham. |
|
From: S B. <sb...@no...> - 2001-03-29 02:28:29
|
Can we have a multiple filter , ie,search based on more than one attribute.
S Bala
-----Original Message-----
From: Graham Barr [mailto:gb...@po...]
Sent: Wednesday, March 28, 2001 11:51 AM
To: Chris Ridd
Cc: LDAP Mailing List; Balasubramaniyan, S [CAR:0A02:EXCH]
Subject: Re: [Fwd] Perl-LDAP-0.22
On Wed, Mar 28, 2001 at 05:23:46PM +0100, Chris Ridd wrote:
> Graham Barr <gb...@po...> wrote:
> > ----- Forwarded message from S Balasubramaniyan
> > <sb...@no...> -----
> > my $result = $ldap->search (
> > base => "o=nortel",
> > filter => "unique_key=12345",
>
> That is not a legal filter that conforms to RFC 2254. At the very least
> this should be:
>
> filter => "(unique_key=12345)",
This is such a common mistake that Net::LDAP::Filter does
$filter = "(" . $filter . ")"
unless $filter =~ /^\(/;
Graham.
|
|
From: David R. <d.r...@qu...> - 2001-03-28 23:10:23
|
Hi,
I have scoured the archives and while found some interesting posts,
nothing that I could get to work for my situation.
I am performing a search that will return lots of entries from the
directory (about 50,000) and I am getting the error 'Out of memory!'
which is not suprising. So, I started writing a search that uses a
callback, which will shift the returned entry off the results list, thus
(in theory) not running out of memory.
Here are the code segments:
printf( "Searching...\n" );
$count = 0;
$res = $ldap->search( base => $LDAP_BASE, filter =>
"(objectclass=QUTmailPerson)",
attrs => ['uid', 'mailUID', 'QUTmailbox',
'mailboxQuota', 'cn' ],
callback => &LDAP_callback() );
sub LDAP_callback {
my ( $mesg, $entry ) = @_;
printf( "Start Callback\n");
if( ! defined( $mesg ) ) {
printf( "MESG Not defined\n" );
if( ! defined( $entry ) ) {
printf( "ENT Not defined\n" );
}
} else {
$mesg->shift_entry();
printf( "Got entry: %d\n", $count++ );
}
printf( "End Callback\n");
}
This is on the way to building a much larger peice of code, so for now
just knowing I got the entries will do. So, this produces the output:
Searching...
Start Callback
MESG Not defined
ENT Not defined
End Callback
Can't use string ("1") as a subroutine ref while "strict refs" in use at
/usr/lib/perl-5.005/lib/site_perl/5.005/Net/LDAP/Search.pm line 51.
Any idea, help or pointers would be greatly appreciated.
Thanks,
--
David Richards
Project Manager (Messaging)
Information Technology Services
Queensland University of Technology
|
|
From: Gad, G. A <GG...@UH...> - 2001-03-28 22:15:07
|
We got a this space error on the Netscape Directory Server admin error log. Does any one know what it means, or where I can find out information about it? : [28/Mar/2001:04:16:58 -0600] - idl_store(*s@m) returns 12 Not enough space [28/Mar/2001:04:16:58 -0600] - idl_insert_key 5 BAD 12 Not enough space [28/Mar/2001:04:16:58 -0600] - addordel_values 1.5 BAD 12 [28/Mar/2001:04:16:58 -0600] - addordel_values 2 BAD 12 [28/Mar/2001:04:16:58 -0600] - index_addordel_values 5 BAD 12 [28/Mar/2001:04:16:58 -0600] - index_add_mods BAD 12 [28/Mar/2001:04:16:58 -0600] - index_add_mods failed, err=12 Not enough space [28/Mar/2001:04:16:58 -0600] - Serious Error---Failed in dblayer_txn_abort, err=12 (Not enough space) [28/Mar/2001:04:16:59 -0600] - housecleaning PR_CreateThread failed reply to: gg...@uh... Gerges Gad, MT(ASCP) Internet/Intranet Developer III IT-TSS Information Services www.uh.edu/~ggad "Counsel in the heart of man is like deep water, But a man of understanding will draw it out" (Prov 20:5) |
|
From: S B. <sb...@no...> - 2001-03-28 17:05:06
|
Hi ,
I was able to locate the problem ..
The base for the v3 infrastructure has changed .
I had to change the base to "o=NortelNetworks" and Now it works.
Nothing technical 'bout it.
Thanx much,
S Bala
-----Original Message-----
From: Graham Barr [mailto:gb...@po...]
Sent: Wednesday, March 28, 2001 10:14 AM
To: LDAP Mailing List
Cc: Balasubramaniyan, S [CAR:0A02:EXCH]
Subject: [Fwd] Perl-LDAP-0.22
----- Forwarded message from S Balasubramaniyan <sb...@no...>
-----
Date: Wed, 28 Mar 2001 10:11:41 -0500
To: "'gb...@po...'" <gb...@po...>
From: "S Balasubramaniyan" <sb...@no...>
Subject: Perl-LDAP-0.22
X-Mailer: Internet Mail Service (5.5.2653.19)
Hi Graham,
Iam currently programming with your perl-ldap-0.22 module
, its quite interesting.
But i have a query , does your module support ldap v3 ?
Perhaps mine is just a layman question as i could not run my piece of
code for ldap v3 server.
My piece of code which runs in v2 but not in v3 is :
=========================================
#!/usr/bin/perl
use Net::LDAP qw(:all);
$ldap = Net::LDAP->new("ldapv2-server") or die "$@";
$mesg = $ldap->bind;
my $result = $ldap->search (
base => "o=nortel",
filter => "unique_key=12345",
);
$ldap->unbind;
@entries = $result->entries;
foreach $entr ( @entries )
{
my @attrs = sort $entr->attributes;
my $attr;
foreach $attr ( $entr->attributes ){
print "$attr : ",$entr->get_value($attr),"\n";
}
}
==============================================
can you please comment on this ?
Thanx in advance ,
S Bala
............................................................................
...........
S Balasubramaniyan- sb...@no...
International R&D Operations (IRDO)
Nortel Networks - 3500 Carling Ave, Ottawa ON, K2H8E9
ESN: 6-398-0247
----- End forwarded message -----
|
|
From: Chris R. <chr...@me...> - 2001-03-28 17:04:55
|
Graham Barr <gb...@po...> wrote:
> On Wed, Mar 28, 2001 at 05:23:46PM +0100, Chris Ridd wrote:
>> Graham Barr <gb...@po...> wrote:
>> > ----- Forwarded message from S Balasubramaniyan
>> > <sb...@no...> -----
>
>> > my $result = $ldap->search (
>> > base => "o=nortel",
>> > filter => "unique_key=12345",
>>
>> That is not a legal filter that conforms to RFC 2254. At the very least
>> this should be:
>>
>> filter => "(unique_key=12345)",
>
> This is such a common mistake that Net::LDAP::Filter does
>
> $filter = "(" . $filter . ")"
> unless $filter =~ /^\(/;
>
>
> Graham.
>
I suspected it might do :-)
Cheers,
Chris
|
|
From: Graham B. <gb...@po...> - 2001-03-28 16:52:11
|
On Wed, Mar 28, 2001 at 05:23:46PM +0100, Chris Ridd wrote:
> Graham Barr <gb...@po...> wrote:
> > ----- Forwarded message from S Balasubramaniyan
> > <sb...@no...> -----
> > my $result = $ldap->search (
> > base => "o=nortel",
> > filter => "unique_key=12345",
>
> That is not a legal filter that conforms to RFC 2254. At the very least
> this should be:
>
> filter => "(unique_key=12345)",
This is such a common mistake that Net::LDAP::Filter does
$filter = "(" . $filter . ")"
unless $filter =~ /^\(/;
Graham.
|
|
From: Chris R. <chr...@me...> - 2001-03-28 16:23:55
|
Graham Barr <gb...@po...> wrote:
> ----- Forwarded message from S Balasubramaniyan
> <sb...@no...> -----
>
> Date: Wed, 28 Mar 2001 10:11:41 -0500
> To: "'gb...@po...'" <gb...@po...>
> From: "S Balasubramaniyan" <sb...@no...>
> Subject: Perl-LDAP-0.22
> X-Mailer: Internet Mail Service (5.5.2653.19)
>
> Hi Graham,
> Iam currently programming with your perl-ldap-0.22
> module , its quite interesting.
> But i have a query , does your module support ldap v3 ?
> Perhaps mine is just a layman question as i could not run my piece of
> code for ldap v3 server.
> My piece of code which runs in v2 but not in v3 is :
> =========================================
> #!/usr/bin/perl
> use Net::LDAP qw(:all);
You do not need (or want) to import all the module's symbols. Just do 'use
Net::LDAP;'
> $ldap = Net::LDAP->new("ldapv2-server") or die "$@";
> $mesg = $ldap->bind;
You have not specified what LDAP version to bind with. The default is
LDAPv2. You need to specify if you want LDAPv3. I assume the default is
LDAPv2 as that is likely to work with more servers.
> my $result = $ldap->search (
> base => "o=nortel",
> filter => "unique_key=12345",
That is not a legal filter that conforms to RFC 2254. At the very least
this should be:
filter => "(unique_key=12345)",
Cheers,
Chris
|
|
From: Graham B. <gb...@po...> - 2001-03-28 15:14:51
|
----- Forwarded message from S Balasubramaniyan <sb...@no...> -----
Date: Wed, 28 Mar 2001 10:11:41 -0500
To: "'gb...@po...'" <gb...@po...>
From: "S Balasubramaniyan" <sb...@no...>
Subject: Perl-LDAP-0.22
X-Mailer: Internet Mail Service (5.5.2653.19)
Hi Graham,
Iam currently programming with your perl-ldap-0.22 module
, its quite interesting.
But i have a query , does your module support ldap v3 ?
Perhaps mine is just a layman question as i could not run my piece of
code for ldap v3 server.
My piece of code which runs in v2 but not in v3 is :
=========================================
#!/usr/bin/perl
use Net::LDAP qw(:all);
$ldap = Net::LDAP->new("ldapv2-server") or die "$@";
$mesg = $ldap->bind;
my $result = $ldap->search (
base => "o=nortel",
filter => "unique_key=12345",
);
$ldap->unbind;
@entries = $result->entries;
foreach $entr ( @entries )
{
my @attrs = sort $entr->attributes;
my $attr;
foreach $attr ( $entr->attributes ){
print "$attr : ",$entr->get_value($attr),"\n";
}
}
==============================================
can you please comment on this ?
Thanx in advance ,
S Bala
............................................................................
...........
S Balasubramaniyan- sb...@no...
International R&D Operations (IRDO)
Nortel Networks - 3500 Carling Ave, Ottawa ON, K2H8E9
ESN: 6-398-0247
----- End forwarded message -----
|
|
From: Chris R. <chr...@me...> - 2001-03-28 08:53:34
|
Behruz Rushenas <beh...@cp...> wrote: > > Thanks Chris, > > Your questions helped me to figure out where was the problem. You are > right by the default it use the LDAP V2. so what I did, i specified > during the bind operation version=>3 and that solved my problem. Was the server sending back mangled values in the LDAPv2 case? In other words, do you think this is a bug in Net::LDAP :-) > Thanks again > > By the way how can you setup the PERL-LDAP to be V3 by default? There's no way to set the default using the API, but basically you could do something like this: $Net::LDAP::LDAP_VERSION = 3; in your code, before binding. Doing this would mean your code could break in future Net::LDAP releases, as this variable is not public. It seems to me better simply to specify the LDAP version you want when you bind - you are cleanly specifying what you want using a public API. > Thanks and have a nice day. > Behruz. Cheers, Chris |
|
From: Jason <im...@ac...> - 2001-03-27 00:35:30
|
That's not really an "ldap" topic. Although, our directory server(Netscape V4.12) uses an attribute, "employeestatus", with active=active user, and inactive=user with NO access to the directory. >"Lambright, Linda (N-Averstar)" wrote: > > Does anyone know what attribute or combination of attributes the > Netscape console uses to determine that a user's dn has been disabled or has > expired? > > Linda Lambright -- Regards, Jason H Carroll ********************************************* * * * \\\|/// * * \\ - - // * * (/ @ @ \) * * ---------oOOo-(_)-oOOo-------- * * __ * * / / _ * * / / (_)__ __ ____ __ * * / /__/ / _ \/ // /\ \/ / * * /____/_/_//_/\_._/ /_/\_\ * * * * --- Linux, WinNT, MS-DOS --- * * * * AKA: The good, the bad, and the ugly * * * * * ********************************************* |
|
From: Lambright, L. (N-Averstar) <lin...@lm...> - 2001-03-26 23:59:09
|
Does anyone know what attribute or combination of attributes the Netscape console uses to determine that a user's dn has been disabled or has expired? Linda Lambright |
|
From: Graham B. <gb...@po...> - 2001-03-26 08:31:11
|
On Sat, Mar 24, 2001 at 07:26:23AM -0000, Chris Ridd wrote: > > Are you saying an option to skip anything unknown and ignore extra at end > > of sequences, just as long as everything expected is extracted ? > > Something like that. > > > That sounds simple, but becomes more complex when you have to consider the > > situation where a new element is added before an existing element which is > > already optional. > > Hm. If we limited this to just ignoring stuff at the end would it be > simpler? Yes, I think that would be simpler to implement. Graham. |
|
From: Chris R. <chr...@me...> - 2001-03-24 07:29:49
|
Graham Barr <gb...@po...> wrote: > On Fri, Mar 23, 2001 at 05:22:33PM -0000, Chris Ridd wrote: >> (Obscure concern coming up!) >> >> I believe that LDAP clients/servers are meant to be able to ignore >> 'unexpected' elements in ASN.1 SEQUENCEs (RFC 2251 section 4 para 1). >> This is to promote compatibility with future clients/servers which may >> be using a version of the protocol with extra stuff in. >> > >> If there is only one extra parameter in the encoded SEQUENCE, the 'ANY' >> catches it, which is correct. More than one extra parameter though, and >> the decode rightly fails. > > I think this should be done as an option to the decoder, rather than > modifying the ASN.1 Yes, I tend to agree. >> What is needed (I think) is for a mechanism to allow for 'all remaining' >> elements of a SEQUENCE to end up in a single variable. In the >> Convert::BER days, this was done with a magic 'BER' type. This is OK if >> all the new extensions in the SEQUENCE are added at the end of the >> SEQUENCE - there's no guarantee that they will be all at the end of >> course... > > Hm, well I cannot see an easy way to support new elements anywhere without > a considerable slowdown. > >> Alternatively, there should be a way to configure a Convert::ASN1 object >> to ignore unknown things when decoding. (This option shouldn't be the >> default.) > > Are you saying an option to skip anything unknown and ignore extra at end > of sequences, just as long as everything expected is extracted ? Something like that. > That sounds simple, but becomes more complex when you have to consider the > situation where a new element is added before an existing element which is > already optional. Hm. If we limited this to just ignoring stuff at the end would it be simpler? > Graham. Cheers, Chris |
|
From: Behruz R. <beh...@cp...> - 2001-03-23 18:47:02
|
Thanks Chris, Your questions helped me to figure out where was the problem. You are right by the default it use the LDAP V2. so what I did, i specified during the bind operation version=>3 and that solved my problem. Thanks again By the way how can you setup the PERL-LDAP to be V3 by default? Thanks and have a nice day. Behruz. -----Original Message----- From: Chris Ridd [mailto:chr...@me...] Sent: Friday, March 23, 2001 3:40 AM To: perl-ldap Cc: Behruz Rushenas Subject: Re: (no subject) Behruz Rushenas <beh...@cp...> wrote: > Hi Graham, > > First of all thanks for the great job on LDAP. > I have a question concerning an ldap attribute which contains special > caraters such as "#". > When I call the function entry->get( attribute_name), the value is > returned with some special caracter instead of #. > How can i fix that. > > Thanks. > Behruz. > > > Net::LDAP doesn't do any particular mangling of the results from the directory. They're just stored in scalars, which can hold arbitrary octets including NUL bytes etc. Perhaps your server is returning mangled results, or alternatively perhaps Perl is doing something odd perhaps in the area of Unicode handling. What version of LDAP are you specifying in the bind? Remember the default is v2. You can peek at the bytes the server's returning by creating the Net::LDAP object with debug set to 4 (see the documentation for Net::LDAP->new). Cheers, Chris |
|
From: Graham B. <gb...@po...> - 2001-03-23 17:39:28
|
On Fri, Mar 23, 2001 at 05:22:33PM -0000, Chris Ridd wrote: > (Obscure concern coming up!) > > I believe that LDAP clients/servers are meant to be able to ignore > 'unexpected' elements in ASN.1 SEQUENCEs (RFC 2251 section 4 para 1). This > is to promote compatibility with future clients/servers which may be using > a version of the protocol with extra stuff in. > > If there is only one extra parameter in the encoded SEQUENCE, the 'ANY' > catches it, which is correct. More than one extra parameter though, and the > decode rightly fails. I think this should be done as an option to the decoder, rather than modifying the ASN.1 > What is needed (I think) is for a mechanism to allow for 'all remaining' > elements of a SEQUENCE to end up in a single variable. In the Convert::BER > days, this was done with a magic 'BER' type. This is OK if all the new > extensions in the SEQUENCE are added at the end of the SEQUENCE - there's > no guarantee that they will be all at the end of course... Hm, well I cannot see an easy way to support new elements anywhere without a considerable slowdown. > Alternatively, there should be a way to configure a Convert::ASN1 object to > ignore unknown things when decoding. (This option shouldn't be the default.) Are you saying an option to skip anything unknown and ignore extra at end of sequences, just as long as everything expected is extracted ? That sounds simple, but becomes more complex when you have to consider the situation where a new element is added before an existing element which is already optional. Graham. |
|
From: Chris R. <chr...@me...> - 2001-03-23 17:22:53
|
(Obscure concern coming up!)
I believe that LDAP clients/servers are meant to be able to ignore
'unexpected' elements in ASN.1 SEQUENCEs (RFC 2251 section 4 para 1). This
is to promote compatibility with future clients/servers which may be using
a version of the protocol with extra stuff in.
I don't think Net::LDAP can handle this. Well, I think this is really
something that Convert::ASN1 cannot handle. eg:
-------------------
my $decode = Convert::ASN1->new();
my $encode = Convert::ASN1->new();
# Attempt to allow for extra stuff when decoding
$decode->prepare(q<
SEQUENCE {
version INTEGER,
name OCTET STRING,
ext ANY OPTIONAL
}
>);
$encode->prepare(q<
SEQUENCE {
version INTEGER,
name OCTET STRING,
flag BOOLEAN,
foo PrintableString
}
>);
my $pdu = $encode->encode(version => 1,
name => 'cn=Chris Ridd',
flag => 1,
foo => 'foo');
my $o = $decode->decode($pdu);
# Returns undef.
-------------
If there is only one extra parameter in the encoded SEQUENCE, the 'ANY'
catches it, which is correct. More than one extra parameter though, and the
decode rightly fails.
What is needed (I think) is for a mechanism to allow for 'all remaining'
elements of a SEQUENCE to end up in a single variable. In the Convert::BER
days, this was done with a magic 'BER' type. This is OK if all the new
extensions in the SEQUENCE are added at the end of the SEQUENCE - there's
no guarantee that they will be all at the end of course...
Alternatively, there should be a way to configure a Convert::ASN1 object to
ignore unknown things when decoding. (This option shouldn't be the default.)
Does this make any sense?
Cheers,
Chris
|
|
From: Jose O. <JAO...@lb...> - 2001-03-23 14:30:08
|
I generally use the "if..." type constructions regardless of the programming
language I am using.
Thank you one and all.
John Berthels wrote:
> > $mesg->code && die $mesg->error;
> >
> > That would be a common perlism for do the first part, and if it succeeds,
> > then do the second part. You can also do that in UNIX shell.
>
> Yes, but it relies on the 'return code of zero is success' convention. The
> code is equivalent to:
>
> # Sorry...I like brackets on function/method calls
> if( $mesg->code() == 0 ) {
> die $mesg->error();
> }
>
> The ->code() method returns the LDAP result code of the operation the
> $mesg is the result of. LDAP follows the UNIX/C convention of 'return 0
> for success'.
>
> Note that this is the opposite of the convention used in perl, where
> functions and methods return a true value for success and a false value
> for failure.
>
> (Except for the system() call, which follows the Unix convention since it
> invokes a Unix command line (OK...or a WinNT command line)).
>
> So in perl you have the common idiom::
>
> open FOO, "< foo" || die "ack : $!";
>
> and there the '||' is replaced with a '&&' in the LDAP example code
> because of the different return convention.
>
> Yours pedantically,
>
> jb
|
|
From: Chris R. <chr...@me...> - 2001-03-23 11:43:28
|
Behruz Rushenas <beh...@cp...> wrote: > Hi Graham, > > First of all thanks for the great job on LDAP. > I have a question concerning an ldap attribute which contains special > caraters such as "#". > When I call the function entry->get( attribute_name), the value is > returned with some special caracter instead of #. > How can i fix that. > > Thanks. > Behruz. > > > Net::LDAP doesn't do any particular mangling of the results from the directory. They're just stored in scalars, which can hold arbitrary octets including NUL bytes etc. Perhaps your server is returning mangled results, or alternatively perhaps Perl is doing something odd perhaps in the area of Unicode handling. What version of LDAP are you specifying in the bind? Remember the default is v2. You can peek at the bytes the server's returning by creating the Net::LDAP object with debug set to 4 (see the documentation for Net::LDAP->new). Cheers, Chris |
|
From: John B. <joh...@ne...> - 2001-03-23 11:20:40
|
> Yes, but it relies on the 'return code of zero is success' convention. The
> code is equivalent to:
>
> # Sorry...I like brackets on function/method calls
> if( $mesg->code() == 0 ) {
> die $mesg->error();
> }
Sigh. Of course. I got the test the wrong way round. Should be !=.
> Yours pedantically,
Or possibly just stupidly,
jb
|
|
From: John B. <joh...@ne...> - 2001-03-23 10:40:57
|
> $mesg->code && die $mesg->error;
>
> That would be a common perlism for do the first part, and if it succeeds,
> then do the second part. You can also do that in UNIX shell.
Yes, but it relies on the 'return code of zero is success' convention. The
code is equivalent to:
# Sorry...I like brackets on function/method calls
if( $mesg->code() == 0 ) {
die $mesg->error();
}
The ->code() method returns the LDAP result code of the operation the
$mesg is the result of. LDAP follows the UNIX/C convention of 'return 0
for success'.
Note that this is the opposite of the convention used in perl, where
functions and methods return a true value for success and a false value
for failure.
(Except for the system() call, which follows the Unix convention since it
invokes a Unix command line (OK...or a WinNT command line)).
So in perl you have the common idiom::
open FOO, "< foo" || die "ack : $!";
and there the '||' is replaced with a '&&' in the LDAP example code
because of the different return convention.
Yours pedantically,
jb
|
|
From: Christoph N. <en...@ap...> - 2001-03-23 02:18:20
|
Jose, $mesg->code && die $mesg->error; That would be a common perlism for do the first part, and if it succeeds, then do the second part. You can also do that in UNIX shell. It's based on the order the operands are evaluted in an "AND" expression. Since Perl uses short circuit evaluation, it will only evaluate as little as possible to determine the true of a statment. In an "AND" statment, if the first part of the expression returns false, the second part does not need to be evaluated. - Christoph On Fri, 23 Mar 2001, Graham Barr wrote: > ----- Forwarded message from Jose Olivares <JAO...@LB...> ----- > > Date: Thu, 22 Mar 2001 09:45:55 -0800 > To: gb...@po... > From: Jose Olivares <JAO...@LB...> > Subject: Net::LDAP > X-Mailer: Mozilla 4.75C-CCK-MCD LBNL V4.73 Build 2 (Macintosh; U; PPC) > > Hi Graham - > > My name is Jose Olivares and I have just gotten access to the Net::LDAP > module for Perl. > > I have done lots of programming, but I have not done any object oriented > > programming. I am however quite familiar with concepts like > subroutines (methods in OOP?), data structures (objects?), etc. > > I am looking at the writeup for Net::LDAP. Under the Synopsis section > are a couple of examples. I can understand the code pretty much, even > if > I don't know the exact actions that are happening. However, there is a > piece that mystifies me. There is a line that says: > > $mesg->code && die $mesg->error; > > I can see that "$mesg->code" refers to a success or failure return code > and it > looks like the "die $mesg->error" part puts out the error message that > is in > the $mesg structure (I assume it is a structure). But taken together I > don't > really understand the above statement. What is the statement doing and > how > does it know what to do? > > Thanks. > > - Jose Olivares > > > ----- End forwarded message ----- > > |
|
From: Graham B. <gb...@po...> - 2001-03-23 00:05:48
|
----- Forwarded message from Jose Olivares <JAO...@LB...> ----- Date: Thu, 22 Mar 2001 09:45:55 -0800 To: gb...@po... From: Jose Olivares <JAO...@LB...> Subject: Net::LDAP X-Mailer: Mozilla 4.75C-CCK-MCD LBNL V4.73 Build 2 (Macintosh; U; PPC) Hi Graham - My name is Jose Olivares and I have just gotten access to the Net::LDAP module for Perl. I have done lots of programming, but I have not done any object oriented programming. I am however quite familiar with concepts like subroutines (methods in OOP?), data structures (objects?), etc. I am looking at the writeup for Net::LDAP. Under the Synopsis section are a couple of examples. I can understand the code pretty much, even if I don't know the exact actions that are happening. However, there is a piece that mystifies me. There is a line that says: $mesg->code && die $mesg->error; I can see that "$mesg->code" refers to a success or failure return code and it looks like the "die $mesg->error" part puts out the error message that is in the $mesg structure (I assume it is a structure). But taken together I don't really understand the above statement. What is the statement doing and how does it know what to do? Thanks. - Jose Olivares ----- End forwarded message ----- |
|
From: Behruz R. <beh...@cp...> - 2001-03-22 21:37:36
|
Hi Graham, First of all thanks for the great job on LDAP. I have a question concerning an ldap attribute which contains special caraters such as "#". When I call the function entry->get( attribute_name), the value is returned with some special caracter instead of #. How can i fix that. Thanks. Behruz. |
7902 messages has been excluded from this view by a project administrator.
