Feature request: Our Keil C166 compiler does not make a distinction between standard output or standard error. It would be nice if error/warning messages would be displayed on standard error. This make it easier to redirect output, handle logging in our build environment, etc. Seems like a simple file descriptor adjustment and existing users/tools won't notice the difference.
I'm not sure if the latest version (6.x) supports this already.
Kind rergards, Joost Leeuwesteijn
If nobody would notice the difference, what could possibly be the point of changing the behaviour?
And honestly, I can't figure out how redirecting stderr could ever be easier than redirecting stdout. Or, for that matter, redirecting stdout directly to stderr, if that's what you want to do:
c166 [...arguments...] 1>&2
But surely, as far as the compiler is concerned, compilation messages (warnings, errors, etc) are its standard output - so they should go to stdout?!
If anything should go to stderr, it would be messages about failures of the compiler itself?
What do native UNIX compilers do?
gcc - and a lot of other compilers - emits the errors to stderr.
A redirect of standard out will just get the normal output from the make process.
Then at least compilation errors are failures of the compiler itself, it can't handle the source file. But I understand what you mean. What kind of failures do you mean exactly?
I believe most UNIX tools send their error messages ("file not found", etc.) to stderr, not just their internal errors or core dumps. I expected the Keil compiler to behave the same way. I redirected the compiler startup messages etc. (stdout) but I expected to still see the warnings/error but that doesn't happen.
Quick test on Windows (cmd.exe):
C:\> dir burp > log.txt File Not Found C:\> _
So "dir" also sends errors to stderr.
(Thanks Perg for the gcc answer.)
Regards, Joost Leeuwesteijn
I was only trying to predict the impact on current users. There's no change in behaviour for them. But now I realize I was wrong about that. When people currently redirect only stdout, it would go wrong when the compiler would make use of stderr.
And honestly, I can't figure out how redirecting stderr could ever be easier than redirecting stdout. Or, for that matter, redirecting stdout directly to stderr, if that's what you want to do: c166 [...arguments...] 1>&2
My point was that the Keil compiler does not even use stderr (as far as I know). But there are cases when making a distinction between stdout and stderr can be useful. In our case, we're not interested in the normal output, only in the warnings/errors. But at the moment there's no way to redirect only one of them, unlike alot of other compilers/tools.
My opinion is that compilation errors and warnings are the normal output of a compiler, so they should go to stdout. stderr would be appropriate for internal compiler problems, like running out of RAM.
If you do a huge compilation with houndreds or thousands of source files, you might actually like a compiler that sends warnings and errors to stderr, allowing you to just use redirect to separate the warnings/errors from the normal build noise.
When using c++ with templates, a lot of warnings/errors messages may be several lines long, making it hard to just use grep to pick out interesting warnings.