[Python-Dev] Incorrect documentation of the raw_input built-in function

[Jeroen Ruigrok van der Werven]

-On [20080128 18:57], Guido van Rossum (guido at python.org) wrote:
>On Jan 28, 2008 12:35 AM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>> So it appears that the official Unix Way prefers using stderr
>> over stdout for prompting, if using the std files for it at all.
>
>That's a dangerous generalization from just one example. I'd prefer it
>if you could unearth some POSIX or Linux base document saying this.

I cannot find anything explicitly in favour of or against this in POSIX. The
stuff quoted below is what I could find. I do not think there's a hard
mandate either way, but from my experience of having been a committer for
both FreeBSD and DragonFly BSD for a number of years stderr was not
preferred for prompting. stderr was always the domain of diagnostics.

"3.105 Command Language Interpreter

 An interface that interprets sequences of text input as commands. It may
 operate on an input stream or it may interactively prompt and read commands
 from a terminal. It is possible for applications to invoke utilities
 through a number of interfaces, which are collectively considered to act as
 command interpreters."

POSIX defines per utility what stdin, stdout and stderr do. The default
definition for these is:

STDIN

There is no additional rationale provided for this section.

STDOUT

The format description is intended to be sufficiently rigorous to allow
post-processing of output by other programs, particularly by an awk or lex
parser.

STDERR

This section does not describe error messages that refer to incorrect
operation of the utility. Consider a utility that processes program source
code as its input. This section is used to describe messages produced by a
correctly operating utility that encounters an error in the program source
code on which it is processing. However, a message indicating that the
utility had insufficient memory in which to operate would not be described.

Some utilities have traditionally produced warning messages without
returning a non-zero exit status; these are specifically noted in their
sections. Other utilities shall not write to standard error if they complete
successfully, unless the implementation provides some sort of extension to
increase the verbosity or debugging level.

The format descriptions are intended to be sufficiently rigorous to allow
post-processing of output by other programs.

-- 
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/
We have met the enemy and they are ours...