Cargo output could go to stderr

[huonw]

Currently output generated by cargo itself goes to stdout, while rustcs goes to stderr. This is pretty annoying for a command cargo run, where the user controls stdout and may not appreciate the contamination from cargo, e.g. cargo run --bin foo > some_file.txt will include the Compiling ... and Running ... lines.

Alteratively, I suppose we could support cargo run --output some_file.txt --bin foo which will do the redirect internally.

[alexcrichton]

cc #653, a possible solution to the problem proposed there.

[alexcrichton]

It does seem odd, though, to print informational output to stderr. Do other CLI tools have a habit of doing this?

[jethrogb]

+1. I don't know about build et. al but the run output should really go to stderr, for the aforementioned reason of piping/redirecting output.

[kamalmarhubi]

Having trouble thinking of tools that run a subcommand and also print informative output.

A data point for a similar use Bazel always sends its informational output to stderr, for whether for run, build, test or otherwise. This is particularly useful for bazel run.

A historical aside, stderr was originally introduced to make pipelines nice, allowing separation of "diagnostic" output from the main output. Source: Unix Reader section on PIPE.

[mxork]

+1 for not contaminating stdout during a 'cargo run'

[kevincox]

Why does it seem strange to print diagnostic information to stderr? I generally think of stderr as the default place to print things, only using stdout for things that are actually output. This way shell piping works as expected.

Seeing as cargo output isn't supposed to be machine readable I would suggest putting all messages to stderr. This is especially useful when using cargo run as while cargo doesn't produce any "output" it is nice not to contaminate stdout in case the program you are running wants to use it for something.

[alexcrichton]

This seems like a reasonable feature to me to add! Especially if it helps out running small scripts here and there so much.

[matklad]

I've tried implementing this. Looks like the only code change is in this line. There are several calls to shell.say(), shell.out() and println! left which rightfully print to stdout.

However when status messages go to stderr, 200+ of tests fail :( Should I just change with_stdout assertions to with_stderr, or is there perhaps a more intelligent and future proof way of testing this?

[alexcrichton]

Yeah I had a feeling that this'd need a lot of updates to tests... We'd probably just want to update them to use with_stderr instead of with_stdout (as that's what we're testing)

[matklad]

Will try to send a PR later today :)

[w0rp]

Changing the output stream to stderr broke integration with ALE.

[w0rp]

Luckily, ALE can handle stderr, stdout, or both streams at the same time. ALE will have to accept both streams, because it could be either one, depending on the version of cargo.

[matklad]

Hm, the changed happened a rather long time ago, I would be surprised to find a lot of cargos which use stdout now....

[w0rp]

Yeah, I noticed that.

Strangely, I hadn't received any complaints until quite recently. That makes me wonder which versions of cargo people are actually using.

[matklad]

Hm, maybe then complaints are about some unrelated change to Cargo/Rustc output? It would be prudent to ask about the version of Cargo indeed!