From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Wray Subject: Re: xm create option parsing.. Date: Fri, 30 Jul 2004 10:08:20 +0100 Sender: xen-devel-admin@lists.sourceforge.net Message-ID: <410A1004.2050801@hpl.hp.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Errors-To: xen-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Ian Pratt Cc: Steven Hand , xen-devel@lists.sourceforge.net List-Id: xen-devel@lists.xenproject.org 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 subcommand 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