From: Robert Klemme on 20 Jun 2010 13:47 On 20.06.2010 12:47, R.. Kumar wrote: > Thomas Sawyer wrote: > >> OptionParser generally works fine --even for the items you mention. To >> handle subcommands just pop off the top of ARGV before parsing (or for >> more advanced use, find the first non-option item). > > I just found a great example of how you can use subcommands with > OptionParser. > > http://stackoverflow.com/questions/2732894/using-rubys-optionparser-to-parse-sub-commands I would modify that approach because it has the drawback of wasting CPU cycles creating all the unnecessary OptionParsers for subcommands that are not found in ARGV. Rather, I'd do something more lazy, e.g. global = OptionParser.new do |opts| # ... end subcommands = { 'foo' => lambda {|argv| OptionParser.new do |opts| # ... end.parse! argv}, # ... 'baz' => lambda {|argv| OptionParser.new do |opts| # ... end.parse! argv}, } global.order! subcommands[ARGV.shift][ARGV] Of course you can also make "subcommands" a method which figures what to return based on the argument (command name). Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/
From: R.. Kumar on 20 Jun 2010 14:25 Robert Klemme wrote: > > I would modify that approach because it has the drawback of wasting CPU > cycles creating all the unnecessary OptionParsers for subcommands that > are not found in ARGV. Rather, I'd do something more lazy, e.g. > > global = OptionParser.new do |opts| > # ... > end > > subcommands = { > 'foo' => lambda {|argv| OptionParser.new do |opts| > # ... > end.parse! argv}, > # ... > 'baz' => lambda {|argv| OptionParser.new do |opts| > # ... > end.parse! argv}, > } > > global.order! > subcommands[ARGV.shift][ARGV] > > Of course you can also make "subcommands" a method which figures what to > return based on the argument (command name). > > Kind regards > > robert I have actually isolated this into a seperate module with a method named "command" which creates the subcommand. It also takes care of : prog help command which trollop does not to my knowledge. It also prints out the subcommands with their descriptions when typing help or --help just as git does (which trollop does not.) http://gist.github.com/445992 I will look into your feedback about lazy creation and update the same. Could you have a quick look at the gist attached since my ruby is quite newbie level. -- Posted via http://www.ruby-forum.com/.
From: R.. Kumar on 21 Jun 2010 07:34 Robert Klemme wrote: >> >> Is there any way of doing this ? > > Well, either you revert back to creating all sub OptionParsers or you > store the description in some other place. > > Kind regards > > robert Actually i did find a way out !! Earlier in the loop, I was doing: desc = opt.description Now I do: opt.call.description cmdtext = "Commands are:" @commands.each_pair do |c, opt| desc = opt.call.description cmdtext << "\n #{c} : #{desc}" end Works. I modified my app to use this, it was easy since both use OptionParser. I added aliases. But my app has slightly more complex aliases where one command maps to multiple words. Working on that currently. -- Posted via http://www.ruby-forum.com/.
From: Gabriel Horner on 26 Jun 2010 21:07 I keep lists of related gems on delicious that could help. > * colorized output http://delicious.com/tag/gem:cs=color > * sensible option parsing http://delicious.com/tag/gem:type=opt > Does that sort of thing exist? I've noticed there are some apparently > more powerful alternatives like Thor, which is more of a full-stack > scripting framework, and I'm wondering what else might be useful to > take a look at. More libraries like thor at http://delicious.com/tag/gem:type=task I'd vote for thor over commander for most of what you need. Much more widely used and less verbose DSL. Gabriel -- Posted via http://www.ruby-forum.com/.
First
|
Prev
|
Pages: 1 2 3 Prev: 2010 FIFA World Cup Real Madrid Club football jersey Next: Do I overuse class methods? |