Unknown plugins or commands do not show help and correct message to user

[maximilien]

In what area(s)?

Kn plugins

Classifications:

/kind good-first-issue

What version of Knative Client?

Version: v20190726-local-59b2855-dirty
Build Date: 2019-07-26 21:07:51
Git Revision: 59b2855
Dependencies:

• serving: v0.6.0

What version of Knative Serving running on your cluster?

0.6.x

Expected Behavior

./kn lol
Manage your Knative building blocks:

* Serving: Manage your services and release new software to them.
* Eventing: Manage event subscriptions and channels. Connect up event sources.

[...]

Use "kn [command] --help" for more information about a command.

Could not find plugin to execute
unknown command "lol" for "kn"

Actual Behavior

./kn lol
Could not find plugin to execute

Steps to Reproduce the Problem

./kn lol # assuming no plugins named kn-lol

[maximilien]

/assign @maximilien

[rhuss]

Can't we do it just like kubectl, i.e.

$ kubectl bla
Error: unknown command "bla" for "kubectl"
Run 'kubectl --help' for usage.
unknown command "bla" for "kubectl"

I like that because:

• Not the full help is shown but an indication howto get help
• That it does not tell 'can't find plugin' but 'unknown command'. Plugins are implementation details and should not unnecessarily leak to the command line. At the end the plugin is treated as a command. And what if the user just misspelled the command like in kn services list ? That's equally likely as referring to an uninstalled plugin (if not more, e.g. when reverting noun and verb, or using "get" because of kubectl brainwash)
• It's consequent as for misspelled subcommands you get that 'command not found' message, too in kn (but could be also a missing plugin).

I'm totally for not exposing plugins at that spot.

[maximilien]

As you know, I was always for being most compatible with kubectl.

However, that does not agree with what we have already agreed on which is to show the help then unknown command “blah” for kn. We sort of have to be consistent with #218.

[rhuss]

However, that does not agree with what we have already agreed on which is to show the help then unknown command “blah” for kn. We sort of have to be consistent with #218.

My main point is it should be only 'unknown command', and not 'plugin not found'. And not sure why we have to be "consistent" with #218 and not showing the full help at the very beginning would equally well (maybe even better) fix #111

[maximilien]

My main point is it should be only 'unknown command', and not 'plugin not found'

Well that's debatable. Since you could assume that now with plugin, someone issuing: kn tkn pipeline ... is looking for a plugin called tkn or a command called tkn.

Same thing for any word after kn and down the various branches. With #218 which solved #111 we got a consistent way of dealing with unknown commands: show help, then unknown command "<word>" for "kn".

I'd agree with the following compromise:

➜  client git:(issue308) kn blah
Manage your Knative building blocks:

* Serving: Manage your services and release new software to them.
* Eventing: Manage event subscriptions and channels. Connect up event sources.

Usage:
  kn [command]
...
unknown command or plugin "blah" for "kn"

for any unsown invocation of kn. Invocation of unknown subcommands would follow as it is now: help text for group and unknown message.

Thoughts? If you are OK I'll update PR, otherwise, let's ask others to chime in. Thx

[rhuss]

I'm fine with that compromise (though a plugin is-a 'command' in a sense and for a user, it shouldn't make a difference whether a functionality is provided by a built-in command or a plugin command. But it's a compromise, so that was my last bullet ;-)

If hiding the full help text it that point is only a technical limitation I'm happy to have a look (haven't followed or forgot the discussion ;-). if this was a community agreement, I'm also fine with showing the full help text when a command is mistyped.

[maximilien]

No hiding is not a limitation. It’s a choice we did in #218. Feel free to suggest an alternative. I like it since it helps the user. If our help was multiple pages long then I would agree with you, for now, we live in a wonderful less than a page help with kn -h so life is good :)