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 :|