Может ли OptionParser пропустить неизвестные параметры, которые будут обработаны позже в программе Ruby?

для потомства, вы можете сделать это с order! способ:

option_parser.order!(args) do |unrecognized_option|
  args.unshift(unrecognized_option)
end

в этот момент args был изменен - все известные параметры были потреблены и обработаны option_parser - и может быть передан в другой синтаксический вариант:

some_other_option_parser.order!(args) do |unrecognized_option|
  args.unshift(unrecognized_option)
end

очевидно, что это решение зависит от порядка, но то, что вы пытаетесь сделать, несколько сложно и необычно.

одна вещь, которая может быть хорошим компромиссом является просто использовать -- в командной строке, чтобы остановить обработка. Сделав это, он уйдет args С тем, что последовало --, будь то дополнительные опции или просто обычные аргументы.

мне нужно было решение, которое не бросало бы OptionParser::InvalidOption когда-либо, и не смог найти элегантное решение среди текущих ответов. Этот патч обезьяны основан на одном из другие ответы но очищает его и делает его более похожим на текущий order! семантика. Но см. ниже нерешенную проблему, присущую разбору вариантов с несколькими проходами.

class OptionParser
  # Like order!, but leave any unrecognized --switches alone
  def order_recognized!(args)
    extra_opts = []
    begin
      order!(args) { |a| extra_opts << a }
    rescue OptionParser::InvalidOption => e
      extra_opts << e.args[0]
      retry
    end
    args[0, 0] = extra_opts
  end
end

работает так же, как order! за исключением вместо бросать InvalidOption, он оставляет непризнанный переключатель в ARGV.

тесты RSpec:

describe OptionParser do
  before(:each) do
    @parser = OptionParser.new do |opts|
      opts.on('--foo=BAR', OptionParser::DecimalInteger) { |f| @found << f }
    end
    @found = []
  end

  describe 'order_recognized!' do
    it 'finds good switches using equals (--foo=3)' do
      argv = %w(one two --foo=3 three)
      @parser.order_recognized!(argv)
      expect(@found).to eq([3])
      expect(argv).to eq(%w(one two three))
    end

    it 'leaves unknown switches alone' do
      argv = %w(one --bar=2 two three)
      @parser.order_recognized!(argv)
      expect(@found).to eq([])
      expect(argv).to eq(%w(one --bar=2 two three))
    end

    it 'leaves unknown single-dash switches alone' do
      argv = %w(one -bar=2 two three)
      @parser.order_recognized!(argv)
      expect(@found).to eq([])
      expect(argv).to eq(%w(one -bar=2 two three))
    end

    it 'finds good switches using space (--foo 3)' do
      argv = %w(one --bar=2 two --foo 3 three)
      @parser.order_recognized!(argv)
      expect(@found).to eq([3])
      expect(argv).to eq(%w(one --bar=2 two three))
    end

    it 'finds repeated args' do
      argv = %w(one --foo=1 two --foo=3 three)
      @parser.order_recognized!(argv)
      expect(@found).to eq([1, 3])
      expect(argv).to eq(%w(one two three))
    end

    it 'maintains repeated non-switches' do
      argv = %w(one --foo=1 one --foo=3 three)
      @parser.order_recognized!(argv)
      expect(@found).to eq([1, 3])
      expect(argv).to eq(%w(one one three))
    end

    it 'maintains repeated unrecognized switches' do
      argv = %w(one --bar=1 one --bar=3 three)
      @parser.order_recognized!(argv)
      expect(@found).to eq([])
      expect(argv).to eq(%w(one --bar=1 one --bar=3 three))
    end

    it 'still raises InvalidArgument' do
      argv = %w(one --foo=bar)
      expect { @parser.order_recognized!(argv) }.to raise_error(OptionParser::InvalidArgument)
    end

    it 'still raises MissingArgument' do
      argv = %w(one --foo)
      expect { @parser.order_recognized!(argv) }.to raise_error(OptionParser::MissingArgument)
    end
  end
end

