Data that can be used for further processing \('pipe'\) should be sent to stdout. All messages that are only relevant for the user should be sent to stderr. Errors should not be detected by checking if anything was written to stderr, but by checking the return value \(which will be non-zero if an error occurred\).

Basically, this is a well-known cron problem. See, for instance, http://habilis.net/cronic/

I disagree. Non-zero return value is for errors from which the application could not recover. There might be errors or unexpected important events which do not cause the bot to fail but should be reported nevertheless. \(For example if an interwikibot gets a talk page message on one of the many wikis it visits, that should be reported, maybe the bot should stop working on that wiki until the owner can check the message, but it certainly should not stop working on all other wikis.\)

If you want to show human-readable output to humans, and machine-processable output to scripts, the proper solution for that is to detect \(via sys.stdout.isatty\(\)\) whether you are writing to a terminal, and format accordingly \(and allow overriding the behavior via a command line switch\). That is how sophisticated command line applications usually operate; compare, for example, the output from 'ls' and 'ls | cat'.

> /dev/null was invented to suppress screen output. To prevent scripts of using this option is a misuse. Even if the script is not run from cron, operator may wish not to see messages and his screen scrolled.

I think it would be good since jsub tasks in labs save output in two different files. one .out and one .err

There are three types of messages (more or less):

• errors
• normal output (status)
• data

Currently it's the the first two are going to stderr while the last is going to stdout. The problem is now, someone who wants to gets data wouldn't want this to be changed. We have three streams (if we don't count warnings) but only two targets. Instead of printing more to stdout I think it should be possible to redirect where the logs are going. So that someone could say that messages with 'error' level are going to stderr, and the rest to stdout. Then it's in the hand of the script to use a sensible output level and not always use pywikibot.output to output anything.