Prevent registering homonymous commands
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 62/100
Research direction
Start in subcommands.go at the Register behavior referenced near line 199, then inspect how subcommands.Commander stores and selects commands. Verify how repeated registrations with the same name behave. Done means a later registration replaces the earlier homonymous command instead of leaving the first one selected.
Written by the indexing model from the issue text.
Description
I could find this behavior when using this library in conjunction with go-cmdtest.
Because of how test suites in go-cmdtest work, a subcommand can be tested several times with different flags and arguments. In order for this to happen, for each variation, the program's main function is called, what consists of registering commands, so subcommands.Register is called more than once for the same command in a single go test run.
Because go-cmdtest overrides os.Stdout and os.Stderr before each test, I correctly set them to my type that implements subcommands.Command just before registering it, so it points to the correct output set by go-cmdtest.
However, because I register commands with the same name more than once and they are stored in the same subcommands.Commander (subcommands.DefaultCommander), when executing the subcommand more than once, only the first one registered is picked.
Of course, I already solved my problem by creating a new subcommands.Commander in the main function, but if a subcommands.Commander can only execute the first command registered for a list of homonymous commands, there is no point of letting more than one homonym to be registered.
So, for fixing this, I think there is no point in discarding the newer ones. I guess the best solution would be to override a subcommand when another of same name already exists. This way, no unused homonyms will get appended.
- Dominant language
- Go
- Stars
- 794
- Forks
- 52
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from google/subcommands
-
Difficulty 5/5 Over a week Newbie friendliness 20/100
google/subcommands#42 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
google/subcommands#41 ·
-
Difficulty 5/5 Over a week Newbie friendliness 30/100
google/subcommands#40 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 52/100
google/subcommands#38 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 35/100
google/subcommands#37 ·
All issues in google/subcommands
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 84/100
-
enhancement needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
kind/cleanup
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
kubernetes-sigs/kueue#15947 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
sympozium-ai/sympozium#627 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100