Here are the logs of the failure:

Optimist::ParserTest#test_date_formatting = 0.00 s = E


Error:
Optimist::ParserTest#test_date_formatting:
Optimist::CommandlineError: option 'arg' needs a date
    /home/utkarsh/debian/updates/ruby-team/optimist/ruby-optimist/lib/optimist.rb:842:in `rescue in block (2 levels) in parse'
    /home/utkarsh/debian/updates/ruby-team/optimist/ruby-optimist/lib/optimist.rb:833:in `block (2 levels) in parse'
    /home/utkarsh/debian/updates/ruby-team/optimist/ruby-optimist/lib/optimist.rb:831:in `map'
    /home/utkarsh/debian/updates/ruby-team/optimist/ruby-optimist/lib/optimist.rb:831:in `block in parse'
    /home/utkarsh/debian/updates/ruby-team/optimist/ruby-optimist/lib/optimist.rb:830:in `map'
    /home/utkarsh/debian/updates/ruby-team/optimist/ruby-optimist/lib/optimist.rb:830:in `parse'
    /home/utkarsh/debian/updates/ruby-team/optimist/ruby-optimist/lib/optimist.rb:327:in `block in parse'
    /home/utkarsh/debian/updates/ruby-team/optimist/ruby-optimist/lib/optimist.rb:316:in `each'
    /home/utkarsh/debian/updates/ruby-team/optimist/ruby-optimist/lib/optimist.rb:316:in `parse'
    /home/utkarsh/debian/updates/ruby-team/optimist/ruby-optimist/test/optimist/parser_test.rb:512:in `test_date_formatting'
    /usr/lib/ruby/vendor_ruby/minitest/test.rb:98:in `block (3 levels) in run'
    /usr/lib/ruby/vendor_ruby/minitest/test.rb:195:in `capture_exceptions'
    /usr/lib/ruby/vendor_ruby/minitest/test.rb:95:in `block (2 levels) in run'
    /usr/lib/ruby/vendor_ruby/minitest.rb:270:in `time_it'
    /usr/lib/ruby/vendor_ruby/minitest/test.rb:94:in `block in run'
    /usr/lib/ruby/vendor_ruby/minitest.rb:365:in `on_signal'
    /usr/lib/ruby/vendor_ruby/minitest/test.rb:211:in `with_info_handler'
    /usr/lib/ruby/vendor_ruby/minitest/test.rb:93:in `run'
    /usr/lib/ruby/vendor_ruby/minitest.rb:1029:in `run_one_method'
    /usr/lib/ruby/vendor_ruby/minitest.rb:339:in `run_one_method'
    /usr/lib/ruby/vendor_ruby/minitest.rb:326:in `block (2 levels) in run'
    /usr/lib/ruby/vendor_ruby/minitest.rb:325:in `each'
    /usr/lib/ruby/vendor_ruby/minitest.rb:325:in `block in run'
    /usr/lib/ruby/vendor_ruby/minitest.rb:365:in `on_signal'
    /usr/lib/ruby/vendor_ruby/minitest.rb:352:in `with_info_handler'
    /usr/lib/ruby/vendor_ruby/minitest.rb:324:in `run'
    /usr/lib/ruby/vendor_ruby/minitest.rb:164:in `block in __run'
    /usr/lib/ruby/vendor_ruby/minitest.rb:164:in `map'
    /usr/lib/ruby/vendor_ruby/minitest.rb:164:in `__run'
    /usr/lib/ruby/vendor_ruby/minitest.rb:141:in `run'
    /usr/lib/ruby/vendor_ruby/minitest.rb:68:in `block in autorun'


bin/rails test home/utkarsh/debian/updates/ruby-team/optimist/ruby-optimist/test/optimist/parser_test.rb:508

I inherited another project that requires trollop. I am willing to move to optimist,
but I would love to have some guidelines as to what to do in order to move. The
code base is foreign to me, including the style - very alien, so I'd like to have
some document that can help me in the process of porting things.

For instance:

opts = Trollop.with_standard_exception_handling(trollop_parser) {
trollop_parser.parse(i)

Can such method names be just used as a 1:1 replacement? If not what else
can be used? Could some document be added (can be short and concise,
just a tiny helper tool) and then linked to it from the main README perhaps?

Example option block :

opts = Trollop::options do
  version 0.1

  usage "foo|bar"
  synopsis "Reticulate splines"

  banner "Recognized options: "
  opt :dry_run, "Don't do anything", short: "-n"
end

Output when passed --help is :

Recognized options: 
  -n, --dry-run    Don't do anything
  -v, --version    Print version and exit
  -h, --help       Show this message

If I comment just the banner line, I get this :

Usage: test foo|bar
Reticulate splines

0.1
Options:
  -n, --dry-run    Don't do anything
  -v, --version    Print version and exit
  -h, --help       Show this message

Additionally, I get warnings (the shebang line is #!/usr/bin/env ruby -W) depending on whether the usage or synopsis lines are comment out :

$gem-path/trollop-2.1.2/lib/trollop.rb:480: warning: instance variable @usage not initialized
$gem-path/trollop-2.1.2/lib/trollop.rb:481: warning: instance variable @synopsis not initialized

When passing in a Date argument, there is now code on line 435 that says require 'chronic'. Since trollop by design doesn't have dependencies, this is supposed to not cause an issue if the code using trollop doesn't have the chronic gem loaded. It used to be that there was no require there and this worked fine, because the NameError that would be triggered by the next line (time = Chronic.parse(param)) was rescued and everything would continue to work.

Sample setup:

• Make a directory test_trollop_date
• Make a Gemfile containing:

source 'https://rubygems.org'

gem 'trollop', '2.1.1'

• Write a script test_trollop_date.rb with contents:

require 'trollop'

opts = Trollop::options do
  opt :date, 'Date', :type => :date, :required => true
end

• Run bundle install
• Run bundle exec ruby ./test_trollop_date.rb -d 2011-02-01

You'll get the following error:

/Users/carsten.dreesbach/.rvm/gems/ruby-1.9.3-p550/gems/trollop-2.1.1/lib/trollop.rb:435:in `require': cannot load such file -- chronic (LoadError)
        from /Users/carsten.dreesbach/.rvm/gems/ruby-1.9.3-p550/gems/trollop-2.1.1/lib/trollop.rb:435:in `parse_date_parameter'
        from /Users/carsten.dreesbach/.rvm/gems/ruby-1.9.3-p550/gems/trollop-2.1.1/lib/trollop.rb:401:in `block (3 levels) in parse'
        from /Users/carsten.dreesbach/.rvm/gems/ruby-1.9.3-p550/gems/trollop-2.1.1/lib/trollop.rb:401:in `map'
        from /Users/carsten.dreesbach/.rvm/gems/ruby-1.9.3-p550/gems/trollop-2.1.1/lib/trollop.rb:401:in `block (2 levels) in parse'
        from /Users/carsten.dreesbach/.rvm/gems/ruby-1.9.3-p550/gems/trollop-2.1.1/lib/trollop.rb:401:in `map'
        from /Users/carsten.dreesbach/.rvm/gems/ruby-1.9.3-p550/gems/trollop-2.1.1/lib/trollop.rb:401:in `block in parse'
        from /Users/carsten.dreesbach/.rvm/gems/ruby-1.9.3-p550/gems/trollop-2.1.1/lib/trollop.rb:378:in `each'
        from /Users/carsten.dreesbach/.rvm/gems/ruby-1.9.3-p550/gems/trollop-2.1.1/lib/trollop.rb:378:in `parse'
        from /Users/carsten.dreesbach/.rvm/gems/ruby-1.9.3-p550/gems/trollop-2.1.1/lib/trollop.rb:742:in `block in options'
        from /Users/carsten.dreesbach/.rvm/gems/ruby-1.9.3-p550/gems/trollop-2.1.1/lib/trollop.rb:772:in `with_standard_exception_handling'
        from /Users/carsten.dreesbach/.rvm/gems/ruby-1.9.3-p550/gems/trollop-2.1.1/lib/trollop.rb:742:in `options'
        from ./test_trollop_date.rb:3:in `<main>'

