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
|
