On Thu, Jul 01, 2010 at 08:57:25AM -0400, Hugh O. Brock wrote:
On Thu, Jul 01, 2010 at 11:50:20AM +0100, Daniel P. Berrange wrote:
> 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
Actually I think we *do* need the --details convenience method for
human-readable output, *and* a better machine-parseable format. Justin
is mostly interested in making virsh more usable for people, which I
fully support -- making it easier to script is also a bonus however.
Err, that's entirely my point
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 :|