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

[Mike Wray <mike.wray@xxxxxxxxxx>]

Mike Wray wrote:

> Ian Pratt wrote:
>
> >  
> >
> > > 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.
> Just example option flags.
>
> > 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.
>
> We potentially have
>
> xm <xm options> subcommand <subcommand options/args>
>
> It doesn't really make sense to allow xm options after the subcommand.
>
> Each subcommand is responsible for parsing its own options, so
> we could get 'xm create' etc. to allow options after the args.
> I'll make the change.
Oops. The gnu-style getopt parsing is a Python 2.3 feature - not
available in 2.2. So we can't enable it at the moment.

Mike