Printing confirmation of login information about up HOT 4 OPEN

it's not that you shouldn't print anything when not a TTY, just that things like confirmation and things like "do this next" do not make sense in the context of a script

Got it, yeah I was thinking about reporting back to user like universal-crossplane v1.2.1-up.3 is installed!. Agree that the long ones with instructions can be saved for TTY.

from up.

Very much agree that we can improve messaging for a number of commands, both on success and failure. I am working on a design for a framework for doing this so that we are consistent across all commands. Things that I think are important to support:

• Do not print confirmation (or any otherwise extraneous text) when not in a TTY (similar to how we refuse to prompt here)
• Add global flag for silencing all output
• Add global flag for forcing machine readable output -- for instance, I think it would be awesome if every command supported --json, making it such that the output of any command could be easily piped to utilities like jq for consumption

from up.

Add global flag for forcing machine readable output

Yes, I love kubectl's -o flag.

Do not print confirmation (or any otherwise extraneous text) when not in a TTY

Is there a particular reason to not print out of TTY? I think most tools I've used print no matter you're in TTY or not. Not printing usually exists in tools whose job is to print something, like cat or kubectl logs.

from up.

@muvaf it's not that you shouldn't print anything when not a TTY, just that things like confirmation and things like "do this next" do not make sense in the context of a script because:

1. Errors should be checked by exit code
2. If the command is in a script, there is no need to tell what to do next

Basically, if not a TTY, verbosity should be reduced. As an example, with up cloud login we might print something like "See what control planes exist in this account with up cloud xp list or attach you UXP cluster with `up cloud xp attach". These commands would be helpful to a user in an interactive setting, but would be noise in the context of a CI pipeline or similar. Here is some good guidance on when to print what.

from up.