-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
Hidden console commands appear in "Did you mean .." list #33398
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
Comments
@m-vo To me, this is a bug, hidden should not leak anywhere. Would you like to work on a patch and submit a pull request to fix it? |
I guess this impacts lazy-loaded commands only, calling isHidden() requires instantiating the command. We probably need a new |
@fabpot Sure, I can give it a try. 👍 So we probably shouldn't allow hidden commands to be shortened at all (so that there is no ambiguity). Wdyt? If we only strip them from a list of suggestions, we would get a strange behaviour (and indirectly also leak information):
|
Disallowing hidden commands to be shortened sounds like a good idea to me. |
This PR was merged into the 4.4 branch. Discussion ---------- [Console] Do not leak hidden console commands | Q | A | ------------- | --- | Branch? | 4.4 (updated) | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #33398 | License | MIT This PR attempts to fix hidden console commands to be leaked when interacting with the console. These are the changes: * Hidden commands won't be shown anymore in the list of commands in a namespace as well as the list of suggestions ("Did you mean...") for invalid or ambiguous commands. * Hidden commands therefore now need to be always entered with their full name. * If an abbreviated command is entered that was previously ambiguous with (only) hidden commands, it's now executed directly (not ambiguous anymore). Side note: When implementing the tests & changes I realized that `Application->get()` isn't side effect free (when redirecting to the help command) and behaves differently when called multiple times. It therefore must not be used from inside `find()`. Maybe we should change this? Here are the relevant bits: https://github.com/symfony/symfony/blob/f71f74b36a80227d3e68f1b65b1f1d9b42fa9952/src/Symfony/Component/Console/Application.php#L495-L502 Commits ------- f340633 [Console] Deprecate abbreviating hidden command names using Application->find()
Description
Setting a command to
hidden
does not remove it from the list of suggested commands when the input is ambiguous. ("Did you mean one of these?"). That's of course a side effect of the command still being accessible and allowing commands to be shortened.It feels a bit inconsistent but I'm actually not sure what to change about this. So maybe add a note to the docs?
How to reproduce
some:visible-command
some:hidden-command
but configure it with$this->setHidden(true)
bin/console
→ only the first command is visible in the list of commands ✓bin/console some:
→Did you mean one of these? some:visible-command some:hidden-command
The text was updated successfully, but these errors were encountered: