You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-dev@hadoop.apache.org by "dhruba borthakur (JIRA)" <ji...@apache.org> on 2006/11/17 19:57:38 UTC

[jira] Updated: (HADOOP-733) dfs shell has inconsistent exit codes

     [ http://issues.apache.org/jira/browse/HADOOP-733?page=all ]

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

    Attachment: shellerrorcodes.patch

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