Opened 17 years ago

Closed 12 years ago

#545 closed Bugs (fixed)

Program_options: Fails to parse options with a common root

Reported by: rleigh Owned by: Vladimir Prus
Milestone: Boost 1.44.0 Component: program_options
Version: Boost Development Trunk Severity: Problem
Keywords: Cc:

Description

Given the following testcase:

#include <iostream>
#include <boost/program_options.hpp>
namespace opt = boost::program_options;

int main(int   argc,
	 char *argv[])
{
  try
    {
      bool all, all_chroots, all_sessions;

      opt::options_description chroot("Chroot selection");
      chroot.add_options()
	("all,a", "Select all chroots and active sessions")
	("all-chroots", "Select all chroots")
	("all-sessions", "Select all active sessions");

      opt::variables_map vm;
      opt::store(opt::parse_command_line(argc, argv,
chroot), vm);
      opt::notify(vm);

      if (vm.count("all"))
	all = true;
      if (vm.count("all-chroots"))
	all_chroots = true;
      if (vm.count("all-sessions"))
	all_sessions = true;

      return 0;
    }
  catch (std::exception const& e)
    {
      std::cerr << e.what() << std::endl;
      return 1;
    }
}

$ g++ -o opt opt.cc -lboost_program_options
$ ./opt --help
unknown option help
$ ./opt --all-chroots
$ ./opt --all-sessions
$ ./opt --all
ambiguous option all

--all is not abiguous, since it's an exact match.  It's
not ambigous for GNU getopt or GLib GOption, so this is
IMHO a bug.


Regards,
Roger

ii  libboost-dev                  1.33.0-6   Boost C++
Libraries development fi
ii  libboost-program-options1.33. 1.33.0-6   program
options library for C++

Attachments (1)

program_options.patch (1.7 KB ) - added by christian.blichmann@… 12 years ago.
Patch for parsing options with same name-prefix

Download all attachments as: .zip

Change History (6)

comment:1 by Vladimir Prus, 17 years ago

Status: assignedclosed
Logged In: YES 
user_id=321498

A fix and a test were just committed. 
Thanks for the report! 

by christian.blichmann@…, 12 years ago

Attachment: program_options.patch added

Patch for parsing options with same name-prefix

comment:2 by christian.blichmann@…, 12 years ago

Severity: Problem

As of Boost 1.43.0 this is still problematic, see the test case below:

#include <iostream> #include <boost/program_options.hpp> namespace po = boost::program_options;

int main(int argc, char *argv[]) {

try {

bool all, all_chroots, all_sessions;

po::options_description chroot("Chroot selection"); chroot.add_options()

("flag", "Some boolean flag") ("flag2", "Another flag that gets matched approximately");

po::variables_map vm; po::store(po::parse_command_line(argc, argv, chroot), vm); po::notify(vm);

std::cout << "flag: " << vm.count("flag") << std::endl; std::cout << "flag2: " << vm.count("flag2") << std::endl;

return 0;

} catch (std::exception const& e) {

std::cerr << e.what() << std::endl; return 1;

}

}

Results:

$ g++ -o po-test po-test.cpp -lboost_program_options $ ./po-test --flag flag: 0 flag2: 1 $ ./po-test --flag2 flag: 0 flag2: 1 $ ./po-test --flag --flag2 multiple occurrences

Expected results (after applying program_options.patch):

$ ./po-test --flag flag: 1 flag2: 0 $ ./po-test --flag2 flag: 0 flag2: 1 $ ./po-test --flag --flag2 flag: 1 flag2: 1

comment:3 by christian.blichmann@…, 12 years ago

Component: Noneprogram_options
Milestone: Boost 1.44.0
Resolution: Fixed
Status: closedreopened
Summary: Proogram_options: Fails to parse options with a common rootProgram_options: Fails to parse options with a common root
Version: NoneBoost Development Trunk

comment:4 by Vladimir Prus, 12 years ago

You have set 'version' to 'Boost Development Trunk'. Have you actually tried with trunk? I guess not, since trunk appears to give your expected results on your testcase. Could you please double-check with trunk, and then mark this issue fixed again?

in reply to:  4 comment:5 by christian.blichmann@…, 12 years ago

Resolution: fixed
Status: reopenedclosed

Replying to vladimir_prus:

You have set 'version' to 'Boost Development Trunk'. Have you actually tried with trunk? I guess not, since trunk appears to give your expected results on your testcase. Could you please double-check with trunk, and then mark this issue fixed again?

You're right, trunk fixes the problem. I selected "Trunk" by mistake, sorry. Setting to "fixed" again.

Note: See TracTickets for help on using tickets.