Definitely not. One can tell a naive, non-Unix programmer by the fact that they write code that pollutes the output of a command line utility with informational/ error garbage. (And it almost goes without saying that much real work still happens on the command line.)
Regarding the OP comment about not being able to tell correspondence between a given output and an error: That is an interesting point, but generally in the Unix command line idiom, one stops the program on the first error, so it is easy to tell. However, if you have process that can't stop (like a server), then one has to be more careful and should probably use a more general logging system.
When this is important, you can make it so that stdout and stderr are the same stream, via a variety of methods. With bash this is done with 2>&1, as in:
While that makes them the same stream, it doesn't actually solve the problem. Many systems will write to stdout buffered, but stderr unbuffered, so that writes are visible when the program crashes. Redirecting streams at the shell level doesn't stop application level buffering ruining your day.
Having said that, GP's request is pretty niche, it's only useful when the program uses stdout (not a gui, web etc) and is doing work that might write to stderr while it's writing to stdout (so no summary report generators, long running physics simulations etc)
Not if your logmsg() function prepends a timestamp to each message. Then its just a matter of glomming the output FD's, piping through sort, and .. problem solved.
Stderr is nice in theory. In practice, it is really hard to consistently decide which types of output should go on stdout and which should go on stderr. Different developers (all experienced unixians) have different ideas on when stderr should be used instead of stdout. For example should stderr be used for --help, --version or when invalid arguments are passed to a program?
Then there's the problem with granularity. An output for a long running program could be purely informative, minor warning, major warning, minor error, critical error or some other category. Putting all those outputs on stderr doesn't simplify anything for a script that would still need to parse the output and determine what to do with it.
There is no such difficulty. I give you the GNU Coding Standards section on Command-Line Interfaces.[1] It will inform you of what you should do on any Linux/Unix system: --help and --version both go to stdout, never stderr, because it is not an error to do what the user requested, successfully. Any program which prints to stderr on either of these options, and/or returns a failure code, deserves a patch.
Someone will come and say this is all well and good for GNU but what if we aren't using GNU? The answer is the same, because at least in this case the GNU conventions are sane and consistently applicable to virtually all command-line programs.
When invalid arguments are passed to a program, of course it should print to stderr, and exit unless it can do something smarter or prefers to ignore the options (most programs wouldn't).
The issue of severities has no bearing on stdout vs. stderr. If you have a syslog-like severity system, all those messages can go to the same stream (probably a file or the network, but it could be stderr).
Before anyone says things should be done another way, please point us to some examples of popular programs that do not abide by the above on a Linux/Unix system. Most do, and all should, and it's not so difficult.
Yeah, but that breaks the rule that standard error is for error messages. You're then repurposing stdout and stderr to "standard binary output" and "standard various text messages output".
