linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Goffredo Baroncelli <kreijack@inwind.it>
To: Axel Burri <axel@tty0.ch>, David Sterba <dsterba@suse.cz>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: btrfs machine readable output [was Re: btrfs patches]
Date: Mon, 5 Oct 2015 22:09:44 +0200	[thread overview]
Message-ID: <5612D908.4000201@inwind.it> (raw)
In-Reply-To: <5612B30A.9030308@tty0.ch>

Hi Axel,

I add CC:linux-btrfs because I think that what you are saying is important and it was discussed in ML.

[we are talking about the Axel patches to "btrfs sub list" command]
On 2015-10-05 19:27, Axel Burri wrote:
> Hi Goffredo
> 
> Don't get me wrong, I don't want to blame you (or anyone), actually I'm
> only arguing what I think is best for btrfs. I started to write those
> patches because btrfs-scriptability is pretty bad (there is also "btrfs
> sub show" which has pretty un-parseable output"), and I think this is
> very important for the success of btrfs, and no-one seemed to address this.

In the past, when I developed the "btrfs fi usage/btrfs dev usage" I put a lot of effort to have an output easily machine readable: one data per line, key without space; I remember the battle to have in the key "_" instead of space :-)
However other people changed that to a more (human) readable output.

May be that I was wrong; I don't know. 

However for sure, if I look to other projects:
- systemd: it uses some btrfs capability, but it uses the ioctl directly.
- snapper: it uses ioctl directly

So I have to conclude that it is not common to use btrfs (as progs) directly.
Few times I noticed somebodies are working on a libbtrfs. May be this is a better approach.

> 
> I know that nowadays people expect to get shiny output from command-line
> tools, but IMHO it is much more important to have consistent
> machine-readable output before even thinking of human readability (since
> there are so many unix commands to translate it, e.g. "columns"). Now
> this is sadly not the case with btrfs-progs, and it's hard to change it
> when people are used to it. Note that when writing the patches I was
> also thinking of introducing some "--machine-readable" option, but this
> seemed so wrong to me...

I think that "--machine-readable" (or similar) is a better approach: the output of the btrfs command in the past is changed even drastically (give a look to my work on the mkfs.btrfs); but we could force us to have an output "backward compatible" and machine (programmer) friendly if a switch like "--machine-readable" is used.

[...]
> 
> Regards,
> 
> - Axel

BR
Goffredo


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5

      parent reply	other threads:[~2015-10-05 20:09 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-02 16:41 [PATCH 0/4] btrfs-progs: improve output of btrfs subvolume list command axel
2015-10-02 16:41 ` [PATCH 1/4] btrfs-progs: add -A option for subvolume list (print all available information) axel
2015-10-02 16:41 ` [PATCH 2/4] btrfs-progs: add "flags" column for subvolume list (shows "readonly" flag with -A) axel
2015-10-02 16:41 ` [PATCH 3/4] btrfs-progs: add option "--time-format=short|iso|unix|locale" to subvolume list axel
2015-10-02 16:41 ` [PATCH 4/4] btrfs-progs: change -t option for subvolume list to print a simple space-separated table (making it machine-readable) axel
2015-10-03  9:56   ` Goffredo Baroncelli
2015-10-03 10:06     ` Goffredo Baroncelli
2015-10-03 10:17     ` Axel Burri
     [not found]     ` <560FA944.3050606@digint.ch>
2015-10-03 17:41       ` Goffredo Baroncelli
2015-10-04  3:37         ` Duncan
2015-10-04 14:34           ` Goffredo Baroncelli
2015-10-05 15:08             ` Axel Burri
     [not found]             ` <56129171.4040200@digint.ch>
2015-10-05 15:42               ` Goffredo Baroncelli
2015-10-05 16:58                 ` Axel Burri
     [not found]                 ` <5612B30A.9030308@tty0.ch>
2015-10-05 20:09                   ` Goffredo Baroncelli [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=5612D908.4000201@inwind.it \
    --to=kreijack@inwind.it \
    --cc=axel@tty0.ch \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).