The line require 'chronic' should therefore be removed, or you should also catch the LoadError.

Looking at trollop 2.1.1, README.md claims the license of this code is "Ruby", while the trollop.gemspec claims that it is "MIT". Both places should list the same set of licenses available to avoid confusion.

Hi.

I want to implement help for sub-commands, e.g.

mycommand subcommand --help

The best way I can see to do this is to somehow override the exception handling but I was wondering if there was a better way?

An option that starts with no_ which is false by default:

# file script.rb
require 'optimist'
opts = Optimist.options do
  opt :no_blank_cleaning, "Deactivates cleaning of null and empty fields", default: false
end
puts opts

Using the short-name -n does the opposite of using the long-name --no-blank-cleaning.

$ ruby script.rb -n
{:no_blank_cleaning=>false, :help=>false, :no_blank_cleaning_given=>true}
$ ruby script.rb --no-blank-cleaning
{:no_blank_cleaning=>true, :help=>false, :no_blank_cleaning_given=>true}

I suspect when the options name starts with no_ the logic interferes with the logic that handles the flags that are true by default. Since this is a flag which is false by default (even if its name starts with no_) I expected it to work like any other flag x which is false by default .

Trollop.educate exits with code 0. I would like to use Trollop in an existing script, but usage errors must exit with a code N != 0. As a workaround, I can reopen Trollop:

