All of lore.kernel.org
 help / color / mirror / Atom feed
From: TARUISI Hiroaki <taruishi.hiroak@jp.fujitsu.com>
To: kreijack@gmail.com
Cc: linux-btrfs@vger.kernel.org, zhipeng.gong@intel.com,
	chris.mason@oracle.com
Subject: Re: btrfsctl exit with 1 when succeed
Date: Mon, 28 Dec 2009 08:39:31 +0900	[thread overview]
Message-ID: <4B37F033.30700@jp.fujitsu.com> (raw)
In-Reply-To: <200912251025.57158.kreijack@libero.it>

Thank you, I don't think of a devices scan.

After all, I wonder why. Return codes must be
coherent so that we can know good from no-good
by them. In this spec, it's very hard to make
shell scripts with btrfsctl. If there isn't good
reason, we need to fix it, I think.

(2009/12/25 18:25), Goffredo Baroncelli wrote:
> On Friday 25 December 2009, TARUISI Hiroaki wrote:
>> I also want to know why this conversion is needed.
>> This might be a typo, I think.
>>
>> Could someone tell us why?
>> Can we fix this conversion? Or shouldn't we fix it
>> considering back-compatibility?
>>
> 
> It is even worse: the result code returned by btrfsctl is not coherent.
> btrfsctl returns always 1 except:
> - after a devices scan (in this case the result is _always_ 0)
> - if the ioctl returns a value greater than 0 
> 
> In other all cases (error in the command line, the device btrfs-control 
> doesn't exists, error in opening a file) the return code is 1.
> 
> That doesn't permit to differentiate an error from a good return. 
> 
> BR
> Goffredo
> 
> 
>> Regards,
>> taruisi
>>
>> (2009/11/11 15:16), Gong, Zhipeng wrote:
>>> We'd like to use btrfsctl in a shell script, however, btrfsctl exit with 1 
> even if the operation is successful, which is opposite to the usual shell 
> command convention.
>>> Why btrfsctl add this conversion in the end?
>>>          if (ret)
>>>                   exit(0);
>>>          else
>>>                   exit(1);
>>>
>>> Thanks
>>> Zhipeng
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 
> 


-- 
taruisi


      reply	other threads:[~2009-12-27 23:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-11  6:16 btrfsctl exit with 1 when succeed Gong, Zhipeng
2009-12-25  0:19 ` TARUISI Hiroaki
2009-12-25  9:25   ` Goffredo Baroncelli
2009-12-27 23:39     ` TARUISI Hiroaki [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B37F033.30700@jp.fujitsu.com \
    --to=taruishi.hiroak@jp.fujitsu.com \
    --cc=chris.mason@oracle.com \
    --cc=kreijack@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=zhipeng.gong@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.