Kurt D. Zeilenga wrote:
At 08:12 PM 1/20/2006, Hallvard B Furuseth wrote:
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).
On non-Unix, I have no idea... Hopefully someone else knows.
On systems that have some notion of a Bourne-style command shell, they
generally emulate Unix behavior. I suppose since our test scripts
require a POSIX environment in the first place, we can assume the rest.
I note that IBM mainframes typically only used return codes that are
multiples of 4, but even they conform to POSIX when running an
appropriate shell. Anyway, POSIX says the return value is the least
significant 8 bits of the exit() value (or return() if the program
terminated that way). That means it's necessarily an unsigned byte's
worth of info, so we can't express the LDAP API error codes, as they're
all negative integers.
If we're going to try to make this consistent, then I'd say all we can
rely on is zero and non-zero. To get anything more specific we're going
to have to rely on diagnostics that the tools write to stderr. I guess
that means we should standardize on an easily parsable format for those,
e.g. "Result: 49 - invalid credentials" where the numeric code is always
a known field of the message.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