проблема: обычно OptionParser позволяет сокращенные варианты, при условии, что есть достаточно символов, чтобы однозначно определить предполагаемый вариант. Разбор параметров в несколько этапов нарушает это, потому что OptionParser не видит все возможные аргументы в первом проходе. Например:

describe OptionParser do
  context 'one parser with similar prefixed options' do
    before(:each) do
      @parser1 = OptionParser.new do |opts|
        opts.on('--foobar=BAR', OptionParser::DecimalInteger) { |f| @found_foobar << f }
        opts.on('--foo=BAR', OptionParser::DecimalInteger) { |f| @found_foo << f }
      end
      @found_foobar = []
      @found_foo = []
    end

    it 'distinguishes similar prefixed switches' do
      argv = %w(--foo=3 --foobar=4)
      @parser1.order_recognized!(argv)
      expect(@found_foobar).to eq([4])
      expect(@found_foo).to eq([3])
    end
  end

  context 'two parsers in separate passes' do
    before(:each) do
      @parser1 = OptionParser.new do |opts|
        opts.on('--foobar=BAR', OptionParser::DecimalInteger) { |f| @found_foobar << f }
      end
      @parser2 = OptionParser.new do |opts|
        opts.on('--foo=BAR', OptionParser::DecimalInteger) { |f| @found_foo << f }
      end
      @found_foobar = []
      @found_foo = []
    end

    it 'confuses similar prefixed switches' do
      # This is not generally desirable behavior
      argv = %w(--foo=3 --foobar=4)
      @parser1.order_recognized!(argv)
      @parser2.order_recognized!(argv)
      expect(@found_foobar).to eq([3, 4])
      expect(@found_foo).to eq([])
    end
  end
end

у меня такая же проблема, и я нашел следующее решение:

другое решение, которое полагается на parse! оказывает побочный эффект на список аргументов, даже если возникает ошибка.

давайте определим метод, который пытается сканировать некоторый список аргументов с помощью определяемого пользователем синтаксического анализатора и вызывает себя рекурсивно при возникновении ошибки InvalidOption, сохраняя недопустимую опцию для последующего использования с возможными параметрами:

def parse_known_to(parser, initial_args=ARGV.dup)
    other_args = []                                         # this contains the unknown options
    rec_parse = Proc.new { |arg_list|                       # in_method defined proc 
        begin
            parser.parse! arg_list                          # try to parse the arg list
        rescue OptionParser::InvalidOption => e
            other_args += e.args                            # save the unknown arg
            while arg_list[0] && arg_list[0][0] != "-"      # certainly not perfect but
                other_args << arg_list.shift                # quick hack to save any parameters
            end
            rec_parse.call arg_list                         # call itself recursively
        end
    }
    rec_parse.call initial_args                             # start the rec call
    other_args                                              # return the invalid arguments
end

my_parser = OptionParser.new do
   ...
end

other_options = parse_known_to my_parser

Мне тоже нужно было то же самое... это заняло у меня некоторое время, но в конце концов относительно простой способ сработал отлично.

options = {
  :input_file => 'input.txt', # default input file
}

opts = OptionParser.new do |opt|
  opt.on('-i', '--input FILE', String,
         'Input file name',
         'Default is %s' % options[:input_file] ) do |input_file|
    options[:input_file] = input_file
  end

  opt.on_tail('-h', '--help', 'Show this message') do
    puts opt
    exit
  end
end

extra_opts = Array.new
orig_args = ARGV.dup

begin
  opts.parse!(ARGV)
rescue OptionParser::InvalidOption => e
  extra_opts << e.args
  retry
end

args = orig_args & ( ARGV | extra_opts.flatten )

" args "будет содержать все аргументы командной строки без тех, которые уже проанализированы в хэше" options". Я передаю эту "args" внешней программе, которая будет вызвана из этого сценария ruby.

я столкнулся с аналогичной проблемой, когда писал сценарий, который обернул ruby gem, который нуждался в собственных опциях с аргументами, переданными ему.

