[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ldap tool result codes

At 08:12 PM 1/20/2006, Hallvard B Furuseth wrote:
>I'm going through long-forgotten threads...
>In October, I suggested that we should change the LDAP tools
>(clients/tools/*) to always exit with some LDAP error code,

I note that in some cases the tools do return LDAP result codes
or LDAP API error codes.

I wonder how scripters are suppose to distinguish LDAP_OPERATONS_ERROR

>and some special code when it cannot or when an LDAP code does not
>make sense (e.g. when no LDAP operation was performed).
>Should I go ahead and do that?  Or should it not be done?

What about using sysexits(3) codes (where available)?

>On Unix, it can return 0-255 - but I think the range should be
>at most 0-127, since shells tend to return 128 and up if the
>process terminated due to a signal.  Some code(s) will be needed
>for error returns that do not come from LDAP protocol.  And some
>code(s) for protocol result codes outside the range of result
>codes which can be handled this way - including when the server
>returns the particular codes which we make use of this way.

FreeBSD exit(2)
  Passing arbitrary values back to the environment as status is considered
  bad style; you should use the values EXIT_SUCCESS and EXIT_FAILURE. If
  portability is not a concern, you may use the values described in

>On non-Unix, I have no idea... Hopefully someone else knows.
>RFC 2251 reserved result codes 81-90 for the client,

Unforunately, these result codes can and do (inappropriately)
appear on the wire.

>so it might
>be natural to use some these - even if the updated LDAP protocol
>draft does not reserve them.

>The reason I got interested is some cleanup for the test suite
>I've got lying around.  The tests sometimes check LDAP result
>codes, sometimes not.  It's hard to get that correctly - and to
>see if it is correct - when clients sometimes return result
>codes and sometimes just do exit(EXIT_FAILURE) or whatever.
>I've got some cleanup to the test suite lying around, but I'd
>like to know what to do about this issue first.