Forum: Ruby OptionParser: unexpected behaviour with -help

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Stephan W. (Guest)
on 2009-05-24 08:58
I ran into some unexpected behaviour with the Ruby OptionParser class.
When running this script (without any command line arguments) the output
is as in the last, commented, line.

--------------------------------------

require 'optparse'
options = {}
OptionParser.new do |opt|
 opt.on "--ex EXECUTABLE", String do |val|
    options[:ex] = val
  end
 opt.on "--headers" do |val|
    options[:headers] = val
  end
 opt.parse(%w( -help ))
end

puts options.inspect

# Output is {:ex=>"lp", :headers=>true}

--------------------------------------


I don't think that '-help' should be treated the same as '-h -ex lp' or
'-h --ex lp'. In particular, '-help' may be a misspelling of the
common  '--help' option. Am I doing something wrong? Is there a way to
avoid this?

Thanks a lot,

Stephan
Brian C. (Guest)
on 2009-05-24 13:21
Look at the source - /usr/lib/ruby/1.8/optparse.rb or somewhere similar
on your system.

                # if no short options match, try completion with long
                # options.
                sw, = complete(:long, opt)

So it looks that if you stub out 'complete' you can get the behaviour
you require: that is, I think you want -h to be treated as an error
instead of as a shortcut for --headers, and ditto -e as an error instead
of a shortcut for --ex

Alternatively, if only '-help' is a problem, you could just handle this
special case:

ARGV.each { |a| a.replace('--help') if a == '-help' }
Robert K. (Guest)
on 2009-05-24 19:50
(Received via mailing list)
On 24.05.2009 06:58, Stephan W. wrote:
>     options[:ex] = val
>   end
>  opt.on "--headers" do |val|
>     options[:headers] = val
>   end
>  opt.parse(%w( -help ))

In addition to what Brian wrote, the line above is wrongly placed IMHO.
  You cannot know whether initialization of the OptionParser instance is
completed when still inside the block.  You should rather invoke #parse
on the result of OptionParser.new.

> end
>
> puts options.inspect

Kind regards

  robert
Stephan W. (Guest)
on 2009-05-25 10:42
Brian C. wrote:
> Look at the source - /usr/lib/ruby/1.8/optparse.rb or somewhere similar
> on your system.
>
>                 # if no short options match, try completion with long
>                 # options.
>                 sw, = complete(:long, opt)
>
> So it looks that if you stub out 'complete' you can get the behaviour
> you require: that is, I think you want -h to be treated as an error
> instead of as a shortcut for --headers, and ditto -e as an error instead
> of a shortcut for --ex
>
> Alternatively, if only '-help' is a problem, you could just handle this
> special case:
>
> ARGV.each { |a| a.replace('--help') if a == '-help' }

Well, thanks a lot for that. I feel the guessing game should be avoided
-- there's too much potential for confusion.

Stephan
Stephan W. (Guest)
on 2009-05-25 10:42
Robert K. wrote:
> On 24.05.2009 06:58, Stephan W. wrote:
>>     options[:ex] = val
>>   end
>>  opt.on "--headers" do |val|
>>     options[:headers] = val
>>   end
>>  opt.parse(%w( -help ))
>
> In addition to what Brian wrote, the line above is wrongly placed IMHO.
>   You cannot know whether initialization of the OptionParser instance is
> completed when still inside the block.  You should rather invoke #parse
> on the result of OptionParser.new.
>
>> end
>>
>> puts options.inspect

Good point -- but the result is the same.

Stephan

> Kind regards
>
>   robert
Eric H. (Guest)
on 2009-05-27 00:52
(Received via mailing list)
On May 23, 2009, at 21:58, Stephan W. wrote:

> I don't think that '-help' should be treated the same as '-h -ex lp'
> or
> '-h --ex lp'. In particular, '-help' may be a misspelling of the
> common  '--help' option. Am I doing something wrong? Is there a way to
> avoid this?

When you use - instead of -- you invoke short-option-parsing like:

$ ruby -dvrubygems -e 'raise rescue nil'
ruby 1.8.6 (2008-08-11 patchlevel 287) [universal-darwin9.0]
Exception `LoadError' at /Library/Ruby/Site/1.8/rubygems.rb:1106 - no
such file to load -- rubygems/defaults/operating_system
Exception `LoadError' at /Library/Ruby/Site/1.8/rubygems/
config_file.rb:35 - no such file to load -- Win32API
Exception `RuntimeError' at -e:1 -
$

Which is equivalent to:

ruby -d -v -r ubygems -e 'raise rescue nil'
Stephan W. (Guest)
on 2009-05-28 20:38
Eric H. wrote:
> On May 23, 2009, at 21:58, Stephan W. wrote:
>
>> I don't think that '-help' should be treated the same as '-h -ex lp'
>> or
>> '-h --ex lp'. In particular, '-help' may be a misspelling of the
>> common  '--help' option. Am I doing something wrong? Is there a way to
>> avoid this?
>
> When you use - instead of -- you invoke short-option-parsing like:
>
> $ ruby -dvrubygems -e 'raise rescue nil'
> ruby 1.8.6 (2008-08-11 patchlevel 287) [universal-darwin9.0]
> Exception `LoadError' at /Library/Ruby/Site/1.8/rubygems.rb:1106 - no
> such file to load -- rubygems/defaults/operating_system
> Exception `LoadError' at /Library/Ruby/Site/1.8/rubygems/
> config_file.rb:35 - no such file to load -- Win32API
> Exception `RuntimeError' at -e:1 -
> $
>
> Which is equivalent to:
>
> ruby -d -v -r ubygems -e 'raise rescue nil'

There is some precedence for disabling this kind of command line
parsing, see

  http://jargs.sourceforge.net/doc/api/jargs/gnu/Cmd...

  http://tinyurl.com/notflagexception

Quote:

  public static class CmdLineParser.NotFlagException
  extends CmdLineParser.UnknownOptionException

  Thrown when the parsed commandline contains multiple concatenated
short options, such as -abcd, where one or more requires a value.
getMessage() returns an english human-readable error string.

End quote

This looks like a useful option to support.

Stephan
This topic is locked and can not be replied to.