Add a -q/quiet option

[duglin]

While the current model of printing a "success" message can be useful for newbies, I actually think it kind of odd since IMO most Linux commands tend to be silent unless there are error - or there's really important info you need to get your next job done. But things like creating a service really shouldn't need any output when things work. I tend to think that messages like this are handy the first couple of times you run a command (as I said, for newbies), then after that it gets annoying because I've been conditioned to learn that "no output means things worked" and anything else is something I need to look at because odds are it means there are error messages. Remember, most people don't do echo $? after they run a command to see the exit code, so asking them to scan the output for an error message is (IMO) asking a lot when people are flying thru their commands to get a job done.

However, I'm not going to suggest we drop those messages (yet, even though I do think it would be better to do so :-) ). For now, I'd be ok with just adding a -q/quiet type of flag so that I can hide this verbosity. An env var would be nice too so I can set it once and forget about it.

What do people think?

[rhuss]

I'm happy to support a quiet mode, it's a perfectly valid use case. However, I think there is valuable information which can be printed out, too, which goes beyond a pure success:

• The URL how a service is reachable (coming with feat(service create): Wait for a service to be ready when its created #156) so you save an extra call for looking this up
• The service name (or its 'id') used when after the service is created (you know that discussion ;). Not sure whether this comes, though.

So I'm all for supporting both: Using a human-friendly message for interactive CLI usage and a silent usage for script (but even then it might be useful e.g. when running in a CI environment).

[duglin]

I do agree that showing the URL is more useful than "it worked!" :-) but even then, given a choice I'd still prefer to have no output because the URL should be a well-defined/calculated value and have people ask for the URL via a flag if they want it. But that's just me. A -q for now is ok with me.

[maximilien]

👍 quiet option makes sense.

[rhuss]

/assign rhuss

[duglin]

Per our call today, some additional thoughts and things I've seen. Using tar as the example linux app:

$ tar -cf a.tar *   # will show no output because it worked

$ tar -vcf a.tar *   # will show list of files processed due to -v option, these go to stdout
file1
file2

And this makes sense to me because 1) there's no error, so nothing on stderr, and 2) the user asked for additional output, so it goes to stdout.

Now, there might be other flags (like --debug type of flags) that generate output and I do actually think it makes sense for that to go to stderr so they don't disrupt your normal workflow. I think "warnings" fit into that category but I'm not sure, I'm having trouble finding a good standard linux cmd that printing warnings.

[rhuss]

I still believe that the default assumption should be that kn is used as an interactive tool, so having by default success and error messages for e.g. kn service create is much more user-friendly than having only an error code to detect whether an operation is successful or not.

So I still in strong favour to add -q for the scripting use case (like eg. for grep).

Having a similar level of verbosity like other tools as docker and kubectl that play in the same arena also helps.

Another option would be to detect whether running with a tty or not and then decide on the level of verbosity, but that has the 'magic switch' disadvantage.