Error Message Should Not Also Display Help Message

[danielhelfand]

Currently, when an error occurs, the user sees the error message returned and below that message is shown the --help output for the command that produced the error.

It's a bit overwhelming to get all of the information from --help when the user is not expecting it, and it also makes it difficult to find the error message.

I am proposing in this issue that the Tekton CLI simply return the error message instead of information from --help. An alternative that would allow the user to make the choice to see all of the information from --help would be to suggest to run --help with the command that was run.

Expected Behavior

When an error occurs, a user should simply receive the error message.

Actual Behavior

The user receives the error message and also receives information from --help.

Steps to Reproduce the Problem

1. Run tkn pr ls -n and don't give -n a name argument
2. See the output from the command:

tkn pr ls -n 
Error: flag needs an argument: 'n' in -n
Usage:
  tkn pipelinerun list [flags]

Aliases:
  list, ls

Examples:

# List all PipelineRuns of Pipeline name 'foo'
tkn pipelinerun list foo -n bar

# List all pipelineruns in a namespaces 'foo'
tkn pr list -n foo",


Flags:
      --allow-missing-template-keys   If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. (default true)
  -h, --help                          help for list
  -o, --output string                 Output format. One of: json|yaml|name|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-file.
      --template string               Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates [http://golang.org/pkg/text/template/#pkg-overview].

Global Flags:
  -k, --kubeconfig string   kubectl config file (default: $HOME/.kube/config)
  -n, --namespace string    namespace to use (default: from $KUBECONFIG)

[girishramnani]

@danielhelfand I my opinion, with the error message a suggestion on what to do next e.g. use --usage to find the correct usage could also be shown to the user?
This approach can be clubbed together with this issue #124

[girishramnani]

also to add to the merits of the above mentioned approach, it aligns with how kubectl handles these kinds of inputs as well

[gramnani@girish cli]$ kubectl sadf
Error: unknown command "sadf" for "kubectl"
Run 'kubectl --help' for usage.

[danielhelfand]

@girishramnani Yes, I agree. That's what I was I trying to communicate with the following sentence in the issue:

An alternative that would allow the user to make the choice to see all of the information from --help would be to suggest to run --help with the command that was run.

Apologies, looking back on it, I could have written it more clearly.

I think a suggestion to use --help that is specific to the subcommand is what makes sense. It should be similar to kubectl as you have displayed above.

[danielhelfand]

With #292, the --help response (i.e. usage) will not display for error messages. What is needed to close this issue is a way to recommend to run --help for a command if an error occurs.

[tekton-robot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[tekton-robot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/close

Send feedback to tektoncd/plumbing.

[tekton-robot]

@tekton-robot: Closing this issue.

Details

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/close

Send feedback to tektoncd/plumbing.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.