Trollop 1.15 released
I’ve just released Trollop 1.15, which fixes an irritating misfeature pointed out by Rafael Sevilla: when Trollop runs out of characters when it’s generating short option names, e.g. when you have a lot of options, it shouldn’t throw an exception and die. It should just continue peacefully.
Trollop’s reign of domination continues!
Trollop 1.13 released
I’ve released Trollop 1.13. This is a minor bugfix release. Arguments
given with =’s and with spaces in the values are now parsed correctly.
(E.g. --name="your mom".)
Get it with a quick gem install trollop.
Trollop 1.11 released
Trollop 1.11 has been released. This is a minor release with only one new feature: when an option <opt> is actually given on the commandline, a new key <opt>_given is inserted into the return hash (in addition to <opt> being set to the actual argument(s) specified).
This allows you to detect which options were actually specified on the commandline. This is necessary for situations where you want one option to override or somehow influence other options. For example, configure’s --exec-prefix and --bindir flags: if --exec-prefix is specified, you want to override the default value for --bindir, unless that’s also given. If neither are given, you want to use the default values.
This should be a backwards-compatible release, except for namespace issues, if you actually had options called <something>-given.
Trollop 1.10 released
I released a new version of Trollop with a couple minor but cool updates.
The best part is the new :io argument type, which uses open-uri to handle
filenames and URIs on the commandline. So you can do something like this:
require 'trollop'
opts = Trollop::options do
opt :source, "Source file (or URI) to print",
:type => :io,
:required => true
end
opts[:source].each { |l| puts "> #{l.chomp}" }
Also, when trying to detect the terminal size, Trollop now tries to `stty
size` before loading curses. This gives better results when running under
screen (for some reason curses clears the terminal when initializing under
screen).
I’ve also cleaned up the documentation quite a bit, expanding the examples on the main page, fixing up the RDoc comments, and generating the RDoc documentation with a modern RDoc, so that things like constants actually get documented.
If you’re still using OptParse, you should really give Trollop a try. I guarantee you’ll write much fewer lines of argument parsing code, and you’ll get all sorts of nifty features like help page terminal size detection.
Trollop news
Looks like there was a Ruby Inside article featuring Trollop a few weeks ago. Partially as a result of this, I have at least two other people contributing patches. For a project that’s been around for a few years and basically had no one but me use it, that’s a nice change of pace.
I’ve also moved it over from SVN to git (hosted on Gitorious), which probably will help some.
Trollop 1.8.1 released
Trollop 1.8.1 is out. This is a minor bugfix release, but 1.8, released a few weeks ago but not really advertised, adds new functionality, so I’m describing that here.
The new functionality is subcommand support, as seen in things like git and
svn. This feature is actually trivial to use / implement: you give Trollop a
list of stopwords. When it sees one, it stops parsing. The end. That’s all you
need.
Here’s how you use it:
- Call
Trollop::optionswith your global option specs. Pass it the list of subcommands as the stopwords. It will parseARGVand stop on the subcommand. - Parse the next word in ARGV as the subcommand, however you wish.
ARGV.shiftis the traditional choice. - Call
Trollop::optionsagain with whatever command-specific options you want.
And that’s it. Simple eh?
It continually amazes me how hard other people make option parsing. I think it’s a holdover from their days of using C or Java. Take a look at synopsis for optparse — it’s a ridiculous amount of work for something simple. Or better yet, look at the synopsis for CmdParse. Having to make a class for each command is a clunky Java-ism. I’m sorry, but it’s true. Subclassing is the one option for specializing code in Java; in Ruby we can be far more sophisticated. Take a look at Ditz’s operator.rb for an example of a subcommand DSL.