module Trollop
  def self.educate_without_exiting
    @last_parser.educate
  end
end

# somewhere in my code
Trollop.educate_without_exiting
exit(N)

Is there a better way for me to exit with a code N of my choosing?

PS: I'm using Trollop for the first time and I really like it so far. Thanks for the lib!

Hi,
Googling for Trollop gives back an old version of the trollop web page, this specifically: http://trollop.rubyforge.org/

I think it's confusing to see multiple web pages, one up to date and one with references to the old git repo (gitorious one). Can someone do something about it? The rubyforge page should be a 301 redirect to http://manageiq.github.io/trollop/, or be deleted.

Hello,

I'm packaging rubygem-optimist for Fedora/EPEL and stuck with missing LICENSE file which is mandatory…

Could you please add it here and make new release?

Hello,

I am maintaining legacy code written by someone else quite some years ago, in trollop.

I have just seen the message on the commandline that trollop is now called optimist.

I have no problem with this per se, but I would like to know how difficult it may be to rewrite trollop-code in optimist. Right now I have no idea.

Would it be possible to add a subsection to the main readme? It does not have to be a long paragraph, just something that tells people who may be in a similar position as I am, how easy the rewrite operation may be. For example, would replacing all of Trollop with Optimist in the code as-is, continue to work? And if not, how to know how to replace it with?

