LDAP - Net::LDAP::LDIF re-correction

Author

Net::LDAP::LDIF re-correction

Gergely Sánta

2006-01-10, 7:31 pm

Hi!

It seems, the problem is in my perl-experience.. I generated an
another, bigger bug with my change, the trailing '\n'-s of lines
wasn't removed.. So those lines wasn't equivalent at all :(

I'm attaching a diff of my changes, which now works fine for me..

I hope, these changes do solve the problem with memory-files.

Regards,
Gergely

PS: I know, I should post this to mailing-list, but as I mentioned in
my previous letter, I think, this change should be the solution for
this problem...
85c85
< local $/;
---
> local $/ = "";
112,115d111
< foreach my $ln (@ldif) {
< chomp $ln;
< }
< ï¿¼

Quanah Gibson-Mount

2006-01-10, 7:31 pm

--On Tuesday, January 10, 2006 5:29 PM +0100 Gergely S=C3=A1nta=20
<Gergely_Santa@tempest.sk> wrote:

> Hi!
>
> It seems, the problem is in my perl-experience.. I generated an another,
> bigger bug with my change, the trailing '\n'-s of lines wasn't removed..
> So those lines wasn't equivalent at all :(
>
> I'm attaching a diff of my changes, which now works fine for me..

Generally the standard is to use "diff -u" not just "diff", as the default=20
output is pretty useless to use to apply as a patch.

--Quanah

--
Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

Gergely SÃ¡nta

2006-01-11, 3:59 am

--Quanah Gibson-Mount wrote:

>
> --On Tuesday, January 10, 2006 5:29 PM +0100 Gergely SÃ¡nta
> <Gergely_Santa@tempest.sk> wrote:
>
>
>
> Generally the standard is to use "diff -u" not just "diff", as the
> default output is pretty useless to use to apply as a patch.
>
> --Quanah
>
Ok, sorry, I didn't know.. Here is the "diff -u" with another little change.
After some googling on $INPUT_RECORD_SEPARATOR ($/), I found that the
difference between '$/ = undef' and '$/ = ""' is, that the second one
will treat two or more consecutive empty lines as a single empty line.
For this reason I added an additional line '$ln =~ s/\n\n+/\n\n/sg;'.

Maybe this isn't the best solution for accepting memory-files too, but
it works fine. I hope, it is not generating another bug to code.. Now
this works for buffers too:

my $buff = <LDIF_buffer>;
open $fd, '<', \$buff;
$ldif = Net::LDAP::LDIF->new($fd);
....
$ldif->done ( );
close $fd;

--Gergely

Chris Ridd

2006-01-11, 3:59 am

On 11/1/06 8:21, Gergely S=E1nta <Gergely_Santa@tempest.sk> wrote:

> --Quanah Gibson-Mount wrote:
>=20
> Ok, sorry, I didn't know.. Here is the "diff -u" with another little chan=
ge.
> After some googling on $INPUT_RECORD_SEPARATOR ($/), I found that the
> difference between '$/ =3D undef' and '$/ =3D ""' is, that the second one
> will treat two or more consecutive empty lines as a single empty line.
> For this reason I added an additional line '$ln =3D~ s/\n\n+/\n\n/sg;'.
>=20
> Maybe this isn't the best solution for accepting memory-files too, but
> it works fine. I hope, it is not generating another bug to code.. Now
> this works for buffers too:

What happens if your string contains lines terminated by "\r\n" (DOS-style)
or just "\r" (Classic MacOS-style) instead of just "\n" (Unix-style)? I'm
not sure if LDIF allows the Classic MacOS-style, but I'm sure it allows the
other two.

I'm too lazy too look ;-) and since you've got the code in your editor...
:-))

Cheers,

Chris

Gergely Sánta

2006-01-11, 3:59 am

Chris Ridd wrote:

>On 11/1/06 8:21, Gergely Sánta <Gergely_Santa@tempest.sk> wrote:
>
>
>
>
>What happens if your string contains lines terminated by "\r\n" (DOS-style)
>or just "\r" (Classic MacOS-style) instead of just "\n" (Unix-style)? I'm
>not sure if LDIF allows the Classic MacOS-style, but I'm sure it allows the
>other two.
>
>I'm too lazy too look ;-) and since you've got the code in your editor...
>:-))
>
>Cheers,
>
>Chris
>
Yep, I had on mind that too, but I also killed too much time for this problem :( This caused me a 2-day lag in my work, so I have no time for experimenting with specific cases, sorry. I only know, that this solves my problem (running on Linux and Solaris)
, and hope, it will help to others with same needs too.
Added a "\r" removing line, which will allow DOS-style LDIFs. It seems to me, it not allows MacOS-style, but maybe I'm wrong.

Cheers,

Gergely

Peter Marschall

2006-01-12, 7:11 pm

Hi,

On Wednesday, 11. January 2006 10:10, Gergely S=C3=A1nta wrote:
> Chris Ridd wrote:
>
> Yep, I had on mind that too, but I also killed too much time for this
> problem :( This caused me a 2-day lag in my work, so I have no time for
> experimenting with specific cases, sorry. I only know, that this solves my
> problem (running on Linux and Solaris), and hope, it will help to others
> with same needs too. Added a "\r" removing line, which will allow DOS-sty=
le
> LDIFs. It seems to me, it not allows MacOS-style, but maybe I'm wrong.

There have been extensive changes to Nt::LDAP::LDIF which are currently
in SVN.
According to the output of the test program they should solve your problem.

To obtain the file simply grab it from:
http://svn.mutatus.co.uk/wsvn/perl-...IF.pm?op=3Dfil=
e&rev=3D0&sc=3D0

Regards
Peter
=2D-=20
Peter Marschall
eMail: peter@adpm.de

Gergely SÃ¡nta

2006-01-13, 4:02 am

Peter Marschall wrote:

>Hi,
>
>On Wednesday, 11. January 2006 10:10, Gergely SÃ¡nta wrote:
>
>
>
>There have been extensive changes to Nt::LDAP::LDIF which are currently
>in SVN.
>According to the output of the test program they should solve your problem.
>
>To obtain the file simply grab it from:
>http://svn.mutatus.co.uk/wsvn/perl-...file&rev=0&sc=0
>
>Regards
>Peter
>
>
It's working, thanks for the reply!

Gergely

Sponsored Links