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@xxxxxxxxxx>