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

[spg]

On Mon, May 25, 2009 at 01:14:29PM -0700, Russ Allbery wrote:
> spg <bugreporter at udmvt.ru> writes:
> 
> > This does not depend on tty width.
> > Also no piece of code checks to see if output is a tty.
> > Output example:
> > mail:< file:///tmp/ldapsearch-mail-gA0v8v
> > msExchHomeServerName:< file:///tmp/ldapsearch-msExchHomeServerName-y5RfdB
> > msExchMailboxSecurityDescriptor:< file:///tmp/ldapsearch-msExchMailboxSecurit
> >  yDescriptor-y7G0hG
> > msExchUserAccountControl:< file:///tmp/ldapsearch-msExchUserAccountControl-K9
> >  yMmL
> > msExchMailboxGuid:< file:///tmp/ldapsearch-msExchMailboxGuid-eHEzrQ
> > End of example.
> 
> I think it's fairly unlikely that upstream is going to change this, and
> I don't think this is a place where Debian should diverge from upstream.
> You could try to talk upstream into it, but I suspect that always
> folding at a "safe" column width is intentional.  It does make it less
> likely that LDIF will be mangled when cut and paste or sent via e-mail.
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?
Anyway there is no real usefulness in sending an email with LDIF, that was
generated with -tt switch, unless it is modified to have urls that refer to email
attachments, and there is an mime-entry for LDIF in MUA's database to parse
and display LDIF with correct program. I haven't found such program in Debian. :(
But of course I still can underestimate that use case.
> 
> > That happens even if output is a pipe to a script and that results in
> > mentioned files being not found by that script.
> 
> I can predict what upstream's response would be to this: LDIF may be
> folded; that's part of the specification of LDIF.  Anything that
> consumes LDIF has to deal with folded lines.
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?

> 
> I'm sympathetic to not wanting scripts to have to deal with full LDIF,
> but I suspect you'll find it easiest to just write a simple unfolding
> script and through that in the pipeline after ldapsearch.
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.
Now another feature made that simple script less readable and not simple anymore.
I guess, someday the script will grow larger than ldapsearch itself and eventually augment it's functionality.
:)
Sad, but that makes it impossible to use ldapsearch in shell scripts AsIs,
since there is really no reason for that.
There is no practical reason to require extra programming to access LDAP
from shell given the existence of ldapsearch, isn't it?
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?

By the way, perhaps there are other tools for that?
I have tried all other Debian-provided packages that can run from shell, make ldap queries
and write them to the stdout. I have found, that there is two alternatives: using this ldapsearch
and writing my own ldapsearch.
Perhaps I have overlooked something?
I feel like I'm doing the common things in an incorrect way.

> 
> > NB: I use xterm and my terminal have a line width of 125
> 
> Yeah, one can tell from your e-mail.  :)
> 
> > The manpage says " -L Search results are display in LDAP Data
> > Interchange Format detailed in ldif(5)."  That makes the reader think,
> > that LDIF output is switched by -L switch.  It would be better to
> > explicitly express, that output is ALWAYS in LDIF format and that fact
> > is not related to -L option, since only the version and other details
> > of LDIF is affected by -L.
> 
> 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.

> 
> Here are the differences between no option and -L, for example:
> 
> --- foo 2009-05-25 13:09:57.000000000 -0700
> +++ foo.1       2009-05-25 13:09:51.000000000 -0700
> @@ -1,4 +1,5 @@
> -# extended LDIF
> +version: 1
> +
>  #
>  # LDAPv3
>  # base <dc=stanford,dc=edu> (default) with scope subtree
> @@ -261,8 +262,6 @@
>  suPrivilegeGroup: ra-supportanalyst:remedy
>  
>  # search result
> -search: 5
> -result: 0 Success
>  
>  # numResponses: 3
>  # numEntries: 2
> 
> Note the addition of the version specification, which is required for
> LDIF, and (most significantly) the suppression of the
> "pseudo-attributes" for the search.
> 
> -- 
> Russ Allbery (rra at debian.org)               <http://www.eyrie.org/~eagle/>

Thanks a lot.
It was a pleasure to talk with you anyway.