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.
Discussion
To leave a new comment, enter your email address. A copy of the article will be sent to you via email.
Did you mean to say something? Your email was blank.
Hi, yes I did write an email, guess Firefox ‘ate’ it, so I’m using Safari for this…. I don’t remember exactly what I wrote, but I’ll do my best to remember. First issue I had after running that “gem install trollop” (or something like) line in a Dos prompt shell on Vista is that entering ‘ri Trollop’ returns ‘Nothing known about Trollop’… Even though the gem install program did not report any problems… So I’m glad the docs are available online. 2nd issue: the line " require ‘trollop’ " in a Ruby script resulted in an error, don’t remember which now (this was solved by manually copying trollop.rb to c:\Ruby\lib\1.8 (or something close to that) ) 3rd issue: could you make a correct example on how to call the parse method by hand? I tried the following:require ‘trollop’ parser = Trollop::Parser opts = parser.parse(ARGV) do opt :monkey, “Use monkey mode” # a flag —monkey, defaulting to false opt :goat, “Use goat mode”, :default => true # a flag —goat, defaulting to true opt :num_limbs, “Number of limbs”, :default => 4 # an integer —num-limbs <i>, defaulting to 4 opt :num_thumbs, “Number of thumbs”, :type => :int # an integer —num-thumbs <i>, defaulting to nilend p opts # returns a hash: { :monkey => false, :goat => true, :num_limbs => 4, :num_thumbs => nil } but Ruby (most recent 1.8.6 RC2 1 click installer version) then says: ‘undefined method ’parse’ for Trollop::Parser::Class’ and I’m not seeing the mistake I’m making… 4th and last: is there a way to get Trollop to simply return the options it doesn’t recognize? I certainly don’t want an exception to be raised for that,since I’ve been taught that exceptions should only be used for ‘exceptional circumstances’, and typo’s don’t seem that exceptional for me (this issue is a bit moot for me now, since I began to roll my own after neither getlongopts, nor optparse nor Trollop seemed to fit my bill close enough,but might be handy for others who also want their option parser to stay out of the way…)
First issue I had after running that “gem install trollop” (or something like) line in a Dos prompt shell on Vista is that entering ‘ri Trollop’ returns ‘Nothing known about Trollop’… Even though the gem install program did not report any problems… So I’m glad the docs are available online. 2nd issue: the line " require ‘trollop’ " in a Ruby script resulted in an error, don’t remember which now (this was solved by manually copying trollop.rb to c:\Ruby\lib\1.8 (or something close to that) )
These two sound like gem installation issues.
3rd issue: could you make a correct example on how to call the parse method by hand? I tried the following:
but Ruby (most recent 1.8.6 RC2 1 click installer version) then says: ‘undefined method ’parse’ for Trollop::Parser::Class’ and I’m not seeing the mistake I’m making…You need something like:
4th and last: is there a way to get Trollop to simply return the options it doesn’t recognize? I certainly don’t want an exception to be raised for that,since I’ve been taught that exceptions should only be used for ‘exceptional circumstances’, and typo’s don’t seem that exceptional for me
No. You could do something with
stop_on_unknown, maybe, but it would be ugly. Exceptions are the right approach here.