[
https://issues.apache.org/jira/browse/HADOOP-10816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14062313#comment-14062313
]
Mike Yoder commented on HADOOP-10816:
-------------------------------------
{quote}
Does this make sense to you too?
{quote}
Ever notice how the most inconsequential things spark the big disagreements? :-)
I'd really rather that both the comments about the return value in the code and
the tests against that code agree. So either say it returns one and test that
it returns 1, or say it returns a nonzero value and test that it returns a
nonzero value. I see what you're trying to get at, but...
{quote}
but also make sure that the code for a particular error doesn't change between
releases
{quote}
To be pedantic, if the contract says that it returns a small positive integer,
it does not matter what that integer is. It might "happen to" return 1, but
that's an implementation detail.
Or we could just say "it returns 1" in the contract and deal with the 1.
For all practical purposes, it seems highly unlikely that we're going to
introduce new error return values. So this whole argument is probably moot.
Or, we could actually define some different error codes:
# Argument processing error
# Command validation error
# Command execution error
I've uploaded patch 2 for your consideration, should we choose to go this way,
which says that it returns 1, and tests that it returns 1, and has the
following language:
{noformat}
+ * @return 0 on success and 1 on failure. This value is passed back to
+ * the unix shell, so we must follow shell return code conventions:
+ * the return code is an unsigned character, and 0 means success, and
+ * small positive integers mean failure.
{noformat}
I'd also be happy to implement multiple return codes as above. Then we'd have
three choices from which to pick. :-)
> key shell returns -1 to the shell on error, should be 1
> -------------------------------------------------------
>
> Key: HADOOP-10816
> URL: https://issues.apache.org/jira/browse/HADOOP-10816
> Project: Hadoop Common
> Issue Type: Bug
> Components: security
> Affects Versions: 3.0.0
> Reporter: Mike Yoder
> Assignee: Mike Yoder
> Fix For: 3.0.0
>
> Attachments: HADOOP-10816.001.patch, HADOOP-10816.002.patch
>
>
> I've seen this in several places now - commands returning -1 on failure to
> the shell. It's a bug. Someone confused their posix style returns (0 on
> success, < 0 on failure) with program returns, which are an unsigned
> character. Thus, a return of -1 actually becomes 255 to the shell.
> {noformat}
> $ hadoop key create happykey2 --provider kms://http@localhost:16000/kms
> --attr "a=a" --attr "a=b"
> Each attribute must correspond to only one value:
> atttribute "a" was repeated
> ...
> $ echo $?
> 255
> {noformat}
> A return value of 1 instead of -1 does the right thing.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