Я придумал следующее решение, в котором она поддерживает функции с аргументами для обернутого инструмента. Он работает, анализируя его через первый optparser и отделяет то, что он не может использовать, в отдельный массив (который можно повторно проанализировать с другим optparse).

optparse = OptionParser.new do |opts|
    # OptionParser settings here
end

arguments = ARGV.dup
secondary_arguments = []

first_run = true
errors = false
while errors || first_run
  errors = false
  first_run = false
  begin
    optparse.order!(arguments) do |unrecognized_option|
      secondary_arguments.push(unrecognized_option)
    end
  rescue OptionParser::InvalidOption => e
    errors = true
    e.args.each { |arg| secondary_arguments.push(arg) }
    arguments.delete(e.args)
  end
end

primary_arguments = ARGV.dup
secondary_arguments.each do |cuke_arg|
  primary_arguments.delete(cuke_arg)
end

puts "Primary Args: #{primary_arguments}"
puts "Secondary Args: #{secondary_args}"

optparse.parse(primary_arguments)
# Can parse the second list here, if needed
# optparse_2.parse(secondary_args)

наверное, не лучший или самый эффективный способ сделать это, но это сработало для меня.

я только что переехал из Python. В Python ArgumentParser есть отличный способ parse_known_args(). Но он по-прежнему не принимает второй аргумент, например:

$ your-app -x 0 -x 1

первый -x 0 является аргументом вашего приложения. Второй -x 1 может принадлежать целевому приложению,которое вам нужно переслать. ArgumentParser вызовет ошибку в этом случае.

теперь вернитесь к Ruby, вы можете использовать #order. К счастью, он принимает неограниченные повторяющиеся аргументы. Например, вам нужно -a и -b. Ваш получатель должен еще -a и обязательный аргумент some (обратите внимание, что нет префикса -/--). Обычно #parse будет игнорировать обязательные аргументы. Но с #order, вы получите остальное-замечательно. Примечание что вы должны передать аргументы своего собственного приложения первый, затем аргументы целевого приложения.

$ your-app -a 0 -b 1 -a 2 some

и код должен быть:

require 'optparse'
require 'ostruct'

# Build default arguments
options = OpenStruct.new
options.a = -1
options.b = -1

# Now parse arguments
target_app_argv = OptionParser.new do |opts|
    # Handle your own arguments here
    # ...
end.order

puts ' > Options         = %s' % [options]
puts ' > Target app argv = %s' % [target_app_argv]

Тада :-)

моя попытка:

def first_parse
  left = []
  begin
    @options.order!(ARGV) do |opt|
      left << opt
    end
  rescue OptionParser::InvalidOption => e
    e.recover(args)
    left << args.shift
    retry
  end
  left
end

в моем случае я хочу сканировать параметры и выбирать любые предопределенные параметры, которые могут устанавливать уровни отладки, выходные файлы и т. д. Затем я собираюсь загрузить пользовательские процессоры, которые могут добавить к параметрам. После загрузки всех пользовательских процессоров я вызываю @options.parse!(left) для обработки оставшихся вариантов. Обратите внимание, что -- help встроен в опции, поэтому, если вы хотите не распознать помощь в первый раз, вам нужно сделать ' OptionParser:: Officious.удалить ('help') ' перед созданием OptParser, а затем добавить в свой собственный вариант справки

параметры разбора до первого неизвестного параметра ... блок может вызываться несколько раз, поэтому убедитесь, что это безопасно ...

options = {
  :input_file => 'input.txt', # default input file
}

opts = OptionParser.new do |opt|
  opt.on('-i', '--input FILE', String,
    'Input file name',
    'Default is %s' % options[:input_file] ) do |input_file|
    options[:input_file] = input_file
  end

  opt.on_tail('-h', '--help', 'Show this message') do
    puts opt
    exit
  end
end

original = ARGV.dup
leftover = []

loop do
  begin
    opts.parse(original)
  rescue OptionParser::InvalidOption
    leftover.unshift(original.pop)
  else
    break
  end
end

puts "GOT #{leftover} -- #{original}"