Jim Summers wrote:
> Hello All,
>
> I was modifying the value of an attribute, automountInformation in
> this instance. The modify works as expected, but when I use
> ldapsearch to dump the entry containing the new value it seems to
> truncate it at 78 characters, that is (attribute name + attribute
> value). The remainder of the value is on the next line, which has
> caused some scripts to not work as expected.
>
> The manpage for ldapsearch did not reveal any clues or switches to get
> around this length limit. Could it be a server limit?
No. This is standard LDAP LDIF behavior.
If you're using perl, I suggest using either perldap or Net::LDAP - they
both have LDIF parsers that handle this nicely. If you're using python,
I think python-ldap also handles this. If you're using sh, see below.
>
> Interesting also is that db2ldif produces the same behavior.
>
> Ideas on what I could do to get the value retruned back on one line?
I'm not sure if /usr/bin/ldapsearch supports this, but
/opt/fedora-ds/shared/bin/ldapsearch has the -T option:
-T don't fold (wrap) long lines (default is to fold)
>
> STRANGE EXAMPLE OUTPUT:
> ===============
> automountInformation: -rw,actimeo=30,rsize=32768,wsize=32768
> fs001:/raid/facst
> aff/faharris
> ===============
>
> EXPECTED OUTPUT:
> ===============
> automountInformation: -rw,actimeo=30,rsize=32768,wsize=32768
> fs001:/raid/facstaff/faharris
> ===============
>
> The above examples may not be clear due to email wrapping, but in the
> first one ldapsearch truncates at the "t" and in the second there is
> not truncating.
>
> TIA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3178 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20060309/90694659/attachment.bin
