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: Mike Wray <mike.wray@xxxxxxxxxx>
Subject: Re: [Xen-devel] xm create option parsing..
From: Steven Hand <Steven.Hand@xxxxxxxxxxxx>
Date: Fri, 30 Jul 2004 09:42:57 +0100
Cc: Steven Hand <Steven.Hand@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxxx, Steven.Hand@xxxxxxxxxxxx
Delivery-date: Fri, 30 Jul 2004 09:42:58 +0100
Envelope-to: Steven.Hand@xxxxxxxxxxxx
In-reply-to: Message from Mike Wray <mike.wray@xxxxxxxxxx> of "Fri, 30 Jul 2004 09:19:00 BST." <410A0474.3090303@xxxxxxxxxx>
>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.

Ok - we should probably note this somewhere, particularly as I guess
that many folks will be familiar with the gnu getopt style which 
doesn't assume that there are no more options once a non-option 
argument is seen.