Right now I am not sure how to proceed, since I was not the one who wrote the original code there. I would ideally like to invest as little time as possible :) but if it requires a larger rewrite then I am more inclined to just use ARGV directly since that is simpler; not as elegant and useful, but simpler for me in regards to maintaining the legacy code. (Rewriting the whole legacy code would take even longer ... sorry for that comment, I am just trying to be honest. As said the ideal situation would be for me to only have to e. g. replace require 'trollop' with require 'optimist', and replacing all Trollop with Optimist, but right now I just don't know, which is why a little helpful intro may help).

Thanks for reading.

With the new 2.1.0 update, all my trollop scripts are issuing the following warnings when using ruby's "-w" flag...

/usr/local/lib64/ruby/gems/2.0.0/gems/trollop-2.1.0/lib/trollop.rb:480: warning: ambiguous first argument; put parentheses or even spaces
/usr/local/lib64/ruby/gems/2.0.0/gems/trollop-2.1.0/lib/trollop.rb:248: warning: method redefined; discarding old usage
/usr/local/lib64/ruby/gems/2.0.0/gems/trollop-2.1.0/lib/trollop.rb:243: warning: previous definition of usage was here

Explicit raises are now inside the block. The entire mechanism seems to have been neglected, as it's application is uneven.

Hello there,
I've requirements here that I hope I explain it well.

here is the case I'm trying to do

ruby cooltool.rb -m COMMAND --cmd-sw
# eg
ruby cooltool.rb -m module1 --list user.txt

since the --list switch belongs to module1 not to cooltool

here's my initial dirty implementation

cooltool.rb

require 'trollop'
require 'pp'

module CoolTool
  class OptionParser
    attr_reader :main_opts

    def initialize
      @main_opts = Trollop::options do
        banner "Cool tool."
        banner "Options:"
        opt :parse, "Parse a string", :short => :p, :type => :string
        opt :module, "Use module", :short => :m, :default => ''
      end
    end

    def modules_list
      @modules_list = %w(module1 module2 module3)
    end
  end
end

opts = CoolTool::OptionParser.new
case
  when opts.main_opts[:parse]
    puts "Parsing!!"
  when opts.main_opts[:module]
    mod = opts.main_opts[:module]
    require "./#{mod}.rb"
    pp CoolTool::CoolToolModule.const_get(mod.capitalize).new
  else
    puts opts.main_opts
end

module1.rb

module CoolTool
  module CoolToolModule
    class Module1
      attr_accessor :opts
      def initialize
        @opts = Trollop::Parser.new do
          banner "Module1."
          banner "Options:"
          opt :list, "The user list.", :short => :l, :type => :string
        end
        @opts.parse ARGV
      end

      # make module read the file if -l user.txt
      def run
        if @opts[:list]
          File.readlines(@opts[:list])
        else
          puts 'Some Error'
        end
      end
    end
  end
end

I need each module to have its own commands and/or switches. Those modules called by --module/-m switch. The problem is, when I use --list switch trollop sees it as an argument for cooltool since its cooltool's stdin

 ruby cooltool.rb -m module1 --list user.txt

Error: unknown argument '-l'.
Try --help for help.

Thanks

This is my favorite library for option parsing, but I am hesitant to use it in any sort of formal work environment because I know some people may find the project name offensive.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

This repository currently has no open or pending branches.

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Due to the handling of :help/:version flags by raising an exception, there is little to no utility in overriding these. I suggest not raising an exception (arguably there is no exception) or providing a more comprehensive way to override this behavior if a user/developer supplies his/her own :help/:version options.

My code needs to input multi-line strings as a single value.
Entirety of the test code I created to test this issue:

require 'optimist'
opts = Optimist::options do
  opt :foo, 'foobar', short:none, type: :string
end
puts "foo is #{opts[:foo]}"

Command that works:

ruby rubyfile.rb --foo "bar
baz
qux" 

Output of command that works:

foo is bar
baz
qux

Command that produces error:

ruby rubyfile.rb --foo="bar
baz
qux" 

Output of command that produces error:

foo is bar

I thought it would be nice if Trollop could optionally integrate with Rainbow for coloured output. Would you be interested in a PR?

Hello,

I've implemented trollop in my script and have noticed that whenever I use this on my command line --help, a blank page is produced before the help screen is then shown.

Has anyone else noticed this behaviour and if so how can I ensure that the blank page isn't produced before the help screen is shown?

My setup is Windows 8.1 running latest version on trollop on Ruby 1.9.3

Thanks

Per longstanding PR #83, I have some ideas on ways to enhance behavior of optimist in ways that may not be backward compatible (see below). In order to make these new behaviors opt-in, it would be nice to have a way to tell optimist how to enable them.

Some implementation ideas include:

1. inside Optimist::options block, e.g.:

opts = Optimist.options do
  enable_some_setting
  opt :elk, "elk"
end

2. as arguments to Optimist.options

opts = Optimist.options(some_setting: true) do
  opt :yak, "yak"
end

3. Via class methods to set a global

Optimist.some_setting = true
opts = Optimist.options do
  opt :moose, "moose"
end

Downsides are:

• Alternative-1 causes order dependence (of the setting enablement and the opt command) which feels like it's not in the spirit of most DSLs.
• Alternative-2 causes problems with the cloaker function that is in Optimist.new
• Alternative-3 is ugly since it applies globally.

Would like maintainer/interested parties from previous PR's opinions ( @kbrock @Fryguy @jrafanie @chrisarcand ) on the best implementation before trying to resurrect #83.

For reference, suggested behavior enhancements would include the following and will probably be in separate PRs going forward:

It seems to be like this package uses a dependency called Minimist that has this vulnerability "CVE-2020-7598". Minimist patched this on 0.2.1.
https://nvd.nist.gov/vuln/detail/CVE-2020-7598

For rarely-used options I'd just as soon not have a short version, partly because short space is getting cluttered and partly so that for certain dangerous options the user has to actually type the whole thing out.

As far as I can tell there is no way to not have a short option for something. Am I missing something?

I got test failures when i ran, caused by issues in the Date handling.
The tests are providing U.S. formatted dates (e.g. 5/1/2010) but Date.parse expects Day/Month/Year format like is used in the E.U.
bypassing that test, the 'today' in test_date_formatting also caused breakage.
Both of these were fixed by installing the chronic gem.

I don't know the history behind this, so maybe this is intentional, but IMHO, an optional dependency shouldn't change existing functionality. Perhaps another way to handle could be a way to register a field (e.g. "%m/%d/%Y", "%Y/%m/%d", etc) for use with Time.strptime, though that would break the relative time feature that Chronic adds.

Given:

  parser = Trollop::Parser.new do
    opt :silent, %q{Causes the script to not ask any questions, instead all questions turn into email + abort; used by cron}, :short => 's'
    opt :region, %q{Causes the script only work on the listed region}, :short => 'r', :type => String
    opt :noinst, %q{Causes the script to skip the checking of all instances}, :short => 'i'
  end

Running it with -i gives us:

  {:silent=>false,
   :region=>nil,
   :noinst=>true,
   :help=>false,
   :noinst_given=>true}

However, given:

  parser = Trollop::Parser.new do
    opt :silent, %q{Causes the script to not ask any questions, instead all questions turn into email + abort; used by cron}, :short => 's'
    opt :region, %q{Causes the script only work on the listed region}, :short => 'r', :type => String
    opt :no_instances, %q{Causes the script to skip the checking of all instances}, :short => 'i'
  end

which is what I had originally, running it with -i gives:

  {:silent=>false,
   :region=>nil,
   :no_instances=>false,
   :help=>false,
   :no_instances_given=>true}

which strikes me as wrong.

From #130 (comment), @nanobowers wrote:

...should there any default notation in the help message for exclusivity clauses? If the developer uses either:, conflicts: or depends, seems like the only good way to find out is to try it and get an error message, or the developer would have to manually note it with the banner message.

Would kindly suggest to merge in the changes in the Optimist_XL gem, which is a feature enhancement fork. Also, it addresses #88 and #97, plus some closed-but-unresolved issues.

https://github.com/nanobowers/optimist_xl

I love your work, but would you please consider renaming it.
The word 'trollop' is highly judgemental. It makes me shudder to see it.

Definition of trollop
: a vulgar or disreputable woman; especially : one who engages in sex promiscuously or for money
https://www.merriam-webster.com/dictionary/trollop

This is a word invented purely for putting down women who are either hard-up for money or who want to engage in physical pleasures that we wouldn't think twice about men engaging in.

I note that the makers of Factory Girl renamed their gem. https://github.com/thoughtbot/factory_bot/blob/master/NAME.md

I have a program taking options with values. Sometimes those values start with a dash. If that happens, optimist tries to parse those as actual options instead of values, leading either to wrong options being activated or interested error messages.

The expected behavior is that the value after an option requiring a value is always assigned to the that option.

Here's an example:

#!/usr/bin/env ruby

require "optimist"
require "pp"

o = Optimist::options do
  opt :action, "an action", :type => :string
  opt :ignore, "ignore stuff"
end
pp o

Here are a couple of examples:

[0 mosu@sweet-chili ~/test] ./ruby1.rb --action jump
{:action=>"jump", :ignore=>false, :help=>false, :action_given=>true}
[0 mosu@sweet-chili ~/test] ./ruby1.rb --action --jump
Error: unknown argument '--jump'.
Try --help for help.
[255 mosu@sweet-chili ~/test] ./ruby1.rb --action -a --ignore
Error: option '-a' specified multiple times.
Try --help for help.
[255 mosu@sweet-chili ~/test] ./ruby1.rb --action --ignore
Error: option '--action' needs a parameter.
Try --help for help.

The first case is obviously OK.

The other cases are all really bad. In each case the value after --action (--jump in case 2, -a in case 3 and --ignore in case 4) should be assigned to the action option as the spec says that it must have a value.

Background: this is from a script doing DNS validation for the ACME protocol (Let's Encrypt certificates). It has to deal with the auth tokens that the Let's Encrypt servers generate. Today such an auth token started with a dash, and my program broke. I do not have any control over the auth tokens, which characters they consist of etc. A workaround such as "use different argument formats, then" doesn't help if I don't have control over the data my callers must use.

Maybe already a known issue, but URLs from the README are broken:

http://manageiq.github.io/optimist/
https://github.com/ManageIQ/optimist
https://github.com/ManageIQ/optimist/wiki
the code-climate widget URL

The new runtime dependency, "curses" (aptly named) :O) , is causing me all kinds of havoc. I have not figured out the fix yet. I have tried installing dev Ruby packages.
This is running on RHEL6 default system ruby 1.8.7

-bash-4.1# /usr/bin/gem install -v 2.0.6 --source http://blahblah/rubygems hiera-eyaml
Building native extensions. This could take a while...
ERROR: Error installing hiera-eyaml:
ERROR: Failed to build gem native extension.

/usr/bin/ruby extconf.rb
mkmf.rb can't find header files for ruby at /usr/lib/ruby/ruby.h

Gem files will remain installed in /usr/lib/ruby/gems/1.8/gems/curses-1.0.1 for inspection.
Results logged to /usr/lib/ruby/gems/1.8/gems/curses-1.0.1/ext/curses/gem_make.out

After installing a dev ruby the error changes to

Error: Could not update: Execution of '/usr/bin/gem install -v 2.0.1 --source http://blahblah.com/rubygems hiera-eyaml' returned 1: ERROR: Error installing hiera-eyaml:
ERROR: Failed to build gem native extension.

/usr/bin/ruby extconf.rb
checking for tgetent() in -ltinfo... no
checking for tgetent() in -ltermcap... no
checking for ncurses.h... no
checking for ncurses/curses.h... no
checking for curses_colr/curses.h... no
checking for curses.h... no
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers. Check the mkmf.log file for more
details. You may need configuration options.

I think the title covers it. :)

