-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Needs to handle free arguments. #1
Comments
Interesting, I've not used free arguments before. May I ask what purpose do they serve, and how would you expect to consume them through the api? What if the same free argument was specified twice? |
Often a command has some primary function that is associated with one or more file-names or a host name, for example. In such cases it makes sense to pass them without an option. Prominent examples are I would prefer to retrieve the free arguments via callbacks in the DSL instead of going through a list of free arguments in the result interface, simply because free arguments may need to take part in the error checking. Right now free arguments are ignored and commands could run without being sure that all the user input was handled properly. What should happen when the same free argument is passed twice to a command is up to the command's semantic. So either the DSL supports some additional parameterization or - if a callback is used - it just calls it for each in the order supplied. I guess it could also happen that a free argument is just a shortcut that provides a value for one of the options, so there could also be a method that marks an option as the one that receives the free arguments by default. |
I'm going to spend some time soon working towards other features to include so I will see about how free arguments could fit into it. If you have any other suggestions I will be interested to hear them. |
One related thing I can remember is that some Linux commands support this
This seems to be very useful for commands that wish to forward options and arguments to other commands. The API could look something like:
|
Work almost complete towards support for Using your initial example:
The setup looks like this
It can also be used to safely handle negative integer and doubles
can be safely parsed to a list of integers using
|
Great work! But I'm not sure if your interpretation of the I don't think that arguments after In |
I agree with pragmatrix. It's like in git commit command (https://www.kernel.org/pub/software/scm/git/docs/git-commit.html) , the free arguments at the end represent a list of files, which are not linked to any of the previous options. |
I also agree. Being able to parse something like
is a mandatory requirement for such a library, which is not satisfied here. |
UP I also agree with @pragmatrix and @do0om. Could you add a semantics like this ? In bash for example, you can clearly separate the arguments that are given to the shell and the script it executes: bash --login -- test.sh --option_for_test_sh. Here, everything before the -- goes to bash, everything after the -- goes to test.sh. |
You may look how other do that case. For example boost::program_options call this type of parameters Positional Options. Here is a small description. Hope it can help you to understed what they are. |
How about allowing certain arguments to be definable as positional to allow mapping of positional arguments to strongly-typed arguments. For example:
This would parse "app.exe -i filename.txt -o outfile.txt" and also "app.exe filename.exe outfile.txt" and also "app.exe outfile.txt -i filename.txt. You could mix named and positional arguments in any order. Basically, the parser would split the command line into parsable segments. It would first assign all the named argumented. Then it would take all the positional arguments in order and map the to the list of unassigned arguments in the order they were defined in the code. Examples:
|
I'd like to extract free arguments from the command line, e.g. arguments without an option like
MyConsoleApp.exe --opt1 opt1value Filename.txt
. Right now it seems thatFilename.txt
is ignored and can not be extracted fromCommandLineParserResult
.Is this planned?
The text was updated successfully, but these errors were encountered: