[Pkg-openldap-devel] Bug#530519: Bug#530519: Bug#530519: /usr/bin/ldapsearch: ldap-utils: ldapsearch always cut output into 76-character length lines

[Russ Allbery]

spg <bugreporter at udmvt.ru> writes:

> Yes, I understand that reasoning, that feature is sometimes really
> very useful.  But there are another feature - impossibility to turn
> the first feature off.  How about that?

I can see wanting to turn off wrapping, particularly in combination with
-tt.  I'm not sure what upstream would think, since I'm sure the output
format uses the same logic and I'm not sure they'd want to maintain a
special case for this.

I think you'd probably be best-off discussing the use case directly with
upstream as an upstream ITS, since you can tell them better how you're
using this and what the issues are, and I'm not sure upstream would
really want to see a proxy bug report from us.

Upstream's issue tracking interface is at:

    http://www.openldap.org/its/

> I just asked about non-LDIF output. Just for scripts. How about -ttt
> switch?

>     -ttt       is like -tt, but not affected by arbitrary line length limits
>                and outputs lines with urls as is without
>                wrapping/folding them.
> Cool?

It makes sense to me, but I don't know how the code is structured.

> By the way, ldapsearch does not know anything about locale. That is
> not so bad, since there is no re(en)coding errors introduced into the
> data flow. But it tries to guess whether a string is printable or not
> using single-byte functions against UTF8-encoded multibyte data, it
> randomly decides about incoming strings and binary fields whether to
> include them into the output verbatim, or to stuff them into base64.
> That is another incredibly stupid feature, and it forced me to always
> use -tt switch to turn that feature off and always stuff everything
> into files and pipe the output through a really simple script.

Hm, are you sure about this?  If it's doing single-byte comparisons
against UTF-8, that's certainly a bug.  However, the behavior that I
would expect is that anything that isn't ASCII would be encoded in
base64.  Is that what you're meaning to describe?  That's required by
the LDIF standard, so I'm sure that upstream would say that's not a bug.

> Or should we instead include in Debian package some useful program,
> that will parse LDIF and will help others to use ldapsearch from
> shell? What do you think?

I think that I definitely do not have the time to write such a thing.  :)

Every time I've worked with this, I've unwrapped the output and decoded
base64 where needed.

>> The output without -L isn't actually in LDIF, just in something that
>> looks very similar to LDIF (which the man page calls extended LDIF).
>> Here's the full paragraph from the current man page:

>>    -L     Search results are  display  in  LDAP  Data  Interchange  Format
>>           detailed  in  ldif(5).   A  single  -L  restricts  the output to
>>           LDIFv1.  A second -L disables comments.   A  third  -L  disables
>>           printing of the LDIF version.  The default is to use an extended
>>           version of LDIF.

>> Note the last sentence.

> I'm not insisting on that.

> That's it, I just suggested moving that sentence to the beginning of
> the description of "-L" or copy to the DESCRIPTION part of manpage.
> ldapsearch provides no way to output in non-LDIF-like format, but that
> fact was not intuitively clear for me until I downloaded the sources.
> Maybe I'm stupid.

Adding the statement "The attributes are displayed using an extended
version of LDIF." to the description seems like a good idea to me.  I'll
file an upstream ITS requesting that.

-- 
Russ Allbery (rra at debian.org)               <http://www.eyrie.org/~eagle/>