I saw this deprecation message: "[DEPRECATION] This gem has been renamed to optimist and will no longer be supported. Please switch to optimist as soon as possible."

But nothing in that message says which gem has been renamed. It wasn't hard to google the message, but if it's easy enough to push a new version of trollop, maybe it could be worth clarifying by changing "This gem" to "The trollop gem".

Optimist::ParserEduateTest#test_usage [/home/brain/rpmbuild/BUILDROOT/rubygem-optimist-3.0.0-1.fc33.x86_64/usr/share/gems/gems/optimist-3.0.0/test/optimist/parser_educate_test.rb:25]:
Expected /^Usage: \w* usage string\n\nOptions:/ to match "Usage: -e usage string\n\nOptions:\n".

Anything you'd like to know?

When running a Ruby program that includes the optimist gem, 3 warnings are shown.

warning: parentheses after method name is interpreted as an argument list, not a decomposed argument

These warnings apply to the optimist gem itself. There are three methods with a space between the method name and the opening parenthesis. Under Ruby 2.4, this causes a warning.

CVE-2024-39908 - Medium Severity Vulnerability

Vulnerable Library - rexml-3.2.8.gem

An XML toolkit for Ruby

Library home page: https://rubygems.org/gems/rexml-3.2.8.gem

Path to dependency file: /Gemfile.lock

