What I basically need is a parser that behaves like ls and java (without the -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 On Wed, Sep 29, 2010 at 2:09 AM, Emmanuel Bourg <[email protected]> wrote: > Le 29/09/2010 02:16, Jason Powers a écrit : > > > 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 will > introduce a new unified parser, maybe it could be enhanced to support your > use case. > > Emmanuel Bourg > >
