inconsistent use of stderr and stdout

[Reed O'Brien]

TL;DR We are inconsistent in our use of stdout and stderr in command line interactions. We need to decide when we should use the different streams and be consistent in our implementation moving forward.

There is some work happening with Nate and interaction helper which could possibly be relevant. See:
 Interactive Commands in Juju: https://goo.gl/fEcLM6
 Interactive Add-Cloud: https://goo.gl/GNg0bG
 Interactive Bootstrap: https://goo.gl/n5aEE2

On http://reviews.vapour.ws/r/5222/ jam said:

Do we have precedence On other commands? It feels like messages to the user should go via stderr while messages to another script would be stdout. Best to be consistent, but stderr feels "more correct" here. If other commands use stdout, use it, but we should file a tech debt bug about it.

anastasiamac replied:

This is an interesting pickup.

I have done some codebase lookup recently for other work and found that we are not very consistent with our usage of Stdout. Although it is mostly used to provide user feedback, there are also instances where we provide errors on Stderr.

However, Stderr is used almost consistently to communicate errors (in our codebase).

I agree that we need to have a consensus and, if there is no tech debt card, it should be added.

I have been under impression that, in general, Stderr is a channel dedicated to errors \o/

And redir pondered:

TL;DR destroy contoller does the same in cmd/juju/controller/destroy.go:368 which is what I modelled this confirmation dialog on.

Current uses of stdout/stderr in cmd/*

$ grep -r "fmt.Fprintf(ctx.Stdout" .
shows a number of useres of stdout the same with stderr. Both also mix returning errors and returning values.

Ponderance on the purposes of stdout/stderr.

stdout is an abstraction for sending output to a file, pipe, or to a console. On nix-alikes, AFAIU unless stdout is redirected, stdout is the console that initiated the command (likewise with stderr). stderr is an abstraction that was born of the need/desire to send diagnostics (errors). So it makes sense to me that we would communicate with the user on stdout and send errors/diagnostics to stderr.

As an example, if I grep for foo in root... contrived example:

$ grep -r foo /
/bar: foo: 42
grep /foo: permission denied
/baz: foo: 97

And wanted to extract the info with awk, I don't want to pass the grep error into awk. Naked output looks like:

$ grep -r foo / | awk '{print $2}'
42
grep /foo: permission denied
97

I can remove the diagnostics by redirecting stederr:

$ grep -r foo / 2> /dev/null| awk '{print $2}'
42
97

But if diagnostics weren't seperate I'd see:

$ grep -r foo / | awk '{print $2}'
42
/foo:
97

and my easy win would be a PITA.

So stderr made pipelines awesome and easy by creating another stream for errors/diagnostics. A side effect occured because any program in a pipeline could send errors to stderr. So a need for commands to identify themselves arose, giving birth to syslog ident.

As a user I'd want to be able to parse output from juju commands by piping to other commands without having to manually separate output from errors/diagnostics. Anyhow that is some stream of consiousness regarding how I interpret stderr and stdout.

[Anastasia (anastasia-macmood)]

As this is a tech-debt item, I am lowering its Importance.

[Canonical Juju QA Bot (juju-qa-bot)]

This bug has not been updated in 2 years, so we're marking it Low importance. If you believe this is incorrect, please update the importance.