On Jan 28, 2008 11:17 AM, Steve Holden <steve at holdenweb.com> 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4