saveman / octargs Goto Github PK

As library user I would like to request handling of positional arguments to be able to process "unnamed" values provided by the user.

Details:

• Positional arguments are all these arguments specified by the user starting from the first one that has no match in registered arguments handling. For example looking at 'man echo' in Linux these are all "STRING" arguments in the "echo [SHORT-OPTION]... [STRING]..." request.
• Currently no limit or automatized processing of such arguments is needed, just storing them.
• If handling was not requested then providing such arguments should result in an error.

It would be good to have support for Windows-like arguments like /j:5.

Elements to change:

• name prefix should be '/' instead of '-' or '--'
• value separator should be ':'
• names should be case insensitive

Some reference data:
https://www.bleepingcomputer.com/tutorials/understanding-command-line-arguments-and-how-to-use-them/

As library user I would like to request handling of simple arguments (without values) so I am able to request simple functionalities like "--help" or "--version".

Details:

• Single name handling is enough in this version (so '-h' and '--help' are two separate arguments).
• Duplicated names should be detected and result in an error.
• It should be possible to register handling of multiple arguments.
• It should be possible to check if an option was specified from command line.
• No more complications needed at that time like checking if option was specified multiple times or making options exclusive.

As the library user I would like to provide values to arguments in a format "<option>=<value>" (example: "--lines=5") to be able to process them in the application.

Details:

This does not include specifying values in option=value format.
The values could be limited to string type.
Single value support is enough at this time.

As the library user I would like to have an option to cast the parsed values to different types to simplify the parsing process.

Details:

• The converters framework may be reused.

As a library user I want to configure the parser to use custom value separators, subparser prefix separators, different (e.g. localized) strings in usage documentation) etc.

Customization support needed for:

• separators
• boolean values ("true", "1")
• usage info

As the library user I would like to group the options so the generated usage documentation would be clear to user.

Example:

parser.add_group("general").set_description("General options")
parser.add_argument("--verbose").set_group("general").set_description("Produce verbose output")
parser.add_group("output").set_description("Generated output configuration")
parser.add_argument("--format").set_group("output").set_description("Output format: xml, text").set_value_name("fmt")
parser.add_argument("--compression").set_group("output").set_description("Compression level").set_value_name("level")

Usage info:

General options:
--verbose              Produce verbose output

Generated output configuration:
--format <fmt>         Output format: xml, text
--compression <level>  Compression level

./calc 4 4
ERROR
./calc -s 4 4
init=0
....
8

As the library user I would like to have more control on defining string constants to define for example customized (e.g. localized) true/false string representations.

Details:

• The traits class should be split into two elements: the char type trait (like for std::basic_string and the dictionary).

As the application use I would like to define argument value type (int, double, string, ...) so proper parser would be used and no additional parsing would be needed from the application itself.

Details:
This version could be limited to some predefined set of types.

• Default: string

Adding Conan support may be useful from the perspective of using the library in other projects.

As the library user I want to provide argument multiple times to be able to create collection of values or detect how many times user used the switch (e.g. increase verbosity if -v -v was used).

Details:

• It should be possible to define argument as single-value or multi-value. If argument is set to single value and multiple values are specified then an error should be signaled.
• If argument has multiple names the names could be mixed - for example "-I /usr/include --include-path /usr/local/include".
• Value type could be limited to string at this stage.

As the library user I would like to provide values to arguments in a format "<option> <value>" (example: "--lines 5") to be able to process them in the application.

Details:

• This does not include specifying values in option=value format.
• The values could be limited to string type.
• Single value support is enough at this time.

As library maintainer I want to have a script so I could prepare releases quickly and in safe way (correct branch & tag etc.).

As the package maintainer I want to create packages for Linux automatically to make creating releases easy and reproducible.

As the library user I would like to specify default value for the argument so in case the argument is not present in input this value will be used in results.

As the library user I would like to configure the argument in a simple way without the separation between argument details and handler (type, storage).

To be described:

• limit value(s) to some predefined set ("enum")

As the library user I want to enable 'dash only' mode so only arguments with names starting with dash are allowed.

That will allow defining arguments with multiple values given at once - for example:
send_email --to [email protected] [email protected] --subject "Messages subject" --body "This is a test message, I am checking the tool."

As the library user I would like to have the API simplified so there will be no difference between storing and non-storing parser.

Description:

• This could be probably done using template specialization with values_storage_type = void or similar approach.

As the library user I would like the exceptions to be more descriptive so I could provide maximum usable information to the user.

Example:
Instead of parse_exception define duplicated_value_exception(argument_name).

Provide a documentation (e.g. auto generated using doxygen).
Extend the README with general information and examples.

Hi again. For implementing "nesting" feature in HydrArgs (in fact, that is probably is one of the most important features in it) I need a way to get the "unconsumed" args. I mean the ones not recognized by the parser of the current level. I wonder what is the recommended way to do it? I guess it can be worked around by adding a dedicated positional argument into the end, but it would spoil help output and also would require a method to remove positional args from the spec (HydrArgs model assummes that args can be appended one-by-one, and in the case something must be done after the last arg is added, the framework has a pair of methods, _seal and _unseal. I can add the code adding a dummy positional arg into _seal, but there is no methods to remove them, so there is nothing that I can put into _unseal that reverts the action done by _seal).

