On Thu, Jul 01, 2010 at 02:01:57PM +0100, Daniel P. Berrange wrote: > 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 > Oh, excellent! :) --Hugh > -- > libvir-list mailing list > libvir-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list