[
https://issues.apache.org/jira/browse/HADOOP-10816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14061488#comment-14061488
]
Mike Yoder commented on HADOOP-10816:
-------------------------------------
{quote}
Do we want the tests to instead be doing assertEquals(1)
{quote}
Yeah, I was thinking about this... to be pedantic, the contract (as specified
only in comments) only says "small positive integer" and not "must be 1".
Therefore one could say the test is correct. If in the future we add another
return code, say "2", it would still mean failure, but a failure mode that
would differentiate itself from "1" - and the test code would still be correct,
although we'd want to add additional tests.
Or, we could change "small positive integer" to "1" in the comments, and
enforce the return of "1" on failure as you suggest.
Either way works and doesn't matter that much to me.
> 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
>
>
> 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)
