On Thu, Jul 01, 2010 at 11:42:12AM +0100, Richard W.M. Jones wrote:
> On Wed, Jun 23, 2010 at 09:58:34AM +0100, Daniel P. Berrange 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?
> > 
> > --details is still targetted at humans. If you want something more
> > easily parseable it should use a structured format like CSV. So I
> > don't think we should be overloading --details for this purpose.
> 
> CSV is a good format, but beware the many ways to shoot yourself in
> the foot.  I recommend using my program "csvtool" (in Fedora/Debian)
> which can fully and safely parse CSV output from shell scripts, or use
> a library (eg. Text::CSV for Perl, or csv for Python).  More about
> this subject here:
> 
>   http://libguestfs.org/virt-df.1.html#note_about_csv_format
> 
> Rich.

If we're going to go to all this trouble, how much more difficult
would it be to implement something like ps -o and give the user
control of the format?

Dave

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

Reply via email to