commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [cli] Why is the Constructor to CommandLine package protected?
Date Wed, 29 Sep 2010 16:28:10 GMT
Jason Powers <> writes:
>Content-Type: text/plain; charset=ISO-8859-1
>Content-Transfer-Encoding: quoted-printable
>What I basically need is a parser that behaves like ls and java (without th=
>-D part) for long options.
>For example, if I have a short option of 'a' and a long option of 'add'. I'=
>accept '-a' and '--add', but I would reject '-add'. The new DefaultParser
>looks like it does a very good job of trying to figure out what the user
>meant and doing it, but I need something that's a little less forgiving.
>If you guys like I can code up what I'm thinking and send a patch along
>against 1.3.

A related feature I would like is support for abbreviations, of -- options.
Submitting an ambiguous  abbreviation would generate a parser error. Many,
of the GNU utilities, including ls, have this feature.

>On Wed, Sep 29, 2010 at 2:09 AM, Emmanuel Bourg <> wrote:
>> Le 29/09/2010 02:16, Jason Powers a =E9crit :
>>  Is there a reason that this is protected that I'm just not seeing?
>> I suppose it was made private to make clear that instances of CommandLine
>> are obtained through a parser and not created directly. It hinders the
>> development of alternative parsers though.
>> I'll change the accessibility of the constructor and the addArg/addOption
>> methods to protected so you can easily extend the class.
>> What kind of strict behavior did you expect from the parsers? CLI 1.3 wil=
>> introduce a new unified parser, maybe it could be enhanced to support you=
>> use case.
>> Emmanuel Bourg

    Norman Shapiro
    798 Barron Avenue
    Palo Alto CA 94306-3109
    (650) 565-8215

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message