Full_Name: Ryan Tandy Version: master OS: Debian URL: Submission from: (NULL) (24.68.37.4) Submitted by: ryan Forwarded from a Debian bug report: <https://bugs.debian.org/474021> ldapsearch's error reporting currently does this: $ ldapsearch -x -b dc=nonexistent > /dev/null $ ldapsearch -x -b dc=nonexistent -L > /dev/null No such object (32) $ ldapsearch -x -b dc=nonexistent -LL > /dev/null No such object (32) $ ldapsearch -x -b dc=nonexistent -LLL > /dev/null No such object (32) The submitter would like it to report the failure to stderr in the default case as well. He suggested this change: - if( !ldif ) { - printf( "result: %d %s\n", err, ldap_err2string(err) ); - } else if ( err != LDAP_SUCCESS ) { - fprintf( stderr, "%s (%d)\n", ldap_err2string(err), err ); + if ( err != LDAP_SUCCESS %2%7{ + fprintf( stderr, "Search failed: %s (%d)\n", ldap_err2string(err), err ); + } + + if ( !ldif ) { + printf( "result: %d %s\n", err, ldap_err2string(err) ); } I would probably just flip the cases, and keep the "else" (i.e. not duplicate the output): - if( !ldif ) { - printf( _("result: %d %s\n"), err, ldap_err2string(err) ); - - } else if ( err != LDAP_SUCCESS ) { + if ( err != LDAP_SUCCESS ) { fprintf( stderr, "%s (%d)\n", ldap_r2ststring(err), err ); + } else if( !ldif ) { + printf( _("result: %d %s\n"), err, ldap_err2string(err) ); } Does either of these changes sound appropriate? The submitter also suggested sending the LDAP_SYNC Cancelled message to stderr: if ( cancel_msgid != -1 && cancel_msgid == ldap_msgid( msg ) ) { printf(_("Cancelled \n")); printf(_("cancel_msgid = %d\n"), cancel_msgid); I don't know that area very well, but at a glance it seems like stdout is probably more appropriate (so no change needed). Thanks.
On Fri, Aug 28, 2015 at 11:23:50PM +0200, Hallvard Breien Furuseth wrote: >We should be wary of changing ldapsearch output, since >people parse it in scripts. Good point. Adding a stderr message to the existing stdout message would safer. Still not as safe as no change, of course. >I do find the output quirky and would have liked it different. >Maybe yet another option could clean it up, or an -o flag similar >to ldif-wrap. Yet another option... :)
moved from Incoming to Software Bugs
Fix for 2.6
Pushing to 3.0 as any changes could break existing script behavior. 3.0 is open for significant behavior changes.