Hi all,
personally I favour Ryan's suggestion of setting flags (and/or
system properties) separately to obtain non-RFC compliant behaviour (or
to specify which RFC to follow, where they conflict), or to specify
that exceptions should be raised when encountering a non-Base64 char,
rather
In my own CLI-like library, I've occasionally found it useful to be
able to hack the command line slightly, before passing it to the
interrogation phase.
For example, where a parameter two's default value depends on parameter
one's value, but I don't want to over-write the user's input if
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
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
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.6content-
type=text/vnd.viewcvs-markup
2. Options can have a long name
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
