[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: ldap tool result codes
Kurt D. Zeilenga writes:
>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
> from EXIT_FAILURE...
By magic, I think. There seems to be some system to it, enough that we
don't have a lot of ITSes about the test suite making use of it, but
IIRC there even in these cases it's not consistent.
>> 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)?
Hmmm... actually, I can't even find a suitable sysexit code for "maybe
not a program or user error, but LDAP operation yielded non-success",
much less most specific LDAP result codes.
http://resin.csoft.net/cgi-bin/man.cgi?section=3&topic=sysexits
>> 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 sysexits(3).
Well, the clients already do have code which doesn't follow that advice.
However, a variant could be to add an option which means "return a
result code if possible", and to return EXIT_SUCCESS/EXIT_FAILURE
otherwise. Dunno what to do about the code which already returns
something else by default, in particular for ldapcompare which is more
likely than the other programs to be in use for the sake of its exit
status.
>> 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.
That's all right, the program would just treat that as an LDAP result
code it can't return. Just like codes like LDAP_X_NO_OPERATION
(0x410e).
>> so it might be natural to use some these - even if the updated LDAP
>> protocol draft does not reserve them.
--
Hallvard