I think the correct thing is to print them all to stdout.

The current behavior is intentional. The pragma comments are additional bits to inform humans. Shouldn't the machines always consume the stderr?

Stderr was invented to convey messages to humans, not machines. The machine-readable output should be sent to stdout so that it can be easily piped into another program or file.

In this case, if I'm running go build -n I expect the output to be a series of shell commands. Any errors that occur in producing that output should be sent to stderr.

Sorry, s/stderr/stdout.

The use of two different streams is intentional and you can always 2>&1. I don't think there is anything wrong with the current behavior.

The commands are printed to stderr. I think they should be printed to stdout. The pragmas can also be printed to stdout as they are just shell comments.

gomobile prints commands and comments both to stderr. Regardless of what the final decision, at least, we need to be consistent and apply the same convention to gomobile.

(FWIW, the only justification to write to stderr might be able to diff between -v vs -n and -v vs -x prints. I don't have background about the current behavior and would like to have more context. -n is used to test the tools and I don't think the informative comments are a necessity there and they are written to stdout just like the other verbose output.)

I'm not sure if we have made a policy decision about stdout/stderr, but if
not I am happy to make one. I'll investigate.

On 13 October 2015 at 16:38, rakyll notifications@github.com wrote:

gomobile prints commands and comments both to stderr. Regardless of what
the final decision, at least, we need to be consistent and apply the same
convention to gomobile.

(FWIW, the only justification to write to stderr might be able to diff
between -v vs -n and -v vs -x prints. I don't have background about the
current behavior and would like to have more context. -n is used to test
the tools and I don't think the informative comments are a necessity there
and they are written to stdout just like the other verbose output.)

—
Reply to this email directly or view it on GitHub
#12913 (comment).

I don't really have a strong opinion on whether the -n output should go to stdout or stderr. I'd err on the side of stdout. But I do agree with the issue reporter that the output should be sent to one or the other, and not both (interleaved).

Can @rsc advise?

It is in no way intentional that the output is split between stdout and stderr.

Originally it was all to stdout. CL 7393073 moved the bulk of the output to stderr. The # block print was missed. The fix is to change

fmt.Printf("\n#\n# %s\n#\n\n", a.p.ImportPath)

to use b.print like everything else. Thanks.

CL https://golang.org/cl/16737 mentions this issue.