Re: [te-code-users] Re: Parsing nested command line options...

[Andrew S. T. <ato...@ei...>]

Kat,

Just looking at this further last night, I found out what is happening. 
The only solution I can offer right now without breaking the way the
library works is to say you must associate your option and it's argument
with '=', e.g. 

abcTool -launchedToolOpts="-optionA <arg1> -optionB -optionC <arg2>"

The reason the library behaves this way is so that it can detect
problems like:

abcTool -launchedToolOpts -optionX -optionY foo

where no argument has been specified to launchedToolOpts.  Admittedly,
the check for this case is a bit crude and includes a "FIXME: this could
be better" comment, but if you use the '=' you can do what you need
today.

I'm open to suggestions on how to implement the check so that it does
what I need and what you want (assuming you would prefer to not have to
specify the '=' between the option and value).

Please let me know if this is acceptable to you.

Cheers,

ast

On Mon, 2005-06-20 at 10:44, Andrew S. Townley wrote:
> Kat,
> 
> Sorry I missed this.  Please see earlier post as to the explanation. 
> Still, it's no excuse for not replying for 4 months... :(
> 
> The answer is that this appears to be a bug.  By the time the options
> get to the parser, they appear to lose any string grouping you may have
> specified on the command line due to them starting with '-'.
> 
> I won't have a chance to look at this further today, but I'll get back
> to you in the next couple of days.
> 
> Again, apologies for the tardy response.
> 
> ast
> 
> > Hi,
> >  
> >  We have  a requirement wherein a set of options corresponding to a
> particular 
> >  tool (which is launched from within our tool) have to be passed in
> (as an 
> >  argument to an option) to our command line tool. For example:
> >  
> >  Let"s assume that the command line tool is called "abcTool". There"s
> an option 
> >  for abcTool called "-lanchedToolOpts". 
> >  
> >  abcTool -launchedToolOpts "-optionA <arg1> -optionB -optionC <arg2>"
> -optionX 
> >  <value> -optionY
> >  
> >  abcTool also needs to process other options like -optionX, -optionY
> as 
> >  settings for itself. The expectation here is that the argument to 
> >  launchedToolOpts should be stored AS IS and passed onto to
> launchedTool, 
> >  verbatim.
> >  
> >  Any suggestions on how this could be achieved using TE-Common Java
> libraries?
> >  
> >  Thanks
> >  -Kat.
-- 
Andrew S. Townley <ato...@ei...>
http://atownley.blogspot.com