Add a -q/quiet option #182

duglin · 2019-06-12T13:58:36Z

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?

The text was updated successfully, but these errors were encountered:

rhuss · 2019-06-12T14:21:59Z

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 · 2019-06-12T15:10:48Z

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 · 2019-06-12T22:08:28Z

👍 quiet option makes sense.

rhuss · 2019-06-14T06:16:18Z

/assign rhuss

duglin · 2019-09-10T18:17:51Z

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 · 2019-09-11T07:25:59Z

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.

duglin · 2019-09-11T14:39:03Z

only an error code to detect whether an operation is successful or not.

I'm not suggesting that. There should always be error messages. But in the case of the tool doing exactly what you asked, I don't see the point in saying "Hey, I did it!". Now, showing info, like the URL to which the service was deployed to is different because that's info you need to take the next step in your process. If look at standard unix-y tools like grep, tar, cc .... they will all just exit w/o "successful" messages. No news is good news :-)

re: detecting tty... I tend to be against that because then you get different output based on how something is run and I find that really hard to manage and deal with. E.g. I run something from cmd line and it works a certain way. I then run it via a script and I get totally different output and now need to go figure out which flags to set to get the same output. curl does this and I find it very annoying.

Such names are invalid in GCP, and they can be generated in a local environment with a prefix that has the right length (e.g., "build-pipeline").

github-actions · 2020-10-15T01:40:33Z