So, if there is no such a feature, it may make sense to introuduce it, for example as a method setting a pointer to std::span<char *> (to place there just a direct subarray of argv).

Following errors are present (maybe more):
/octargs/include/octargs/internal/../internal/../dictionary.hpp:316:26: error: ‘init_mode’ is not a class, namespace, or enumeration
/octargs/include/octargs/internal/parser_data.hpp:55:78: error: ‘class oct::args::internal::basic_parser_data<char, void>’ has no member named ‘weak_from_this’
/octargs/include/octargs/internal/parser_data.hpp:64:82: error: ‘class oct::args::internal::basic_parser_data<char, void>’ has no member named ‘weak_from_this’
/octargs/include/octargs/internal/parser_data.hpp:74:79: error: ‘class oct::args::internal::basic_parser_data<char, void>’ has no member named ‘weak_from_this’
/octargs/include/octargs/internal/parser_data.hpp:79:82: error: ‘class oct::args::internal::basic_parser_data<char, void>’ has no member named ‘weak_from_this’
/octargs/include/octargs/internal/parser_data.hpp:69:79: error: ‘class oct::args::internal::basic_parser_data<char, void>’ has no member named ‘weak_from_this’
/octargs/include/octargs/internal/parser_data.hpp:185:57: error: ‘class oct::args::internal::basic_parser_data<char, void>’ has no member named ‘weak_from_this’
make[2]: Target 'examples/calc/CMakeFiles/octargs_calc.dir/build' not remade because of errors.
/octargs/include/octargs/internal/../internal/../dictionary.hpp:316:26: error: ‘init_mode’ is not a class, namespace, or enumeration
/octargs/include/octargs/internal/parser_data.hpp:64:82: error: ‘class oct::args::internal::basic_parser_data<char, oct_args_examples::cat_app_settings>’ has no member named ‘weak_from_this’
/octargs/include/octargs/internal/parser_data.hpp:69:79: error: ‘class oct::args::internal::basic_parser_data<char, oct_args_examples::cat_app_settings>’ has no member named ‘weak_from_this’
/octargs/include/octargs/internal/parser_data.hpp:79:82: error: ‘class oct::args::internal::basic_parser_data<char, oct_args_examples::cat_app_settings>’ has no member named ‘weak_from_this’
/octargs/include/octargs/internal/parser_data.hpp:185:57: error: ‘class oct::args::internal::basic_parser_data<char, oct_args_examples::cat_app_settings>’ has no member named ‘weak_from_this’
make[2]: Target 'examples/cat/CMakeFiles/octargs_cat.dir/build' not remade because of errors.
/octargs/include/octargs/internal/../internal/../dictionary.hpp:316:26: error: ‘init_mode’ is not a class, namespace, or enumeration
/octargs/include/octargs/internal/parser_data.hpp:84:82: error: ‘class oct::args::internal::basic_parser_data<char, oct_args_examples::app_settings>’ has no member named ‘weak_from_this’
/octargs/include/octargs/internal/parser_data.hpp:64:82: error: ‘class oct::args::internal::basic_parser_data<char, oct_args_examples::app_settings>’ has no member named ‘weak_from_this’
/octargs/include/octargs/internal/parser_data.hpp:69:79: error: ‘class oct::args::internal::basic_parser_data<char, oct_args_examples::app_settings>’ has no member named ‘weak_from_this’
/octargs/include/octargs/internal/parser_data.hpp:74:79: error: ‘class oct::args::internal::basic_parser_data<char, oct_args_examples::app_settings>’ has no member named ‘weak_from_this’
/octargs/include/octargs/internal/parser_data.hpp:185:57: error: ‘class oct::args::internal::basic_parser_data<char, oct_args_examples::app_settings>’ has no member named ‘weak_from_this’
make[2]: Target 'examples/getfile/CMakeFiles/octargs_getfile.dir/build' not remade because of errors.
/octargs/include/octargs/internal/../internal/../dictionary.hpp:316:26: error: ‘init_mode’ is not a class, namespace, or enumeration
/octargs/include/octargs/internal/parser_data.hpp:64:82: error: ‘class oct::args::internal::basic_parser_data<char, void>’ has no member named ‘weak_from_this’
/octargs/include/octargs/internal/parser_data.hpp:74:79: error: ‘class oct::args::internal::basic_parser_data<char, void>’ has no member named ‘weak_from_this’
/octargs/include/octargs/internal/parser_data.hpp:69:79: error: ‘class oct::args::internal::basic_parser_data<char, void>’ has no member named ‘weak_from_this’
/octargs/include/octargs/internal/parser_data.hpp:79:82: error: ‘class oct::args::internal::basic_parser_data<char, void>’ has no member named ‘weak_from_this’
/octargs/include/octargs/internal/parser_data.hpp:185:57: error: ‘class oct::args::internal::basic_parser_data<char, void>’ has no member named ‘weak_from_this’
make[2]: Target 'examples/head/CMakeFiles/octargs_head.dir/build' not remade because of errors.
/octargs/include/octargs/internal/../internal/../dictionary.hpp:316:26: error: ‘init_mode’ is not a class, namespace, or enumeration
/octargs/include/octargs/internal/parser_data.hpp:55:78: error: ‘class oct::args::internal::basic_parser_data<char, void>’ has no member named ‘weak_from_this’
/octargs/include/octargs/internal/parser_data.hpp:185:57: error: ‘class oct::args::internal::basic_parser_data<char, void>’ has no member named ‘weak_from_this’
/octargs/include/octargs/internal/parser_data.hpp:64:82: error: ‘class oct::args::internal::basic_parser_data<char, void>’ has no member named ‘weak_from_this’
/octargs/include/octargs/internal/parser_data.hpp:74:79: error: ‘class oct::args::internal::basic_parser_data<char, void>’ has no member named ‘weak_from_this’
/octargs/include/octargs/internal/parser_data.hpp:79:82: error: ‘class oct::args::internal::basic_parser_data<char, void>’ has no member named ‘weak_from_this’
make[2]: Target 'examples/sum/CMakeFiles/octargs_sum.dir/build' not remade because of errors.
/octargs/include/octargs/internal/../internal/../dictionary.hpp:316:26: error: ‘init_mode’ is not a class, namespace, or enumeration
/octargs/include/octargs/internal/parser_data.hpp:185:57: error: ‘class oct::args::internal::basic_parser_data<char, oct_args_examples::settings>’ has no member named ‘weak_from_this’
/octargs/include/octargs/internal/parser_data.hpp:64:82: error: ‘class oct::args::internal::basic_parser_data<char, oct_args_examples::settings>’ has no member named ‘weak_from_this’
/octargs/include/octargs/internal/parser_data.hpp:74:79: error: ‘class oct::args::internal::basic_parser_data<char, oct_args_examples::settings>’ has no member named ‘weak_from_this’
/octargs/include/octargs/internal/parser_data.hpp:69:79: error: ‘class oct::args::internal::basic_parser_data<char, oct_args_examples::settings>’ has no member named ‘weak_from_this’
/octargs/include/octargs/internal/parser_data.hpp:79:82: error: ‘class oct::args::internal::basic_parser_data<char, oct_args_examples::settings>’ has no member named ‘weak_from_this’
make[2]: Target 'examples/win_head/CMakeFiles/octargs_win_head.dir/build' not remade because of errors.

