hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Yoder (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-10816) key shell returns -1 to the shell on error, should be 1
Date Tue, 15 Jul 2014 16:59:05 GMT

    [ 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)

Mime
View raw message