On Thu, Jul 01, 2010 at 11:38:06AM +0100, Richard W.M. Jones wrote:
> On Tue, Jun 22, 2010 at 12:35:32PM -0600, Eric Blake wrote:
> > On 06/22/2010 12:24 PM, Hugh O. Brock wrote:
> > >> Correct, we shouldn't change this behaviour - it'll break apps parsing
> > >> the output
> > > 
> > > FWIW Rich Jones complains that the output as it stands is nigh on
> > > unparseable anyway. Perhaps we should consider that a bug, and fix
> > > it...
> > 
> > The new --details option is our chance to change output - it outputs
> > whatever format we want, because it is a new flag; Rich, do you have any
> > preferences about what it _should_ output?
> > 
> > Here's what pool-list --details would currently do, if we applied
> > Justin's patch as-is (modulo no line wrapping added by my email client):
> 
> Sorry, been away for a couple of weeks.
> 
> > virsh # pool-list --details --all
> > Name       State     Autostart  Persistent  Capacity  Allocation  Available
> > ---------------------------------------------------------------------------
> > default    running   yes        yes          1.79 TB     1.49 TB  304.77 GB
> > image_dir  running   yes        yes          1.79 TB     1.49 TB  304.77 GB
> > tmp        inactive  no         yes                -           -          -
> 
> One good thing, and several bad things about that.  The good thing is
> that empty columns are presented with '-' which means you can use awk
> and sort -k to parse the output columnwise.
> 
> The bad things:
> 
> * Space within fields "1.79 TB" (awk / sort -k in fact _won't_ work).
> 
> * Numeric fields aren't numbers: You can't sort -n on "1.79 TB", and
>   you can't read that number into a script and do math on it.  Most
>   tools have a "-h" or "--human" option in order to generate human-
>   readable numbers (without spaces), but default to just printing the
>   raw numbers.
> 
> * Unnecessary "-------" line.
> 
> * Title line should be optional.  Have a --no-title option or
>   something like that to suppress it.
> 
> * Does virsh still print an unnecessary blank line after the output?
>   If so, stop doing that.

All of these bad things are just an artifact of trying to use the same
output format for humans & machines. To address all those would make
the result unpleasant for humans. We really do just need to create a
dedicated format for machines, csv or json, or somethingelse and leave
the human format alone

Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Reply via email to