In this case it will not be ambiguous as long as foo is not "true" or
"false".
I remember discussing similiar example with Byron for remote commands.
Since command syntax are now defined in server side, it's difficult for
the client to know if the option is a boolean and determining if the
following parameter is an option-value or an operand.
Do you think we should deprecate/remove support for non-boolean option
value?
Bill pointed out a good usage syntax for cvs - thank you! Now I can see
how it can apply to asadmin.
Kedar Mhaswade wrote:
> But I am a bit confused about your previous point. I don't get how
> asadmin --optionname foo bar will be confused to mean:
> - either optionname is a boolean option, or
> - optionname is an option with value foo.
>
> This is because the options that asadmin supports are fixed in their
> type and permissible values. Thus, right upfront, we know whether or not
> --optionname is a valid *asadmin program* option. Depending on that
> a particular invocation can be flagged a parsing error.
>
> Am I missing something basic here?
>
> -Kedar
>
> Jane Young wrote:
>
>> Actually, CLIP does not allow option-value to be optional (see
>> guideline #5).
>> However, back in iPlanet days there was another CLIP that we followed
>> and they support optional option arguments for boolean options (i.e.
>> --no-<boolean-option-name> is always false and
>> --<boolean-option-name> is true). To be compatible with previous
>> Application Server releases (7.0 to be exact), optional arguments for
>> boolean is supported in asadmin.
>>
>> Bill Shannon wrote:
>>
>>> Jane Young wrote:
>>>
>>>> Hi Kedar et al,
>>>>
>>>>
>>>> >In v3, can I say "asadmin --target foo list"? That is, can all the
>>>> >common arguments that really apply to asadmin itself rather than the
>>>> >subcommands be specified *before* the subcommand?
>>>>
>>>> This is *not* CLIP compliant. Please see:
>>>> http://www.opensolaris.org/os/community/arc/caselog/1999/645/spec-html/
>>>>
>>>
>>>
>>>
>>> Stupid CLIP. :-(
>>>
>>>> Also, there is ambiguity if options are specified *before* the
>>>> subcommand.
>>>> Consider the example:
>>>>
>>>> "asadmin --option-name foo bar" What if --option-name is a boolean
>>>> option. So is foo treated as an option value to option-name or is
>>>> it treated as a subcommand? Note that boolean option does not
>>>> require a option value.
>>>
>>>
>>>
>>> Having options with optional values is ambiguous. It doesn't matter if
>>> the options come before or after the subcommand. Does CLIP really
>>> allow that?
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>