Bash – Redirect stderr of the double-parentheses construct

When I'm writing shell scripts myself I often find it hard to decide what output and which messages I should present on stderr, or if I should bother at all.

Silence is golden. Output nothing if everything is fine.

I'd like to know about good practice: When is redirecting some message to stderr called for and reasonable, and when not?

The easiest way to separate stderr from stdout : just imagine all your scripts output will be redirected to another command via pipe. In that case you should keep all notifications in stderr, as such unexpected information in stdout may break the pipe sequence.

Also sometimes in pipes like this one:

command1 | while read line ; do command2 ; done | command3

you need pass something from command2 to users output. The easiest way without temporary files is stderr.

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 stdout.