Change:
CommandGroups: groups, Filtered:      filters, } <ins> cmd.SetFlagErrorFunc(templater.FlagErrorFunc()) </ins> cmd.SetUsageFunc(templater.UsageFunc()) cmd.SetHelpFunc(templater.HelpFunc()) return templater

Discussion:
The majority of kube binaries print usage when certain invalid arguments are presented. Unfortunately, most of our binaries have 2 pages of usage output, and the result of printing that is a very confusing and context disrupting action. In general, CLI commands try to minimize their output - for example: both print their minimal sets. Obviously, as commands grow the number of flags some of the short options become a bit silly (yes, congratulations, you have the entire alphabet of flags) and convey less useful information to a user. When errors are printed we also end up printing the error both above and below the command (in at least kubectl, kubelet, kube-apiserver, and controller-manager). I'm not even sure this was intentional, but coincidentally we print the errors twice and so it's both before and after the usage. Error feedback needs to minimize the amount of extraneous information presented to users for maximum clarity. Three are broadly four classes of help and error output: user explicitly requests help via or user provides an input that is not recognized (flag, command, or argument) and we can unambiguously know provided invalid input. User needs to change the input. user provides inputs that don't work well together or have conflicting meaning. User needs to change the input. user provided inputs that result in a runtime error, but that error can't be resolved by changing the input of the command. Recommended changes: our command and flag sets are so long, I don't think there is value in printing the full usage info in 2 and 3. Instead, I think we should print a minimal "usage: Run "command foo --help" to see usage info" message after printing the error. should stop printing error output twice (once as and once as ) in 2-4 and print as or (the former is more consistent with Posix guidelines). still need to clean up output.
this is really painful as an end user (and I've been tracking people who have these issues). I hit this while looking at and trying to clean it up, and realized we need to fix the broader problem.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with .

Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/reopen /assign This is still a thing.
Reopened this issue. <detailsIn response to : /reopen /assign This is still a thing. Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/remove lifecycle/rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This is still a thing. /assign /reopen
Reopened this issue. <detailsIn response to : This is still a thing. /assign /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
GitHub didn't allow me to assign the following users: sallyom.

Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : This is still a thing. /assign /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This is still very much a problem. Having to scroll through pages of options just to find the error output is terrible. I'm running kube-apiserver with systemd so it automatically restarts. This means the error itself ends up in the middle of hundreds of lines of unhelpful information. It's like finding a needle in a haystack to figure out what actually went wrong. If nothing else, a flag to turn it off would make it more manageable. /reopen /remove lifecycle/rotten
You can't reopen an issue/PR unless you authored it or you are a collaborator. <detailsIn response to : This is still very much a problem. Having to scroll through pages of options just to find the error output is terrible. I'm running kube-apiserver with systemd so it automatically restarts. This means the error itself ends up in the middle of hundreds of lines of unhelpful information. It's like finding a needle in a haystack to figure out what actually went wrong. If nothing else, a flag to turn it off would make it more manageable. /remove lifecycle/rotten Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/reopen /remove-lifecycle rotten
Reopened this issue.

<detailsIn response to : /reopen /remove lifecycle/rotten Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details