[Date Prev][Date Next]
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.
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.