4 ms·

So, did stderr outlive its purpose?

by avmich 13y ago

forkandwait 13y ago
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.
cpeterso 13y ago
A disadvantage of separate stdout and stderr streams is matching of errors to the corresponding resulting output.
- jewel 13y ago
  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: command 2>&1
  - bazzargh 13y ago
    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)
- fit2rule 13y ago
  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.
bjourne 13y ago
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.
- yuhong 13y ago
  But sometime it is obvious. For example, when binary output is being spewed to stdout.
  - DSpinellis 13y ago
    There is nothing wrong with sending binary (non-textual) output to stdout. Many programs, like the netpbm utilities, work like this.
    - codeflo 13y ago
      That's what yuhong meant, I think. If your stdout output is binary, it's clear that all user-readable messages should go to stderr.
  - bjourne 13y ago
    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".
- jzwinck 13y ago
  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. [1] http://www.gnu.org/prep/standards/standards.html#Command_002dLine-Interfaces http://www.gnu.org/prep/standards/standards.html#Command_002...

So, did stderr outlive its purpose?

by avmich 13y ago

So, did stderr outlive its purpose?

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.

cpeterso 13y ago

A disadvantage of separate stdout and stderr streams is matching of errors to the corresponding resulting output.

jewel 13y ago
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: command 2>&1
- bazzargh 13y ago
  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)
fit2rule 13y ago
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.

bjourne 13y ago

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.

yuhong 13y ago
But sometime it is obvious. For example, when binary output is being spewed to stdout.
- DSpinellis 13y ago
  There is nothing wrong with sending binary (non-textual) output to stdout. Many programs, like the netpbm utilities, work like this.
  - codeflo 13y ago
    That's what yuhong meant, I think. If your stdout output is binary, it's clear that all user-readable messages should go to stderr.
- bjourne 13y ago
  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".
jzwinck 13y ago
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. [1] http://www.gnu.org/prep/standards/standards.html#Command_002dLine-Interfaces http://www.gnu.org/prep/standards/standards.html#Command_002...