I'd name it "standard log."

That's what it is....a log of errors, warnings, information messages, whatever to complement the primary output.

Yeah, naming is hard. If there is a better word for "non-output", I don't know it.

I would maybe call it stdlog or stdinfo vs stderr, but yeah naming things is hard.

C++ has std::clog[1], but it's basically cerr, and the OS still only knows about stdin, stdout, and stderr.

1: https://cplusplus.com/reference/iostream/clog/

I think stdinfo would exclude error messages from the definition, just like stderr excludes info messages.

I really like stdlog. Standard log stream is a pretty awesome name. Short and terse, the word "log" doesn't even need abbreviation and it's correct since it's a superset of error and info streams and also generic enough to cover other unforeseen categories.

I'll use it from now on!

The idea for info is that it's informational, which is always the case regardless of whether it's printing error messages due to a failure or informational messages because the user specified a `-v` flag or whatever. Whether the command failed or not is communicated via the exit code. That being said, I do prefer stdlog for the reasons: it communicates the intent and usage as unambiguously and tersely as possible.

> because the user specified a `-v` flag or whatever

The way I see it is the version information and help text belong on standard output if the user passes --version and --help since that's what the user explicitly asked for. When the command is invoked incorrectly, the help text should go to standard error while standard output should be empty.

I agree about the exit code. People like to parse error messages and that's always wrong. Everything should be done via exit codes instead.

The `-v` was in reference to the common convention of one or more `v` flags increasing the verbosity of logging.

What about "debug"? I think the important part about stderr is that it's "meta" info about how the program is running (or ran) rather than what the program is intended to produce as output. This seems pretty similar to what often is referred to as the "debug" level of logging (which includes lower levels of logging like warnings and errors).