Return-Path: Delivered-To: apmail-hadoop-core-user-archive@www.apache.org Received: (qmail 49658 invoked from network); 26 Feb 2009 14:19:33 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 26 Feb 2009 14:19:33 -0000 Received: (qmail 77890 invoked by uid 500); 26 Feb 2009 14:19:26 -0000 Delivered-To: apmail-hadoop-core-user-archive@hadoop.apache.org Received: (qmail 77855 invoked by uid 500); 26 Feb 2009 14:19:26 -0000 Mailing-List: contact core-user-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: core-user@hadoop.apache.org Delivered-To: mailing list core-user@hadoop.apache.org Received: (qmail 77844 invoked by uid 99); 26 Feb 2009 14:19:26 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 26 Feb 2009 06:19:26 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of greycat.na.kor@gmail.com designates 209.85.220.157 as permitted sender) Received: from [209.85.220.157] (HELO mail-fx0-f157.google.com) (209.85.220.157) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 26 Feb 2009 14:19:18 +0000 Received: by fxm1 with SMTP id 1so573605fxm.29 for ; Thu, 26 Feb 2009 06:18:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=JbvM6Pkq7inaZLCi7iJSt/WuYOJNtmzHSw70nM5vHkc=; b=DC6RXy8g31wYHfOsp9m4k3wct2jshg/BXsE4DZxlWVkC7c3l+8iq34/oOuWeywtjXH WxlIMNrM6KkLWguFQnSYmbK+aI6xNq5USJMwDzKT3m2VXEYRJ6PiA3ty1d2Wms0iyrT+ VvGhmtjG8roOAozpavTh2Mj2Afd+2SXjfNfzU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=RGwXYxhfMwM0r6HFQVr8eHxQY9L8Naspg0Ls/41AqFmrw6S2j5+R4wit8cKvgvYdYN DbE70FMnxF2V7coow263KCyK70W/pWSMP0IETkWL4QY4HhdR9j4NeY+bokj+Uvr2DZ5B voY8UyjCE/XwDlB3ZU+IGE5mSiaaS7Cv0MRh8= MIME-Version: 1.0 Received: by 10.103.24.11 with SMTP id b11mr692457muj.76.1235657935693; Thu, 26 Feb 2009 06:18:55 -0800 (PST) In-Reply-To: <4f10e2890902230502xafa5a41g9b706df3b17ad359@mail.gmail.com> References: <4f10e2890902230502xafa5a41g9b706df3b17ad359@mail.gmail.com> Date: Thu, 26 Feb 2009 17:18:55 +0300 Message-ID: <240e377b0902260618ndca8ae7re0fdaac3ece6d5ea@mail.gmail.com> Subject: Re: Can anyone verify Hadoop FS shell command return codes? From: Mikhail Yakshin To: core-user@hadoop.apache.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On Mon, Feb 23, 2009 at 4:02 PM, S D wrote: > I'm attempting to use Hadoop FS shell (http://hadoop > .apache.org/core/docs/current/hdfs_shell.html) within a ruby script. My > challenge is that I'm unable to get the function return value of the > commands I'm invoking. As an example, I try to run get as follows > > hadoop fs -get /user/hadoop/testFile.txt . > > From the command line this generally works but I need to be able to verify > that it is working during execution in my ruby script. The command should > return 0 on success and -1 on error. Based on > > http://pasadenarb.com/2007/03/ruby-shell-commands.html > > I am using backticks to make the hadoop call and get the return value. Here > is a dialogue within irb (Ruby's interactive shell) in which the command was > not successful: > > irb(main):001:0> `hadoop dfs -get testFile.txt .` > get: null > => "" > > and a dialogue within irb in which the command was successful > > irb(main):010:0> `hadoop dfs -get testFile.txt .` > => "" > > In both cases, neither a 0 nor a 1 appeared as a return value; indeed > nothing was returned. Can anyone who is using the FS command shell return > values within any scripting language (Ruby, PHP, Perl, ...) please confirm > that it is working as expected or send an example snippet? You seem to confuse captured output of stdout and exit status. Try analyzing $?.exitstatus in Ruby: irb(main):001:0> `true` => "" irb(main):002:0> $?.exitstatus => 0 irb(main):003:0> `false` => "" irb(main):004:0> $?.exitstatus => 1 -- WBR, Mikhail Yakshin