Closed PhilippeChab closed 8 months ago
I don't really think anything should go to stderr, should all just be stdout. Otherwise it'll be very hard to decide what goes where..
Failures to load a file from the system and similar errors should be printed via stderr, I believe.
It's a minor issue, I don't have a hard opinion on the subject.
The long-standing tradition of sending log/human output to stderr is to support the common unix usecase of ./my_command > outfile
. When my_command errors out (exit code > 0), outfile will be empty. If the logs go to stdout, they'll instead end up in outfile AND the human operator won't even see them on the terminal.
Looks like GCC sends pretty much all output to stderr
- Compile errors and warnings, and even #pragma message "foo"
which is an info level print. I don't know what a good answer here is, so maybe we should just follow suite?
stderr is bit of a misnomer in that it's not just errors; that's in the POSIX standard as well as I understand it. The distinction here should be "user requested output" -> stdout vs "informational messages not part of the desired output" -> stderr.
Example: If the user requests to preprocess a file, the requested output is the preprocessed file content; and the info messages are all the warnings and pragmas.
Any further distinction would have to happen with explicit --pragmas-to FILE or something, I suppose.
stderr is bit of a misnomer in that it's not just errors; that's in the POSIX standard as well as I understand it. The distinction here should be "user requested output" -> stdout vs "informational messages not part of the desired output" -> stderr.
Example: If the user requests to preprocess a file, the requested output is the preprocessed file content; and the info messages are all the warnings and pragmas.
Thanks for the explication, it does make sense.
Any further distinction would have to happen with explicit --pragmas-to FILE or something, I suppose.
Feel free to close the issue, it is not a blocker on my side.
Description