Expose parsed options object in ParserResult
See original GitHub issueI tried using this library in my project today. I’m able to parse the command line from the examples just fine, but found no way to access the parsed options object directly from ParserResult
.
By my coding style, I prefer not use callbacks here (i.e. WithParsed
and WithNotParsed
). I’m already able to use the Tag
property to check if parsing succeeded. Am I just missing something here or can a property exposing the parsed object be added?
Issue Analytics
- State:
- Created 4 years ago
- Reactions:3
- Comments:15 (7 by maintainers)
Top Results From Across the Web
c# - How can you access the Value property of a ...
To get to parsed object (or errors in case parsing failed), you can do this: ParserResult<Options> parserResult = Parser.Default.
Read more >CommandLine.Parser Class Reference
Type array used to supply verb alternatives. Returns: A CommandLine.ParserResult{T} containing the appropriate instance with parsed values as a System.Object ...
Read more >API Documentation
Useful for parsing options such as mount options in the format rw,ro,rsize=32168,xyz . Parameters: optlist (str) -- String of options to parse. opt_sep...
Read more >Parse the Command Line with System.CommandLine
Enables parsing of command-line generic arguments (tokens) into distinct ... The constructs supported include commands, options, arguments, ...
Read more >Command Line Parser for C# | DC Coding - Dan Carter
The Options object o will be populated with the parsed options, which you can then use to control the behaviour of your app....
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
No offense, but I find using the
WithParsed
andWithNotParsed
to be very awkward. I don’t really see the point of having a command-line parser being part of my call stack which makes looking at debug logs and stack traces awkward. Once the command line is parsed and I have myOptions
back, I have no need for the parser object to stay in the stack in any form. It’s preferable to me that I get my options in a single step and then let the parser be garbage collected.Something simple like this is optimal for me from a command line parsing perspective:
This to me shows a clear separation of concerns (command line parsing vs running the program) and I don’t have random LINQ type statements making tracing my program take longer than needed.
Having
WithParsed
andMapResult
calls just adds unneeded overhead, both from a call stack as well as from developer review.From the original above:
The main issue was not having to use the
WithParsed
andWithNotParsed
methods at all.The Async was just a concrete example of how those methods didn’t help.
It also still doesn’t solve the issue with return values from
int Main(params string[] args)
.Can we just move the
Value
property from theParsed<T>
object and put it onParserResult<T>
instead? It seems like a more logical place to put it since ParserResult is already generic however it makes no public references to the generic type.