On Jan 28, 2008 11:17 AM, Steve Holden <[EMAIL PROTECTED]> wrote: > > 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. > > > While I couldn't locate such a document, it makes sense when you > consider that if such a process is part of a pipeline you really don't > want the prompts being handled as input by the downstream processes. > > That's why mv and similar utilities prompt on standard error. > > I'd be very surprised if you can find a UNIX or Linux shell, for > example, that prompts on standard output.
Ah, indeed. It looks like Python's prompt indeed gets written to stderr, at least when stdout is redirected to a file. Oddly, when stderr is redirected to a file, the prompt gets written to stdout. This seems backwards then (and not what the shells do -- when stderr isn't interactive, they don't write a prompt at all). But fixing it is delicate -- e.g. getpass very carefully makes sure to write to stdout, not stderr (and to avoid raw_input() and hence GNU readline). And cmd.py (used by pdb.py) also assumes the prompt should go to stdout when it is not using raw_input. I'm beginning to think that, despite the example of the shells, we'd be better off if Python *always* prompted to stdout (or not at all if that's not a tty). -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
