From: Robert Klemme on
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
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
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
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/.