-
Notifications
You must be signed in to change notification settings - Fork 4
Completely rewrote the whole project with .NET Core as a target #4
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
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ake sense to have a special directory for it.
…opment progresses.
…d a bug, which caused an exception for non-generic collection types, when testing whether a type is supported by the collection helper.
…t to have an overload with options but without a description.
…ands have the same name or alias.
…alue even if the casing is not correct (e.g. "friday" can be converted to DayOfWeek.Friday even though friday was not capitalized).
… of named arguments.
…ed to the parsing results.
…ands, positional arguments, and named arguments already seem to work very well.
…e parser handles allowed name collisions correctly.
…tructors, which set sensible default values depending on what was specified in the parameters.
…, i.e. do not start with unallowed characters.
…valid types an exception was thrown.
…ll not supported.
…tom duplicate resolution policies work.
…ts that were not present in the command line arguments.
…that are of a collection type.
…ts and thereby enabled non-collection type named arguments to have multiple values, which is helpful when dealing with custom duplicate resolution policies.
…s, e.g. "--age=18" instead of "--age 18" or "/use=yes" instead of "/use yes".
lecode-official
added a commit
that referenced
this pull request
Sep 11, 2020
Completely rewrote the whole project with .NET Core as a target
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
After more than a year the new version of the command line parser is finally finished. When I first started with the project I imagined a completely new syntax for command line arguments, which build upon the traditional POSIX-style command line arguments syntax but expanded it with some syntactical sugar for various scenarios that are traditionally not easy when dealing with command line arguments (e.g. lists).
Soon after the first version of this project, Microsoft released .NET Core so I was excited to release the project for other platforms as well. But my hopes were shattered when I found out that the
System.Environment.CommandLine
API was missing from .NET Core. At first I thought it was just one of those APIs that did not make it, yet. But as I started to research the problem, I found out that the API was missing, because the problem was systemic. When starting a new program on a *NIX operating system, the system call already expects the command line arguments to be split. That means that the program is never able to get to the original string that was entered by the user.Now you might think this is not a huge deal, but my extended syntax relies on getting the whole command line arguments as a single string, not as an array of strings. Just "gluing" the array back together won't do the trick, as my syntax was ambiguous in those cases. Just have a look at the valiant effort of the Mono team to implement the
System.Environment.CommandLine
property.I thought about the problem long and hard and I came to the conclusion that the only way the project could be salvaged was by giving up on the idea of extending the classic command line syntax. I had a look at how other similar projects, such as
argparse
solved problems like lists and figured out a way to implement those feature without extending the original syntax.The original implementation relies on ANTLR to parse the command line arguments. This is no longer a viable option when dealing with string arrays. This is why I decided to completely rewrite the project from scratch. This pull request contains these efforts. The new release is not finished, yet, as there are several features that I would like to include. But as of now, both version have a comparable feature set and I decided to put the new version on master.