You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Martin Redington <m....@ucl.ac.uk> on 2002/11/15 00:18:14 UTC
[cli] Suggestions
I've just been writing my own Command Line Parsing library, when duh! I
looked to see what was out there, and came across commons-cli.
Its quite interesting to see the similarities between my implementation
and commons-cli
I have an "Options" type class as my main entry point, and posix
support (my library is built on top of the gnu-getopt package),
automatic generation of usage statements, command line parsing, and and
a similar usage pattern of create/parse/query.
Generally, the CLI implementation is neater and tidier.
However, my class has a number of features that CLI doesn't seem to
have (after a browse through the archives, I found that some of these
were anticipated by David below).
1. Options are typed (boolean, string, integer, double), with the type
being determined by the type of a default value that is passed in
during construction. This means that there are a *lot* of constructors,
as everything is heavily overloaded. From the user (developer)
perspective, if you pass the right kind of object in as a default, then
the library will do all the work (including checking the values
supplied on the command line). I saw what looked to be type support in
CLI, but it didn't seem very obvious how to use it.
3. Options can have a long name and no short name (flag). This is handy
for when you have a lot of parameters, and run out of suitable short
names.
3. Sets of options can be read from and written to properties files.
4. A set of default options is provided (disabled by default) that will
read properties files during parsing, and write them once parsing is
completed.
For example:
mycommand --properies-file in.properties --some-other-argument
some_value --write-properties-file out.properties
reads option values from in.properties, over-rides the value for
--some-other-argument, and dumps the properties out to out.properties.
The "special" property options names and flags can be fully customised
via method calls.
5. During interrogation, option values are retrieved via booleanValue,
stringValue, etc. calls. These are "type-safe", in that trying to
retrieve a boolean value from an integer option will throw a
runtime-exception, which will be thrown the first time that the program
is run
(assuming, reasonably that you go through a create/parse/query phase
early in program initialisation).
I am pretty sure that most of this functionality could be added to CLI
without breaking the existing interfaces, and may be useful for some
people (not requiring a flag for each option, simple typing, and the
properties file functionality has been very handy for me).
If anyone is interested in this, mail me directly for further info. I'd
be happy to write patches if people think its a good idea.
cheers,
Martin
> Date: Sat, 05 Jan 2002 20:05:40 -0500
> From: David Dixon-Peugh <dp...@mindspring.com>
> Subject: [cli] Suggestions
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
>
>
>
> I've been fooling with the CLI package in the
> Sandbox, and I've got a few suggestions on how
> it might be improved.
>
> #1 - Usage Statement
>
> Since we are setting up the Options class with
> all the option possibilites and their descriptions,
> it seems a logical place to generate a Usage
> statement.
>
> #2 - Default Values on Options
>
> It seems that the default values are known when
> the options are created. It makes sense to set
> the defaults when the Options object is created.
>
> #3 - Integrate with Properties Object
>
> It would be nice, if I could write something like
> this:
>
> public static void main(String args[]) {
> Options opt = new QuiltOptions("quilt.properties");
>
> try {
> Properties prop = opt.parse( args );
> } catch (MissingArgumentException e) {
> System.err.println( opt.getUsageStatement() );
> System.exit( -1 );
> }
> }
>
> What do you think? I think it makes the code look
> an awful lot cleaner than the way it works now.
>
> Thanks,
>
> DDP
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [cli] Suggestions
Posted by Martin Redington <m....@ucl.ac.uk>.
>
> CLI had this type of feature previously but it was decided that
> the Builder was a more flexible and easier to use solution.
> Now, if a new property is being added to Option all that is
> required is the accessor on Option and the property method
> on OptionBuilder.
>
> The most basic ctors and factory methods (see Option.addOption) are
> in place but to use any *advanced* features the Builder must be used.
> This also makes it easier for the user to understand rather than
> having to look up the Javadoc for each ctor. So I am -1 on
> reintroducing all of the ctors.
That's cool. One could always write a class that used method
overloading extensively, and then passed those requests through to
OptionBuilder if this was your preferred style.
>
> Yeah, thats a good idea. It would make sense for testing a
> command line. Can you give me an example of what one of these
> properties files would look like.
just like a standard properties file. Here's a snippet of one of mine:
# Saved CommandLineOptions properties
# Date: Fri Nov 15 01:11:11 GMT 2002
help=false
min-age=30
max-age=100
serialized-outputs-and-curves-filename=
read-outputs-and-curves-from-file=true
risk-free-return=0.03
risk-premium=0.05
risk-sigma=0.2
etc ...
In my class, properties are dumped out in the order that the options
were defined (rather than in the "random" order that you get from a
normal properties object).
keys are long names, where defined, or flags otherwise.
A useful enhancement might be to output the description of the option
as a comment above the actual value.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [cli] Suggestions
Posted by John Keyes <jb...@mac.com>.
<snip/>
> This is possible in CLI, e.g. OptionBuilder.withLongOpt( "username"
> > ).hasArg().create().
>
> It seems quite awkward (IMHO) to chain together all of those method
> calls. I got round this with method overloading.
>
> I have a *lot* of constructors/factory methods in my lib, but there is
> a simple set of rules that lets you determine what to write, so that
> constructors work in a very concise, DWIM (do what I mean) fashion.
CLI had this type of feature previously but it was decided that
the Builder was a more flexible and easier to use solution.
Now, if a new property is being added to Option all that is
required is the accessor on Option and the property method
on OptionBuilder.
The most basic ctors and factory methods (see Option.addOption) are
in place but to use any *advanced* features the Builder must be used.
This also makes it easier for the user to understand rather than
having to look up the Javadoc for each ctor. So I am -1 on
reintroducing all of the ctors.
<snip/>
> >> 3. Sets of options can be read from and written to properties files.
> >
> > No support for this. I have a TODO for myself (I must document it) to
> > have an XML reader and writer for configuring an Options instance. I
> > will document this TODO and also add yours. If you feel like having a
> > bash at the properties one that would be cool ;)
>
> Maybe early next week. I should be able to port mine across pretty
> easily.
Cool.
>> 4. A set of default options is provided (disabled by default) that
> >> will read properties files during parsing, and write them once
> >> parsing is completed.
> >>
> >> For example:
> >>
> >> mycommand --properies-file in.properties --some-other-argument
> >> some_value --write-properties-file out.properties
> >>
> >> reads option values from in.properties, over-rides the value for
> >> --some-other-argument, and dumps the properties out to >> out.properties.
> >>
> >> The "special" property options names and flags can be fully
> >> customised via method calls.
> >
> > Might be that I'm a bit sleepy but I don't see what this achieves.
> > Can you
> > enlighten me please.
>
> sure.
>
> imagine my code looks like
>
> options = myCreateOptions();
> options.setUsePropertiesOptions(true);
> options.parseCommandLine("mycommand", args);
> interrogateOptions(options);
>
> Calling setUsePropertiesOptions with a true argument means that in
> addition to the options that I defined, my commandline parsing will
> also support a predefined set of options relating to properties, which
> support reading option values in from a properties file, and writing
> options out to a properties file, and specifying a prefix to add
> to/subtract from property names.
>
> This can be very useful if you have a *lot* of command-line options. I
> have some simulation apps that run like this. Of course one could argue
> that if you have so many options, you should be using a properties file
> or some other mechanism anyway, but this approach lets you have the
> best of both worlds ... specification of options in a properties file,
> over-rideable from the command line.
>
> so, for example
>
> runApp --write-properties-file propertiesfile
>
> dumps out all of the options, and their default values into a
> properties file.
>
> I can now go in and edit this to set a particular set of properties
> that I want to run
>
> Now I can rerun the program using my edited properties file to
> configure the application:
>
> runApp --properties-file propertiesfile
>
> Now, if I want to use this properties file as a base, but to override
> some of the values, I can run
>
> runApp --properties-file propertiesfile --some-other-option newvalue
>
> Of course, you may not like those particular option names, so my class
> provides methods to let you set the name and flags that will be used
> for each of these options. Of course, the programmer could implement
> this themselves, on top of CLI, but this way they get it for free (if
> they choose to turn it on).
>
> Does that make more sense?
Yeah, thats a good idea. It would make sense for testing a
command line. Can you give me an example of what one of these
properties files would look like.
<snip/>
Thanks,
-John K
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [collections][SUBMIT] XMLProperties (a Properties-like class)
Posted by Stephen Colebourne <sc...@btopenworld.com>.
I have a class similar to this one too. It is part of a replecement of
resource bundle, and allows XML resource bundles. So there is definitely
evidence of common code.
However, this class is
- too specific for [collections]
- too XML for [collections]
- not a collection (Its not a List/Map)
You may want to have a look at the [resources] project in the sandbox via
CVS. I haven't looked in great detail, but it does seem to cover the same
ground. (Note to self, get [resources] sorted out at some point...)
Stephen
----- Original Message -----
From: "Henri Yandell" <ba...@generationjava.com>
> It's a good idea Jeff, and the xml.commons people may be interested,
> though they don't tend to view Commons in quite that way, but:
>
> import javax.xml.*;
> import javax.xml.parsers.*;
> import javax.xml.transform.*;
> import org.w3c.dom.*;
> import org.xml.sax.*;
> import org.apache.xpath.*;
>
> import org.w3c.dom.*;
> import org.xml.sax.*;
>
> is why I don't think it should go in Collections.
>
> My tuppence,
>
> Hen
>
> On Thu, 14 Nov 2002, Jeff Varszegi wrote:
>
> > An implementation of a Properties-like utility class that can store
> > and
> retrieve different data
> > types, can store comments for properties, and stores/loads data using
> > XML. If you think it is useful, feel free to use it.
> >
> > Jeff
> >
> >
> > __________________________________________________
> > Do you Yahoo!?
> > Yahoo! Web Hosting - Let the expert host your site
> > http://webhosting.yahoo.com
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [codec][SUBMIT] Common Interface, and Refined Soundex
Posted by Henri Yandell <ba...@generationjava.com>.
Committed.
Thanks Tim, the addition of an Encoder interface and the EncoderComparator
are very cool.
Hen
On Fri, 15 Nov 2002, O'brien, Tim wrote:
>
> Refined Soundex is similar to the Soundex algorithm, but it the number
> of consonant groups has been increased. This algorithm is helpful when
> search for alternative spellings, etc. More information on this
> algorithm can be found here: http://www.bluepoof.com/Soundex/info2.html
>
> Metaphone, Soundex, and RefinedSoundex all implement a common Encoder
> interface, this is handy if one is implementing a system which needs to
> treating the encoding algorithm as a "pluggable" component.
>
> EncoderComparator, is merely a generalization of the SoundexComparator
> for the Encoder interface.
>
> --------
> Tim O'Brien
> Transolutions, Inc.
> W 847-574-2143
> M 847-863-7045
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[codec][SUBMIT] Common Interface, and Refined Soundex
Posted by "O'brien, Tim" <to...@transolutions.net>.
Refined Soundex is similar to the Soundex algorithm, but it the number
of consonant groups has been increased. This algorithm is helpful when
search for alternative spellings, etc. More information on this
algorithm can be found here: http://www.bluepoof.com/Soundex/info2.html
Metaphone, Soundex, and RefinedSoundex all implement a common Encoder
interface, this is handy if one is implementing a system which needs to
treating the encoding algorithm as a "pluggable" component.
EncoderComparator, is merely a generalization of the SoundexComparator
for the Encoder interface.
--------
Tim O'Brien
Transolutions, Inc.
W 847-574-2143
M 847-863-7045
Re: [collections][SUBMIT] XMLProperties (a Properties-like class)
Posted by Henri Yandell <ba...@generationjava.com>.
It's a good idea Jeff, and the xml.commons people may be interested,
though they don't tend to view Commons in quite that way, but:
import javax.xml.*;
import javax.xml.parsers.*;
import javax.xml.transform.*;
import org.w3c.dom.*;
import org.xml.sax.*;
import org.apache.xpath.*;
import org.w3c.dom.*;
import org.xml.sax.*;
is why I don't think it should go in Collections.
My tuppence,
Hen
On Thu, 14 Nov 2002, Jeff Varszegi wrote:
> An implementation of a Properties-like utility class that can store
> and
retrieve different data
> types, can store comments for properties, and stores/loads data using
> XML. If you think it is useful, feel free to use it.
>
> Jeff
>
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Web Hosting - Let the expert host your site
> http://webhosting.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[collections][SUBMIT] XMLProperties (a Properties-like class)
Posted by Jeff Varszegi <jv...@yahoo.com>.
An implementation of a Properties-like utility class that can store and retrieve different data
types, can store comments for properties, and stores/loads data using XML. If you think it is
useful, feel free to use it.
Jeff
__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - Let the expert host your site
http://webhosting.yahoo.com
Re: [cli] Suggestions
Posted by Henri Yandell <ba...@generationjava.com>.
On Fri, 15 Nov 2002, Martin Redington wrote:
> Hi John,
>
> >> 5. During interrogation, option values are retrieved via
> >> booleanValue, stringValue, etc. calls. These are "type-safe", in that
> >> trying to retrieve a boolean value from an integer option will throw
> >> a runtime-exception, which will be thrown the first time that the
> >> program is run
> >> (assuming, reasonably that you go through a create/parse/query phase
> >> early in program initialisation).
> >
> > The TypeHandler class does provide support for this at the
> > interrogation
> > stage. Have a look at it and tell me if there is anything you think is
> > missing.
>
> I'll check it out ...
I was in the same position as yourself a while back. I had my own library
and wanted to dump it for CLI but CLI lacked this feature. I wanted to do:
flags = "a:bc%d/" which means d is a File, c a Number, c a boolean and
a a String.
PatternOptionsBuilder does this and uses TypeHandler to do its dumbie
conversions. BeanUtils has a converter package that realy should become
more highprofile and CLI would use this for its conversion.
I think :) It's been way down on my todo lists :(
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [cli] Suggestions
Posted by Martin Redington <m....@ucl.ac.uk>.
Hi John,
thanks for your reply,
> Check out this unit test which shows how to use typed options:
> http://cvs.apache.org/viewcvs.cgi/jakarta-commons/cli/src/test/org/
> apache/commons/cli/PatternOptionBuilderTest.java?rev=1.6&content-
> type=text/vnd.viewcvs-markup
>
>> 2. Options can have a long name and no short name (flag). This is
>> handy for when you have a lot of parameters, and run out of suitable
>> short names.
>
> This is possible in CLI, e.g. OptionBuilder.withLongOpt( "username"
> ).hasArg().create().
It seems quite awkward (IMHO) to chain together all of those method
calls. I got round this with method overloading.
I have a *lot* of constructors/factory methods in my lib, but there is
a simple set of rules that lets you determine what to write, so that
constructors work in a very concise, DWIM (do what I mean) fashion.
My base constructor is
/**
* @param name The long name for the option.
* @param flag The flag for the option.
* @param argument A constant value indicating whether an argument is
not allowed/optional/required
* @param defaultValue An object containing the default value
* @param type A constant value indicating the type (boolean, string,
int or double) of the object
* @param argName A string to use for the argument in usage messages
(e.g., filename).
* @param description A description of the option.
*/
Option(String name, char flag, int argument, Object defaultValue, int
type, String argName, String description);
The rules for other constructors.
An option must have a name and/or a flag.
argument is optional (for boolean options, there is no argument,
otherwise required argument is assumed)
defaultValue/type are replaced by a single boolean, String, int or
double value, which indicates the default value and the type of the
option.
argName and description are optional.
That generates a lot of constructors in the library (I think I could
make argName optional as well---right now you either have to have
argName and description as well, or neither---which would add a lot
more constructors).
However, the constructors are pretty unambiguous to the end-user, so
the library ends up being very easy to use. For example, see the code
below.
CommandLineOptions options = new CommandLineOptions();
try{
options.addCommandLineOption("url", 'u', DEFAULT_URL_STRING);
options.addCommandLineOption("method", 'm', "");
options.addCommandLineOption("secure", 's', false);
options.addCommandLineOption("help", 'h', false);
int lastArg = options.parseCommandLine("TestClient", args);
url = options.stringValue("url");
method = options.stringValue("method");
secure = options.booleanValue("secure");
if(options.booleanValue("help")) options.printUsage(System.out);
}
catch(CommandLineOptionException e){
e.printStackTrace();
}
I don't know whether any scheme like this could be added to CLI at this
point, but I think it makes things a lot more friendly for the end-user.
>> 3. Sets of options can be read from and written to properties files.
>
> No support for this. I have a TODO for myself (I must document it) to
> have an XML reader and writer for configuring an Options instance. I
> will document this TODO and also add yours. If you feel like having a
> bash at the properties one that would be cool ;)
Maybe early next week. I should be able to port mine across pretty
easily.
>> 4. A set of default options is provided (disabled by default) that
>> will read properties files during parsing, and write them once
>> parsing is completed.
>>
>> For example:
>>
>> mycommand --properies-file in.properties --some-other-argument
>> some_value --write-properties-file out.properties
>>
>> reads option values from in.properties, over-rides the value for
>> --some-other-argument, and dumps the properties out to >> out.properties.
>>
>> The "special" property options names and flags can be fully
>> customised via method calls.
>
> Might be that I'm a bit sleepy but I don't see what this achieves.
> Can you
> enlighten me please.
sure.
imagine my code looks like
options = myCreateOptions();
options.setUsePropertiesOptions(true);
options.parseCommandLine("mycommand", args);
interrogateOptions(options);
Calling setUsePropertiesOptions with a true argument means that in
addition to the options that I defined, my commandline parsing will
also support a predefined set of options relating to properties, which
support reading option values in from a properties file, and writing
options out to a properties file, and specifying a prefix to add
to/subtract from property names.
This can be very useful if you have a *lot* of command-line options. I
have some simulation apps that run like this. Of course one could argue
that if you have so many options, you should be using a properties file
or some other mechanism anyway, but this approach lets you have the
best of both worlds ... specification of options in a properties file,
over-rideable from the command line.
so, for example
runApp --write-properties-file propertiesfile
dumps out all of the options, and their default values into a
properties file.
I can now go in and edit this to set a particular set of properties
that I want to run
Now I can rerun the program using my edited properties file to
configure the application:
runApp --properties-file propertiesfile
Now, if I want to use this properties file as a base, but to override
some of the values, I can run
runApp --properties-file propertiesfile --some-other-option newvalue
Of course, you may not like those particular option names, so my class
provides methods to let you set the name and flags that will be used
for each of these options. Of course, the programmer could implement
this themselves, on top of CLI, but this way they get it for free (if
they choose to turn it on).
Does that make more sense?
>> 5. During interrogation, option values are retrieved via
>> booleanValue, stringValue, etc. calls. These are "type-safe", in that
>> trying to retrieve a boolean value from an integer option will throw
>> a runtime-exception, which will be thrown the first time that the
>> program is run
>> (assuming, reasonably that you go through a create/parse/query phase
>> early in program initialisation).
>
> The TypeHandler class does provide support for this at the
> interrogation
> stage. Have a look at it and tell me if there is anything you think is
> missing.
I'll check it out ...
>> I am pretty sure that most of this functionality could be added to
>> CLI without breaking the existing interfaces, and may be useful for
>> some people (not requiring a flag for each option, simple typing, and
>> the properties file functionality has been very handy for me).
>>
>> If anyone is interested in this, mail me directly for further info.
>> I'd be happy to write patches if people think its a good idea.
>
> I'm glad you found CLI Martin, saves creating another package ;) Let
> me know if you
> have any other queries/comments.
>
> BTW, this is the first time I have seen Davids mail as well.
I just had a very quick squint through the archives ... to see if
anyone had suggested this stuff before ...
cheers,
m.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [cli] Suggestions
Posted by John Keyes <jb...@mac.com>.
Excellent, thanks a million,
-John K
On Fri, 2002-11-15 at 14:51, Martin Redington wrote:
> On Friday, November 15, 2002, at 02:30 PM, John Keyes wrote:
>
> >
> > Now I get you ;) Again, an example properties file with a
> > relevant code snippet would be cool. You should enter this
> > in Bugzilla as a Software Enhancement request (so we can make
> > sure it doesn't get lost).
>
> will do ...
>
> This should be pretty simple, as should the over-riding, although the
> Parser interface will need to be enhanced (directly or in a subclass)
> to support the latter.
>
> The only real gotcha that I can see is that in order to support the
> "free" properties related command line options during parsing (as per
> my previous mail), you need to add a callback to the Parser interface,
> which is a slightly bigger change, although it should be possible
> without breaking anything.
>
> Anyway, I'll submit the enhancement request and some code snippets next
> week, and you can see what you think ...
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
John Keyes <jb...@mac.com>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [cli] Suggestions
Posted by John Keyes <jb...@mac.com>.
Hi Martin,
Just to let you know, I have the properties stuff implemented
(only support args with single values at the moment). I have
to do some tidy up before I commit it but you can hold off
with your work until this is in and you can comment on it then.
-John K
On Friday, Nov 15, 2002, at 14:51 Europe/Dublin, Martin Redington wrote:
>
> On Friday, November 15, 2002, at 02:30 PM, John Keyes wrote:
>
>>
>> Now I get you ;) Again, an example properties file with a
>> relevant code snippet would be cool. You should enter this
>> in Bugzilla as a Software Enhancement request (so we can make
>> sure it doesn't get lost).
>
> will do ...
>
> This should be pretty simple, as should the over-riding, although the
> Parser interface will need to be enhanced (directly or in a subclass)
> to support the latter.
>
> The only real gotcha that I can see is that in order to support the
> "free" properties related command line options during parsing (as per
> my previous mail), you need to add a callback to the Parser interface,
> which is a slightly bigger change, although it should be possible
> without breaking anything.
>
> Anyway, I'll submit the enhancement request and some code snippets
> next week, and you can see what you think ...
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
- - - - - - - - - - - - - - - - - - - - - - -
Jakarta Commons CLI
http://jakarta.apache.org/commons/cli
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [cli] Suggestions
Posted by Martin Redington <m....@ucl.ac.uk>.
On Friday, November 15, 2002, at 02:30 PM, John Keyes wrote:
>
> Now I get you ;) Again, an example properties file with a
> relevant code snippet would be cool. You should enter this
> in Bugzilla as a Software Enhancement request (so we can make
> sure it doesn't get lost).
will do ...
This should be pretty simple, as should the over-riding, although the
Parser interface will need to be enhanced (directly or in a subclass)
to support the latter.
The only real gotcha that I can see is that in order to support the
"free" properties related command line options during parsing (as per
my previous mail), you need to add a callback to the Parser interface,
which is a slightly bigger change, although it should be possible
without breaking anything.
Anyway, I'll submit the enhancement request and some code snippets next
week, and you can see what you think ...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [cli] Suggestions
Posted by John Keyes <jb...@mac.com>.
>> 3. Sets of options can be read from and written to properties files.
> >
> > No support for this. I have a TODO for myself (I must document it) to
> > have an XML reader and writer for configuring an Options instance. I
> > will document this TODO and also add yours. If you feel like having a
> > bash at the properties one that would be cool ;)
>
> rereading your comment, I see that for XML, you're talking about
> configuring an options instance.
>
> I didn't make myself very clear, but I was talking (as was David, I
> think) about taking an Options instance, and a Properties object, and
> producing a CommandLine object or equivalent, so it would be more like
> a Parser object, except that that interface wouldn't be quite suitable.
> The appropriate prototype would be more like:
>
> public CommandLine parse(Options opts, Properties properties, boolean
> stopAtNonOption)
>
> or maybe
>
> public CommandLine parse(Options opts, Properties properties)
>
> or even
>
> public CommandLine parse(Options opts, Properties properties, Prefix
> prefix)
>
> (where prefix is a prefix that gets stripped off the inbound
> properties, so that you can embed relevant properties in a general
> properties file without fear of naming collisions).
>
> If that sounds useful, let me know, and I'll have a bash at it ...
Now I get you ;) Again, an example properties file with a
relevant code snippet would be cool. You should enter this
in Bugzilla as a Software Enhancement request (so we can make
sure it doesn't get lost).
> Returning to my previous reply, it would also be useful (IMHO,
> naturally) to be able to take this CommandLine object, and over-ride
> its settings via an actual command line, but I can't see any way to do
> that gracefully in CLI ...
We'll see, I think it should be possible by having two CommandLines
, one configured by the Properties(A) and the other configured by
the parser(B). Then, add the options from the B can be added to A,
if any of the options in B already exists in A, then override the
value in A. That won't be too much work I don't think. You should
add something on this to the enhancement request also.
Thanks,
-John K
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [cli] Suggestions
Posted by Martin Redington <m....@ucl.ac.uk>.
Hi John,
On Thursday, November 14, 2002, at 11:47 PM, John Keyes wrote:
>
>> 3. Sets of options can be read from and written to properties files.
>
> No support for this. I have a TODO for myself (I must document it) to
> have an XML reader and writer for configuring an Options instance. I
> will document this TODO and also add yours. If you feel like having a
> bash at the properties one that would be cool ;)
rereading your comment, I see that for XML, you're talking about
configuring an options instance.
I didn't make myself very clear, but I was talking (as was David, I
think) about taking an Options instance, and a Properties object, and
producing a CommandLine object or equivalent, so it would be more like
a Parser object, except that that interface wouldn't be quite suitable.
The appropriate prototype would be more like:
public CommandLine parse(Options opts, Properties properties, boolean
stopAtNonOption)
or maybe
public CommandLine parse(Options opts, Properties properties)
or even
public CommandLine parse(Options opts, Properties properties, Prefix
prefix)
(where prefix is a prefix that gets stripped off the inbound
properties, so that you can embed relevant properties in a general
properties file without fear of naming collisions).
If that sounds useful, let me know, and I'll have a bash at it ...
Returning to my previous reply, it would also be useful (IMHO,
naturally) to be able to take this CommandLine object, and over-ride
its settings via an actual command line, but I can't see any way to do
that gracefully in CLI ...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [cli] Suggestions
Posted by John Keyes <jb...@mac.com>.
Hi Martin,
> I've just been writing my own Command Line Parsing library, when duh!
> I looked to see what was out there, and came across commons-cli.
>
> Its quite interesting to see the similarities between my
> implementation and commons-cli
>
> I have an "Options" type class as my main entry point, and posix
> support (my library is built on top of the gnu-getopt package),
> automatic generation of usage statements, command line parsing, and
> and a similar usage pattern of create/parse/query.
>
> Generally, the CLI implementation is neater and tidier.
>
> However, my class has a number of features that CLI doesn't seem to
> have (after a browse through the archives, I found that some of these
> were anticipated by David below).
>
> 1. Options are typed (boolean, string, integer, double), with the type
> being determined by the type of a default value that is passed in
> during construction. This means that there are a *lot* of
> constructors, as everything is heavily overloaded. From the user
> (developer) perspective, if you pass the right kind of object in as a
> default, then the library will do all the work (including checking the
> values supplied on the command line). I saw what looked to be type
> support in CLI, but it didn't seem very obvious how to use it.
Check out this unit test which shows how to use typed options:
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/cli/src/test/org/
apache/commons/cli/PatternOptionBuilderTest.java?rev=1.6&content-
type=text/vnd.viewcvs-markup
> 2. Options can have a long name and no short name (flag). This is
> handy for when you have a lot of parameters, and run out of suitable
> short names.
This is possible in CLI, e.g. OptionBuilder.withLongOpt( "username"
).hasArg().create().
> 3. Sets of options can be read from and written to properties files.
No support for this. I have a TODO for myself (I must document it) to
have an XML reader and writer for configuring an Options instance. I
will document this TODO and also add yours. If you feel like having a
bash at the properties one that would be cool ;)
> 4. A set of default options is provided (disabled by default) that
> will read properties files during parsing, and write them once parsing
> is completed.
>
> For example:
>
> mycommand --properies-file in.properties --some-other-argument
> some_value --write-properties-file out.properties
>
> reads option values from in.properties, over-rides the value for
> --some-other-argument, and dumps the properties out to out.properties.
>
> The "special" property options names and flags can be fully customised
> via method calls.
Might be that I'm a bit sleepy but I don't see what this achieves. Can
you
enlighten me please.
> 5. During interrogation, option values are retrieved via booleanValue,
> stringValue, etc. calls. These are "type-safe", in that trying to
> retrieve a boolean value from an integer option will throw a
> runtime-exception, which will be thrown the first time that the
> program is run
> (assuming, reasonably that you go through a create/parse/query phase
> early in program initialisation).
The TypeHandler class does provide support for this at the interrogation
stage. Have a look at it and tell me if there is anything you think is
missing.
> I am pretty sure that most of this functionality could be added to CLI
> without breaking the existing interfaces, and may be useful for some
> people (not requiring a flag for each option, simple typing, and the
> properties file functionality has been very handy for me).
>
> If anyone is interested in this, mail me directly for further info.
> I'd be happy to write patches if people think its a good idea.
I'm glad you found CLI Martin, saves creating another package ;) Let
me know if you
have any other queries/comments.
BTW, this is the first time I have seen Davids mail as well.
-John K
>
> cheers,
> Martin
>
>
>> Date: Sat, 05 Jan 2002 20:05:40 -0500
>> From: David Dixon-Peugh <dp...@mindspring.com>
>> Subject: [cli] Suggestions
>> Content-Type: text/plain; charset=us-ascii; format=flowed
>>
>>
>>
>>
>> I've been fooling with the CLI package in the
>> Sandbox, and I've got a few suggestions on how
>> it might be improved.
>>
>> #1 - Usage Statement
>>
>> Since we are setting up the Options class with
>> all the option possibilites and their descriptions,
>> it seems a logical place to generate a Usage
>> statement.
>>
>> #2 - Default Values on Options
>>
>> It seems that the default values are known when
>> the options are created. It makes sense to set
>> the defaults when the Options object is created.
>>
>> #3 - Integrate with Properties Object
>>
>> It would be nice, if I could write something like
>> this:
>>
>> public static void main(String args[]) {
>> Options opt = new QuiltOptions("quilt.properties");
>>
>> try {
>> Properties prop = opt.parse( args );
>> } catch (MissingArgumentException e) {
>> System.err.println( opt.getUsageStatement() );
>> System.exit( -1 );
>> }
>> }
>>
>> What do you think? I think it makes the code look
>> an awful lot cleaner than the way it works now.
>>
>> Thanks,
>>
>> DDP
>>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
- - - - - - - - - - - - - - - - - - - - - - -
Jakarta Commons CLI
http://jakarta.apache.org/commons/cli
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>