xm create option parsing..

xm create option parsing..

[Steven Hand]

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.


cheers,

S.



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click

Re: xm create option parsing..

[Tom Wilkie]

Yeah this happens as all option to set variables must come at the end 
of the command line, which all switch must come before them.

Its just the way the command line is parsed.

Tom

On 28 Jul 2004, at 17:37, 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.
>
>
> cheers,
>
> S.
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel
>



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click

Re: xm create option parsing..

[Ian Pratt]

> Yeah this happens as all option to set variables must come at the end 
> of the command line, which all switch must come before them.
> 
> Its just the way the command line is parsed.

I've never liked this. Can we fix it?

Ian


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click

Re: xm create option parsing..

[Tom Wilkie]

I'll take a look at it, someone will probably beat me to it (hint 
hint...)

Tom

On 28 Jul 2004, at 18:10, Ian Pratt wrote:

>> Yeah this happens as all option to set variables must come at the end
>> of the command line, which all switch must come before them.
>>
>> Its just the way the command line is parsed.
>
> I've never liked this. Can we fix it?
>
> Ian
>



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click

Re: xm create option parsing..

[Mike Wray]

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

doesn't.

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.

Mike


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: xm create option parsing..

[Steven Hand]

>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
>
>doesn't.
>
>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. 


cheers, 

S. 


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: xm create option parsing..

[Ian Pratt]

 
> 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


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: xm create option parsing..

[Mike Wray]

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.

Mike


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: xm create option parsing..

[Mike Wray]

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



-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: xm create option parsing..

[Ian Pratt]

> We potentially have
> 
> xm <xm options> subcommand <subcommand options/args>
> 
> It doesn't really make sense to allow xm options after the subcommand.

What <xm options> do we currently have? Having a -U to set the
host:port might be nice, but what others do we currently have?

> 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.

Users will thank you ;-)

Thanks,
Ian



-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: xm create option parsing..

[Ian Pratt]

> > 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.

That's a bind. I'm going to have to cave in and switch to 2.3 at
some point, but I'd like to hold out for a while longer.

'create' is the only sub command that really suffers from this,
so could we just temporally hack the parsing to call getopt again
on the arguments[1:] and append to the list? Not pretty, but...

Ian


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: xm create option parsing..

[Mike Wray]

Ian Pratt wrote:

>>>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.
> 
> 
> That's a bind. I'm going to have to cave in and switch to 2.3 at
> some point, but I'd like to hold out for a while longer.
> 
> 'create' is the only sub command that really suffers from this,
> so could we just temporally hack the parsing to call getopt again
> on the arguments[1:] and append to the list? Not pretty, but...
> 

It's worse than that - because getopt bails on the first non-option
we have to keep on calling it iteratively. Might as well write
your own getopt :-). The way out is to go with 2.3 and use gnu_getopt
or do some backport hack for the code for 2.3 to 2.2.
In the meantime just document that the format is
command [options] [args]

Mike


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com