Path to vulnerable library: /home/wss-scanner/.gem/ruby/3.2.0/cache/rexml-3.2.8.gem

Dependency Hierarchy:

• manageiq-style-1.5.1.gem (Root Library)
  • rubocop-rails-2.25.0.gem
    • rubocop-1.56.3.gem
      • ❌ rexml-3.2.8.gem (Vulnerable Library)

Found in base branch: master

Vulnerability Details

REXML is an XML toolkit for Ruby. The REXML gem before 3.3.1 has some DoS vulnerabilities when it parses an XML that has many specific characters such as <, 0 and %>. If you need to parse untrusted XMLs, you many be impacted to these vulnerabilities. The REXML gem 3.3.2 or later include the patches to fix these vulnerabilities. Users are advised to upgrade. Users unable to upgrade should avoid parsing untrusted XML strings.

Publish Date: 2024-07-16

URL: CVE-2024-39908

CVSS 3 Score Details (4.3)

Base Score Metrics:

• Exploitability Metrics:
  • Attack Vector: Network
  • Attack Complexity: Low
  • Privileges Required: None
  • User Interaction: Required
  • Scope: Unchanged
• Impact Metrics:
  • Confidentiality Impact: None
  • Integrity Impact: None
  • Availability Impact: Low

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-4xqq-m2hx-25v8

