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