WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Mike Wray <mike.wray@xxxxxxxxxx>
Subject: Re: [Xen-devel] xm create option parsing..
From: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>
Date: Fri, 30 Jul 2004 09:49:45 +0100
Cc: Steven Hand <Steven.Hand@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxxx, Ian.Pratt@xxxxxxxxxxxx
Delivery-date: Fri, 30 Jul 2004 09:49:46 +0100
Envelope-to: Steven.Hand@xxxxxxxxxxxx
In-reply-to: Your message of "Fri, 30 Jul 2004 09:19:00 BST." <410A0474.3090303@xxxxxxxxxx>
 
> It's an artifact of getopt - it stops parsing options at
> the first non-option. So
> 
> 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.

I think the current behaviour is sufficiently unintuitive that we
need to fix it: after finding the sub command, we should scan the
whole of the rest of the command line for args.

What does -x and --x do ?  I couldn't find them in the help
message.

I think the best policy is to ensure that arg flags never clash
between 'xm' and it's sub commands (I don't believe we currently
have any clashes), and to look for them in any position.

Ian