hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "dhruba borthakur (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HADOOP-733) dfs shell has inconsistent exit codes
Date Fri, 17 Nov 2006 18:57:40 GMT
     [ http://issues.apache.org/jira/browse/HADOOP-733?page=all ]

dhruba borthakur updated HADOOP-733:
------------------------------------

    Status: Patch Available  (was: Open)

This patch contains a fix to return appropriate error codes while trying to delete or cat
a non-existent file. It also has a regression-test-case to test the return codes from DFSShell.
The test case currently has tests for 'cat' and 'rm' and I will be adding to it in the future.

> dfs shell has inconsistent exit codes
> -------------------------------------
>
>                 Key: HADOOP-733
>                 URL: http://issues.apache.org/jira/browse/HADOOP-733
>             Project: Hadoop
>          Issue Type: Bug
>          Components: dfs
>    Affects Versions: 0.8.0
>            Reporter: Christian Kunz
>         Assigned To: dhruba borthakur
>         Attachments: shellerrorcodes.patch
>
>
> After upgrading to 0.8.0, some of my script applications stopped to work properly, seemingly
because of hadoop dfs utility returning 0 exit code when it should not (kind of revival of
hadoop-488, with a different cause).
> dfs -cat  and dfs -rm always return exit code 0, even for non-existing files. The former
can be traced back to the fact that DFSShell's 'run' method calls a 'doall' method without
passing on the exit code ('doall' catches its own exceptions and returns an exit code). The
latter occurs because the return code of the DFSClient delete method is only used in DFS Shell
to print different messages without affecting exit code.
> There might be more inconsistent behavior of the dfs shell. Hadoop dfs command line should
return 0 signaling success exactly when the corresponding unix command returns 0 (or at least
it should be related to success whatever this means in a documented manner).
> I also would recommend to use a kind of regression test to prevent that this gets broken
again.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message