-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Prevent aliases already in use and subcommands with such an alias or the name already in use from being added #1924
Conversation
I had done some thinking when issue first added, and aliases are a complication. With current PR code aliases on the first command get checked when the second command is added. But I think not vice versa. Some possibilities:
|
I have come up with a better solution, check bd12c90 and the updated PR description. |
My suggestion from the first comment in #1917 enabling sharing and stand-alone use of subcommands won't work if this change is accepted, though. If we decide to implement the suggestion, the checks will have to be done at the beginning of parse calls as you suggested, which I honestly don't like because parse calls are only supposed to throw exceptions from user code (argParsers, hooks, actions), so might be a good idea to just dump that suggestion of mine. Update: There will be no problem if all parent commands are stored, see #1938 for an implementation. When that PR is merged, the check in |
The way commands with alias get displayed in the help is like I tried a rework to use that form in error messages:
Example error when use
|
Closing in favour of #2059 (added co-author on that PR). |
Pull Request
Problem
Adding aliases that are already in use and subcommands with such an alias or the name that is already in use is allowed.
Demo
Original issue
name
s to be registered #1903ChangeLog
Changed
Peer PRs
…solving similar problems