This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] xm create option parsing..

To: Steven Hand <Steven.Hand@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] xm create option parsing..
From: Mike Wray <mike.wray@xxxxxxxxxx>
Date: Fri, 30 Jul 2004 09:19:00 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 30 Jul 2004 09:19:42 +0100
Envelope-to: Steven.Hand@xxxxxxxxxxxx
In-reply-to: <E1BprRD-0008Hh-00@xxxxxxxxxxxxxxxxx>
References: <E1BprRD-0008Hh-00@xxxxxxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421
Steven Hand wrote:

As far as I can see, "xm create -c vmid=1" will create a domain and
attach to its console while "xm create vmid=1 -c" won't. Any reason for this? The option parsing routines xm/opts.py and xm/create.py seems substantial enough.

It's an artifact of getopt - it stops parsing options at
the first non-option. So

xm create -c vmid=1

sets the -c option, whereas

xm create vmid=1 -c


It think there's a getopt flag to process options anywhere
in the args, but this is a problem for a multicommand like xm
that has its own options as well as subcommand options.

Basically options (-x, --x) have to precede args.