You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Torsten Curdt <tc...@apache.org> on 2005/04/07 13:53:39 UTC
[CLI2] getting values
> The proposed release is available at:
> http://people.apache.org/~roxspring/cli/
Rob,
I've been playing with the CLI2 stuff now.
Great stuff! ...but something I found confusing
Let's say I create my option like this:
final Set set = new HashSet();
set.add("a1");
set.add("a2");
set.add("a3");
final Option oOption1 =
oBuilder
.withDescription(Messages.getString("Main.cli.option." +
CommandlineOption.ALGORITHM))
.withRequired(true)
.withArgument(
aBuilder
.withMinimum(1)
.withMaximum(1)
.withValidator(new EnumValidator(set))
.create())
.withLongName(CommandlineOption.ALGORITHM)
.create();
And then later want to get the value from it:
final String v =
(String) cmd.getValue("--" + CommandlineOption.ALGORITHM);
I find adding "--" quite inconvenient. Why here this prefix?
Also I am wondering what you think about adding some
getValuesAsXXX functions. Alway having an explicit cast
is kind of annoying.
Or am I missing something?
cheers
--
Torsten
Re: [CLI2] quoting
Posted by Torsten Curdt <tc...@apache.org>.
> The problem here is that "-c" looks like an option. The simplest ways
Yes, and reason why is because the shell
that executes the vm will remove the "
So what I would get is
command --option1 "-c -P" --option2
[--option1]
[-c -P]
[--option2]
Now we *could* say that since there are
obviously two options in one string of
the array it must have been surrounded
by a " ...which means it was not meant
to be option but an argument.
Not sure if that's always valid. But on
the first glance this makes sense to me.
WDYT?
> around it are to use the -- "consume remaining" to capture the things
> that look like short options:
> command --options1 -- -c -P --option2
> But you do run the risk of -c, -P and -option2 being consumed as
> arguments to --option1.
That doesn't work for me.
I cannot really easily change the
way commandline is looking like.
(needs to be compatible to a legacy app)
> Alternatively you could set up your
> DefaultOptionBuilder with something other than "-" for the short option
> prefix - if you're not using short options at all then reusing "--"
> should skirt around the issue pretty well.
Hm... that's an idea :)
cheers
--
Torsten
Re: [CLI2] quoting
Posted by Rob Oxspring <ro...@imapmail.org>.
Torsten Curdt wrote:
> Torsten Curdt wrote:
>
>>>The proposed release is available at:
>>>http://people.apache.org/~roxspring/cli/
>
>
> ...another thing:
>
> command --option1 "-c -P" --option2
>
> currently CLI1 and CLI2 is treating this
> as if it were
>
> command --option1 -c -P --option2
>
> which is not what I want. For me "-c -P" is
> a string which is the argument of option1.
>
> Bug or desired behaviour?
The problem here is that "-c" looks like an option. The simplest ways
around it are to use the -- "consume remaining" to capture the things
that look like short options:
command --options1 -- -c -P --option2
But you do run the risk of -c, -P and -option2 being consumed as
arguments to --option1. Alternatively you could set up your
DefaultOptionBuilder with something other than "-" for the short option
prefix - if you're not using short options at all then reusing "--"
should skirt around the issue pretty well.
Hope that helps,
Rob
>
> cheers
> --
> Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[CLI2] quoting
Posted by Torsten Curdt <tc...@apache.org>.
Torsten Curdt wrote:
>>The proposed release is available at:
>>http://people.apache.org/~roxspring/cli/
...another thing:
command --option1 "-c -P" --option2
currently CLI1 and CLI2 is treating this
as if it were
command --option1 -c -P --option2
which is not what I want. For me "-c -P" is
a string which is the argument of option1.
Bug or desired behaviour?
cheers
--
Torsten
Re: [CLI2] getting values
Posted by Rob Oxspring <ro...@imapmail.org>.
Torsten Curdt wrote:
>>The proposed release is available at:
>>http://people.apache.org/~roxspring/cli/
>
>
> Rob,
>
> I've been playing with the CLI2 stuff now.
> Great stuff! ...but something I found confusing
>
> Let's say I create my option like this:
>
> final Set set = new HashSet();
> set.add("a1");
> set.add("a2");
> set.add("a3");
>
> final Option oOption1 =
> oBuilder
> .withDescription(Messages.getString("Main.cli.option." +
> CommandlineOption.ALGORITHM))
> .withRequired(true)
> .withArgument(
> aBuilder
> .withMinimum(1)
> .withMaximum(1)
> .withValidator(new EnumValidator(set))
> .create())
> .withLongName(CommandlineOption.ALGORITHM)
> .create();
>
> And then later want to get the value from it:
>
> final String v =
> (String) cmd.getValue("--" + CommandlineOption.ALGORITHM);
>
>
> I find adding "--" quite inconvenient. Why here this prefix?
The prefix is needed here because the getValue() method takes any string
as might be entered by the user. I understand that it can be a bit
confusing but I tend to see people using hard coded strings in their
application where asking for the values of "--algorithm" is quite
intuitive. Alternatively I tend to set up an Option instance as a constant:
Option ALGORITHM = ...
and later:
final String v = (String) cmd.getValue(ALGORITHM)
>
> Also I am wondering what you think about adding some
> getValuesAsXXX functions. Alway having an explicit cast
> is kind of annoying.
>
> Or am I missing something?
There was a plan a while back of adding a TypedCommandLine that would
wrap a CommandLine instance and provide such methods. I didn't get
around to it since there wasn't much demand.
Could be added pretty easily but I think we should push for a 2.0 now
and make the new methods available in a 2.1 so that the api can settle.
THoughts?
Rob
>
> cheers
> --
> Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org