On Thu, May 09, 2002 at 09:41:07AM -0400, Bill Mills-Curran wrote:

I can't believe I'm revisiting this yet again... I'm struggling with identifying "standard practice" for deciding when to write to stdout v. stderr. In particular, I'm working with processes associated with software maintenance (building, copying, SCM, etc.). I'd love to find a definitive whitepaper on the subject. Does anyone have any

Bill - I don't think I've ever seen a whitepaper addressing this particular subject, but the standard practice is very easy to identify. I have a very straightforward approach to this issue. 1. For all Unix commands - say nothing unless the command fails or encounters an error condition. All error messages go to stderr. 2. For all filters (programs which produce output on stdout) only the normal program output goes to stdout. Many normal Unix commands can be used as filters. Like "ls" for example. All error messages go to stderr. 3. Any debugging info activated by command line options or environment variables should go to stderr. For tools used in building software, like "make" emulate make's behavior which follows rule 1 above. Commands executed by make are echoed to stdout and all diagnostic info is directed to stderr. If you invoke the following makefile with the command "make 1>/dev/null" you will see only the diagnostic output. Invoked by just "makefile" gives you both. ###### Makefile starts here. all: boo foo boo: echo "stdout OUTPUT" > /dev/null foo: glarf STDERR ONLY nadba ############# makefile ends here.