[Python-Dev] Incorrect documentation of the raw_input built-in function (original) (raw)

Jeroen Ruigrok van der Werven asmodai at in-nomine.org
Mon Jan 28 19:50:16 CET 2008

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

More information about the Python-Dev mailing list