Release Date: 2024-07-16

Fix Resolution: rexml - 3.3.2

Step up your Open Source Security Game with Mend here

I’m having a heck of a time releasing using the lastest version from master. As it stand the last release on rubygem is in 2015. There has been some critical features that my program relies on, which are on master, but I cannot create my gem since Bundler will not manage gems from GitHub. Please push release to ruby gems and make my life a whole lot easier!

Thank you.

This gem no longer works on JRuby because it relies on the curses library, which uses an MRI C extension.

Perhaps you could use io/console instead?

Per @Student The question is whether it made sense to split up the gem into multiple files and classes.
The opt method is 111 lines and parse is 138.

First pass would be to determine if makes sense to represent each option using a class instead of the various options. There are far too many if blocks for my taste. Not sure where it would go from there.

Not sure if anyone has any extra comments and/or concerns.

On version 2.1.1, The Default value of :strings includes the [] bracket as a string. This did not happened on 2.0

opts = Trollop.options do
  opt :suites, 'List of Suites', :type => :strings, :default => ["AwSuites"]
  opt :debug, 'debug level', :default => "ERROR"
end

On 2.0

c:\>ruby duku.rb --suites  --debug ERROR
Error: option '--suites' needs a parameter.
Try --help for help.

c:\>ruby duku.rb  --debug ERROR
opts[:suites]: ["AwSuites"]
opts[:suites_given]:

c:\>ruby duku.rb --suites a b c --debug ERROR
opts[:suites]: ["a", "b", "c"]
opts[:suites_given]: true

But on 2.1.1

