POSIX defines standard error as
for writing diagnostic output
This doesn’t limit its use to error messages only. I would consider progress information as diagnostic output, so it belongs on standard error.
Posix defines the standard streams thus:
At program start-up, three streams shall be predefined and need not be opened explicitly: standard input (for reading conventional input), standard output (for writing conventional output), and standard error (for writing diagnostic output). When opened, the standard error stream is not fully buffered; the standard input and standard output streams are fully buffered if and only if the stream can be determined not to refer to an interactive device.
The GNU C Library describes the standard streams similarly:
Variable: FILE * stdout
The standard output stream, which is used for normal output from the program.
Variable: FILE * stderr
The standard error stream, which is used for error messages and diagnostics issued by the program.
Thus, standard definitions have little guidance for stream usage beyond “conventional/normal output” and “diagnostic/error output.” In practice, it’s common to redirect either or both of these streams to files and pipelines, where progress indicators will be a problem. Some systems even monitor
stderr for output and consider it a sign of problems. Purely auxiliary progress information is therefore problematic on either stream.
Instead of sending progress indicators unconditionally to either standard stream, it’s important to recognize that progress output is only appropriate for interactive streams. With that in mind, I recommend writing progress counters only after checking whether the stream is interactive (e.g., with
isatty()) or when explicitly enabled by a command-line option. That’s especially important for progress meters that rely on terminal update behavior to make sense, like %-complete bars.
For certain very simple progress messages (“Starting X” … “Done with X”) it’s more reasonable to include the output even for non-interactive streams. In that case, consider how users might interact with the streams, like searching with
grep or paging with
less or monitoring with
tail -f. If it makes sense to see the progress messages in those contexts, they will be much easier to consume from
POSIX is slightly more concrete about “diagnostic information” in Shell and Utilities, 1.4: Utility Description Defaults (emphasis mine):
The STDERR section describes the standard error output of the utility.
Only those messages that are purposely sent by the utility are
described. Use of a terminal for standard error may cause any of the
standard utilities that write standard error output to stop when used
in the background. For this reason, applications should not use
interactive features in scripts to be placed in the background.
The format of diagnostic messages for most utilities is unspecified,
but the language and cultural conventions of diagnostic and
informative messages whose format is unspecified by this volume of
POSIX.1-2008 should be affected by the setting of LC_MESSAGES and
[XSI] [Option Start] NLSPATH. [Option End]
The specified standard error output of standard utilities shall not
depend on the existence or value of the environment variables defined
in this volume of POSIX.1-2008, except as provided by this volume of
Default Behavior: When this section is listed as “The standard error shall be used only for diagnostic messages.”, it means that,
unless otherwise stated, the diagnostic messages shall be sent to
the standard error only when the exit status indicates that an error
occurred and the utility is used as described by this volume of
When this section is listed as “Not used.”, it means that the standard
error shall not be used when the utility is used as described in this
volume of POSIX.1-2008.
IANASL, but I interpret that to mean that stderr will have output only if the utility will return an error exit code. Since this should not be the normal course of events for successful execution, no progress information should be printed by a POSIX utility unless an error occurs (unless, of course, otherwise specified, etc.).