Hi,
Optparse is a quite powerful tool, but there are some issues:
- It seems not to allow the ‘-d directory’ style of option values.
This is really bad. In the unix world this is almost standard.
Also the Posix recommandation says explicitly that both '-d directroy’
and ‘-ddirectory’ should be accepted.
- If you use the recommended form:
ARGV.options do |opts|
…
opts.parse!
end
then optparse stops command line processing, but continues with
the script. This is also quite wrong. It should not catch the exception
(I can do that myself if I want to). Default beheviour for erroneous
options should be exception. The programmer can put a Usage in the
rescue.
Cheers,
Han Holl
I tend to use the getoptlong library. It seems to address your issues.
Here’s an example …
require ‘getoptlong’
opts = GetoptLong.new (
[‘–directory’, ‘-d’, GetoptLong::REQUIRED_ARGUMENT],
[‘–file’, ‘-f’, GetoptLong::OPTIONAL_ARGUMENT]
)
opts.each do |opt, value|
puts “#{opt}: #{value}”
end
Running this produces …
traken$ ruby opts.rb -ddir -d dir -ffile -f file
–directory: dir
–directory: dir
–file: file
–file: file
···
On Mon, 2003-01-20 at 09:34, Han Holl wrote:
Optparse is a quite powerful tool, but there are some issues:
“Beware of bugs in the above code; I have only proved it correct,
not tried it.” – Donald Knuth (in a memo to Peter van Emde Boas)
Hi,
Optparse is a quite powerful tool, but there are some issues:
Thank you.
- It seems not to allow the ‘-d directory’ style of option values.
This is really bad. In the unix world this is almost standard.
Also the Posix recommandation says explicitly that both ‘-d directroy’
and ‘-ddirectory’ should be accepted.
Well, I might misunderstand you?
$ ruby -roptparse -e ‘ARGV.options{|opt|opt.def_option(“-dDIR”){|d|@dir=d};opt.parse!};p self’ – -dhere
#<Object:0x401938e4 @dir=“here”>
$ ruby -roptparse -e ‘ARGV.options{|opt|opt.def_option(“-dDIR”){|d|@dir=d};opt.parse!};p self’ – -d here
#<Object:0x401938e4 @dir=“here”>
- If you use the recommended form:
ARGV.options do |opts|
…
opts.parse!
end
then optparse stops command line processing, but continues with
the script. This is also quite wrong. It should not catch the exception
(I can do that myself if I want to). Default beheviour for erroneous
options should be exception. The programmer can put a Usage in the
rescue.
parse! outside ARGV.options block.
$ ruby -roptparse -e ‘ARGV.options{|opt|opt.def_option(“-dDIR”){|d|@dir=d}; opt}.parse!;p self’ – -d there
#<Object:0x401938e4 @dir=“there”>
$ ruby -roptparse -e ‘ARGV.options{|opt|opt.def_option(“-dDIR”){|d|@dir=d}; opt}.parse!;p self’ – -x
/usr/lib/ruby/1.8/optparse.rb:1118:in order!': invalid option: -x (OptionParser::InvalidOption) from /usr/lib/ruby/1.8/optparse.rb:1082:in catch’
from /usr/lib/ruby/1.8/optparse.rb:1082:in order!' from /usr/lib/ruby/1.8/optparse.rb:1161:in permute!’
from /usr/lib/ruby/1.8/optparse.rb:1187:in `parse!’
from -e:1
···
At Mon, 20 Jan 2003 23:34:00 +0900, Han Holl wrote:
–
Nobu Nakada
nobu.nokada@softhome.net writes:
- It seems not to allow the ‘-d directory’ style of option values.
This is really bad. In the unix world this is almost standard.
Also the Posix recommandation says explicitly that both ‘-d directroy’
and ‘-ddirectory’ should be accepted.
Well, I might misunderstand you?
$ ruby -roptparse -e ‘ARGV.options{|opt|opt.def_option(“-dDIR”){|d|@dir=d};opt.parse!};p self’ – -dhere
#<Object:0x401938e4 @dir=“here”>
$ ruby -roptparse -e ‘ARGV.options{|opt|opt.def_option(“-dDIR”){|d|@dir=d};opt.parse!};p self’ – -d here
#<Object:0x401938e4 @dir=“here”>
I do see this behavior:
ruby-cvs -roptparse -e ‘ARGV.options{|opt|opt.on(“–dir=[DIR]”){|d|@dir=d};opt.parse!};p self’ – --dir here
#<Object:0x401b89fc @dir=nil>
Optional arguments are not “greedy” but I would expect them to be.
Still, I like optparse much better than getoptlong – once I learned
how to use it.
Hi,
$ ruby -roptparse -e ‘ARGV.options{|opt|opt.def_option(“-dDIR”){|d|@dir=d};opt.parse!};p self’ – -d here
#<Object:0x401938e4 @dir=“here”>
Ok, it’s a version issue. I’m running 1.6.8, and downloaded
optparse=0.10.1 from RAA, because I though that would be the latest
version. I got:
./opttest.rb -i library -n
#<Object:0x200a3670 @exec=false, @inplace=“”>
ARGV = library
Later I discovered that the version include with the 1.6-1.8 shim
is actually newer! That version is alright.
- If you use the recommended form:
ARGV.options do |opts|
…
opts.parse!
end
then optparse stops command line processing, but continues with
the script. This is also quite wrong. It should not catch the exception
(I can do that myself if I want to). Default beheviour for erroneous
options should be exception. The programmer can put a Usage in the
rescue.
parse! outside ARGV.options block.
Yes, that helps. My problem was that I followed the example opttest.rb
from optparse-0.10.1. I ended up doing
ARGV.options do |opts| … end || exit
which also worked fine.
The default should be to stop processing, however.
Anyway, optparse is quite nice, once you’ve discovered how to use it.
Cheers,
Han Holl
···
nobu.nokada@softhome.net wrote:
Jim Weirich wrote:
Optparse is a quite powerful tool, but there are some issues:
I tend to use the getoptlong library. It seems to address your issues.
Yes, but optparse has a couple of capabilities that are really
worthwhile, like checking argument types and automatic
Usage: programname …summary
creation.
Quite powerful, but not easy to use because the English documentation
isn’t all that it maybe one day will be.
Cheers,
Han Holl
···
On Mon, 2003-01-20 at 09:34, Han Holl wrote:
Hi,
As I said earlier, I like optparse, but two features are a bit
nonstandard, at least in the Unix world.
Here’s optparse behaviour:
./opttest.rb --require kkk
#<Object:0x40232ce0 @exec=true, @library=“kkk”, @quit=nil>
./opttest.rb -r=kkk
#<Object:0x40232ce0 @exec=true, @library="=kkk", @quit=nil>
Unix conventions are: -f value or
–long-options=value
I think both forms above should be syntax errors.
(but of course it’s not really important).
Cheers
Han Holl
Hi,
Here’s optparse behaviour:
./opttest.rb --require kkk
#<Object:0x40232ce0 @exec=true, @library=“kkk”, @quit=nil>
./opttest.rb -r=kkk
#<Object:0x40232ce0 @exec=true, @library=“=kkk”, @quit=nil>
Unix conventions are: -f value or
–long-options=value
I think both forms above should be syntax errors.
(but of course it’s not really important).
They are allowed by GNU tools whose design I’d followed, and
also autoconf at least.
Ex.
$ date --ref version.h
Mon Jan 20 18:23:18 JST 2003
$ date -rversion.h
Mon Jan 20 18:23:18 JST 2003
$ touch =x
$ date -r=x
Wed Jan 22 07:20:35 JST 2003
···
At Wed, 22 Jan 2003 04:54:22 +0900, Han Holl wrote:
–
Nobu Nakada
nobu.nokada@softhome.net writes:
Hi,
ruby-cvs -roptparse -e ‘ARGV.options{|opt|opt.on(“–dir=[DIR]”){|d|@dir=d};opt.parse!};p self’ – --dir here
#<Object:0x401b89fc @dir=nil>
Optional arguments are not “greedy” but I would expect them to be.
It sounds non-optional. If it were “greedy”, how do you omit
the option value?
I see your point, but I have one idea.
The next element in ARGV is taken to be an optional argument if it
does not begin with a - character.
2 options:
--dir --foo
1 option:
--dir /tmp
1 option (only if optional value begins with - is the = required):
--dir=-somewhere
I think most humans would find this understandable. 
···
At Tue, 21 Jan 2003 04:27:47 +0900, > Matt Armstrong wrote:
nobu.nokada@softhome.net wrote in message
They are allowed by GNU tools whose design I’d followed, and
also autoconf at least.
Ex.
$ date --ref version.h
Mon Jan 20 18:23:18 JST 2003
$ date -rversion.h
Mon Jan 20 18:23:18 JST 2003
$ touch =x
$ date -r=x
Wed Jan 22 07:20:35 JST 2003
I stand corrected. You’re absolutely right.
Han Holl
In article 87hec3nnu2.fsf@squeaker.lickey.com,
Matt Armstrong matt@lickey.com writes:
The next element in ARGV is taken to be an optional argument if it
does not begin with a - character.
If non-option argument which is not begin with a - character is
followed by such option, – is required?
···
–
Tanaka Akira
Tanaka Akira akr@m17n.org writes:
In article 87hec3nnu2.fsf@squeaker.lickey.com,
Matt Armstrong matt@lickey.com writes:
The next element in ARGV is taken to be an optional argument if it
does not begin with a - character.
If non-option argument which is not begin with a - character is
followed by such option, – is required?
Yes. E.g. if --foo takes an optional argument, but you do not want to
pass one, then you have to do:
--foo -- bar
Maybe that is bad. I can’t think of too many commands that have
options with optional arguments, so it is hard for me to tell if that
would be inconvenient or not.
Since use of optional arguments is rare (true?) maybe the current
behavior is okay.