Jason Powers <[email protected]> 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 <[email protected]> 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 [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
