commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Powers <jpow...@gmail.com>
Subject Re: [cli] Why is the Constructor to CommandLine package protected?
Date Wed, 29 Sep 2010 20:47:21 GMT
That last ones doesn't seem too bad, though I don't think that the option
class supports a substring match right? It would be doable with the current
options setup though it might look a little clunky.

Is there anything else that 'defines' a GNU style command line that should
be included? My requirements are basically 'make it behave like all of the
other utilities' which are a mix of shell scripts , java, and mysql.

I'm not really sure this should be mixed in with the goal of the default
parser. I really like the way that is looking and working to 'just try and
figure out what the user was getting at'.

On Wed, Sep 29, 2010 at 9:28 AM, <norm@dad.org> wrote:

> Jason Powers <jpower2@gmail.com> writes:
> >--001636498aa30587d70491682379
> >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=
> >e
> >-D part) for long options.
> >
> >For example, if I have a short option of 'a' and a long option of 'add'.
> I'=
> >d
> >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.
> >
> >Thanks
> >Jason
>
> 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 <ebourg@apache.org>
> 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=
> >l
> >> introduce a new unified parser, maybe it could be enhanced to support
> you=
> >r
> >> use case.
> >>
> >> Emmanuel Bourg
> >>
> >>
> >
> >--001636498aa30587d70491682379--
>
>    Norman Shapiro
>    798 Barron Avenue
>    Palo Alto CA 94306-3109
>    (650) 565-8215
>    norm@dad.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message