To be described

1. Do a windows build.
2. Run test on windows.
3. Check support for unicode (wchar) etc.

As the library user I would like to provide descriptions and use the library to generate usage and help information for the user in automatic way.

Example:
Configure:

parser.set_app_name("cat").add_description('Concatenate FILE(s) to standard output")
parser.add_option('-n").add_description("Print line numbers");
parser.add_option('-e").add_description("Print line end markers");
parser.add_positional_argument("FILE").set_multivalue(true).set_description("File(s) to concatenate";

Print help:
parser.print_usage(std::cout)
Output:

cat [<option>...] [FILE...]

Options:
-n    Print line numbers
-e    Print line end markers

Arguments:
FILE   File(s) to concatenate

As the application user I would like to specify positional arguments with names to make the handling of such arguments clearly visible in the code.

Details:
With this feature it should be possible to do:

• Add position argument "input-file"
• Add position argument "output-file"
• Add position argument "patterns..." (multivalue, must be last)
  Then call parse() and if successful use the parsed values like:
  input_file = values.get("input-file")
  output_file = values.get("output-file")
  for (auto& pattern : values.get("patterns")) process(pattern)

As the library user I would like to register exclusive arguments to be able to create features like "--help" or "--version".

Details:

• Why exclusive arguments are needed? If there are any required arguments defined (min count > 0) then user could not simply do app --help as the required argument will not be provided so an error will be generated.
• It is acceptable to implement the the exclusive arguments as switch arguments.

As library user I would like to register arguments with multiple names so it would be possible to have e.g. arguments with both short and long names.

Details:

• It should be possible to register the argument with one, two or multiple names (e.g. "--help", "-h" + "--help" or "-h" + "--help" + "--usage").
• Asking the API if the arguments was specified should work same way if using any of the names given during registration. So for example was_specifed('-h') == was_specified('--help').
• Name duplicates must be detected (for same argument as well as for different arguments) and result in an error.

As the library user I want to use nested parsers to create application using "command" pattern like e.g. 'git'.

Example:
git --verbose commit -m "Message"
git push --dry-run origin dev:master
where
git - application name
--verbose - main parser option (affects whole application)
commit, pus - main parser "commands"
-m - "commit" parser option with value
--dry-run - "push" parser switch
origin dev:master - "push" parser positional arguments