c:\>ruby duku.rb --suites  --debug ERROR
opts[:suites]: ["[\"AwSuites\"]"]        <<<<<<===============   Bracket included, instead of Error
opts[:suites_given]: true

c:\>ruby duku.rb  --debug ERROR
opts[:suites]: ["AwSuites"]
opts[:suites_given]:

c:\>ruby duku.rb --suites a b c --debug ERROR
opts[:suites]: ["a", "b", "c"]
opts[:suites_given]: true

EDIT: kbrock added syntax highlighting

There were a lot of really awesome pull requests merged recently, but the trollop on rubygems is still v2 from 2012!

I'm personally quite excited about the updates, so perhaps it's time for a 2.1 on Rubygems? 😄

I want to add a list of subcommands to my help message so when I call Trollop.educate it allows the user to see a list of subcommands. However, I am not sure how to customize the help message easily.

I almost bailed on trollop due to perceived lack of features I needed, but eventually dug through the code comments to figure out what i wanted. Much of this was b/c i found very few examples or how-to guides, other than the original documented example.

I'm willing to add accessible examples, and was thinking of putting together a wiki on the github, as opposed to the currently visibile documentation that lives here: http://manageiq.github.io/trollop

OTOH, there is some documentation in the code that is accessible through ri/Rdoc, and duplication via wiki may violate DRY or otherwise get stale. Thoughts?

The (last) 3.1.0 release was over a year ago and there have been a lot of updates since then.
Can we make a new versioned release / gem build?

@Fryguy

Some assertion tests do not do what they advertise:

$ rg 'assert_raises\([A-Za-z]+,' 
optimist/parser_test.rb
870:    assert_raises(CommandlineError, /--one.*--two/) { @p.parse %w(--one --two) }
907:    assert_raises(CommandlineError, /--one.*--two/) { @p.parse %w(--one) }
908:    assert_raises(CommandlineError, /--one.*--two/) { @p.parse %w(--two) }
916:    assert_raises(CommandlineError, /arg2/) { @p.parse(%w(--arg1)) }
917:    assert_raises(CommandlineError, /arg1/) { @p.parse(%w(--arg2)) }
1227:    assert_raises(CommandlineError, /unknown argument '--lib'/) do
1246:    assert_raises(CommandlineError, /specified multiple times/) do
1351:    assert_raises(RuntimeError, "good") do
1360:    assert_raises(RuntimeError, "good") do

The documentation for assert_raises says it takes one or more exceptions. Oops.
https://rubydoc.info/gems/minitest/Minitest%2FAssertions:assert_raises

thus, the Regexp or String given as the second argument is not doing anything.
These should be changed to use the assert_raises_errmatch helper function which takes a single exception type and a Regexp.

Per discussion with @Fryguy on a different PR there it would be good to improve some of the tests' message checking since that is rarely happening.

@miq-bot add-label test

From #130 (comment), @nanobowers wrote:

This seems like a specialization of a more general type of argument validation.

More specifically, the condition you are trying to satisfy with either: is max==1 and min==1. Should we entertain cases where min/max are not 1? conflicts: is kinda like max==1 and min==ANY

Was thinking something along the lines of:

validate min: <Integer/nil>, max: <Integer/nil>, args: <Array of Symbol>

I found this awesome gem, trollop-subcommands, that extends trollop with a better interface for creating subcommands. I wonder if we should somehow merge this into trollop directly? https://github.com/jwliechty/trollop-subcommands @jwliechty What do you think since you're the author of the gem?

I'm happy to see someone working on Trollop development and enhancing it. But the canon description of Trollop has always been "Single file. Throw it in lib/ if you don't want to make it a Rubygem dependency." However, the addition of trollop/version breaks that model. Historically the changes to Trollop tended to follow semantic versioning (even if Trollop itself was not explicitly semver), so that'd be a breaking change and outside the scope of what is permissible in a patch release.