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, <[email protected]> wrote: > 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] > >
