-
Notifications
You must be signed in to change notification settings - Fork 261
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a -q/quiet option #182
Comments
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:
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). |
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 |
👍 quiet option makes sense. |
/assign rhuss |
Per our call today, some additional thoughts and things I've seen. Using
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 |
I still believe that the default assumption should be that So I still in strong favour to add Having a similar level of verbosity like other tools as 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. |
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. |
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").
This issue is stale because it has been open for 90 days with no |
/remove-lifecycle stale |
This issue is stale because it has been open for 90 days with no |
/remove-lifecycle stale |
This issue is stale because it has been open for 90 days with no |
/remove-lifecycle stale |
This issue is stale because it has been open for 90 days with no |
/remove-lifecycle stale |
This issue is stale because it has been open for 90 days with no |
/remove-lifecycle stale |
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: