[Libvir] Re: virsh outputs to stderr(?!) why not stdout

[Karel Zak]

On Thu, Apr 06, 2006 at 02:18:10PM +0100, Daniel P. Berrange wrote:
> On Thu, Apr 06, 2006 at 02:44:41PM +0200, Karel Zak wrote:
> > On Thu, Apr 06, 2006 at 08:40:17AM -0400, Daniel Veillard wrote:
> > > On Thu, Apr 06, 2006 at 02:37:37PM +0200, Karel Zak wrote:
> > > > On Thu, Apr 06, 2006 at 11:46:57AM +0200, Jim Meyering wrote:
> > > > > So, now I can use something like this to get a list of domain names:
> > > > > 
> > > > >   virsh list | tail -n +4 | awk '{print $2}'
> > > > > 
> > > > > Is there some easier way?
> > > > 
> > > >  I think we can add some options to the list command:
> > > > 
> > > >     --noheader
> > > >     --nodom0
> > > >     --cols=name,id,state,maxmem,usemem,....
> > > > 
> > > >  without these options it will use default (current) format. I've
> > > >  already thought about this solution for the others commands (e.g.
> > > >  dominfo). I think this is a way how make it useful in scripts.
> 
> This raises the question of what the primary intended use case of virsh 
> is / should be. Currently I see it as being an interactive administrator

 It's already possible use it as interactive tool ("virsh" without
 any option) and non-interactive (e.g "virsh list").

> Now, I don't disagree that there is a need for something that is easy to 
> script in the shell, but if we are going to make virsh easier to script
> we should be careful not to compromise the primary use case of interactive
> administrator control. Conversly we must be careful not be end up with the

 Agree. I think the example above with the list command doesn't discredit
 interactive mode.

> presentation focused output becoming a defacto API, because there is much
> pain & suffering that way - simple changes to improve user experiance would
> end up breaking scripting. Another example - gettext translations of the
> output fields could break scripts which are grokking for English strings.

 This is pretty common for all commands, the solution is use "LANG=C" in
 shell scripts. 

> So, I'd say, rather than add a whole range of extra command line options
> for tweaking the existing administrator presentation-focused output, we 
> should instead add a single '--batch' option. This would activate a completely 
> separate presentation mode tailored explicitly to the needs of scripts. It
> would have a formal structure for outputting data, perhaps a series of rows
> expressed as 'key:value' pairs, or a single line in CSV format, or some other
> easily shell-parsable format.

 Is there any example where any UNIX command use this way? (It doesn't
 mean that I disagree with you, but the virsh shouldn't be like from
 foreign planet:-).

 IMHO it will be better use --fieldsep=<foo> and --recordsep=<bar>
 global options rather than hardcode there CSV or key:value format.

> Finally, while I think it is useful to have the ability to script common
> tasks from the shell, we shouldn't worry about getting every single little
> detail covered. We already have two very simple scripting APIs for interacting
> with libvirt - Python & Perl which will be far more powerful for automation
> that shell+virsh+awk could ever be. 

 Agree.

    Karel

-- 
 Karel Zak  <kzak at redhat.com>