By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,306 Members | 1,657 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,306 IT Pros & Developers. It's quick & easy.

raw_input(), STRANGE behaviour

P: n/a
I ran into a very strange behaviour of raw_input().
I hope somebody can tell me how to fix this.
(Or is this a problem in the python source?)

I will explain the problem by using 3 examples. (Sorry, long email)
The first two examples are behaving normal, the thirth is
strange.......

I wrote the following flabbergasting code:
#-------------------------------------------------------------
print "1: This is the print statement."

# Now halt the program until someone hits enter
raw_input("2: This is the raw_input prompt.")

import sys
print "3: This is a possible solution. ",
sys.stdout.flush()
command = sys.stdin.readline()
#-------------------------------------------------------------
and saved it in the file 'script.py'.

*** First, normal behaviour to stdout
Now, I open a command line and run the following command:
python script.py

On screen appears, after a few 'enter' keys:
1: This is the print statement.
2: This is the raw_input prompt.
3: This is a possible solution.
All works fine......

*** Second, redirected stdout to file, normal behaviour.
From the command prompt I run:
python script.py stdout_catch.txt
The screen stays empty, and after a few 'enter' keys the prompt
reapears.

In the file 'stdout_catch.txt' are the lines:
1: This is the print statement.
2: This is the raw_input prompt.
3: This is a possible solution.
And again, all works fine......

*** Thirst, redirect stderr to file, STRANGE behaviour......
From the command prompt I run:
python script.py 2stderr_catch.txt
This should redirect strerr to the file and stdout should stay on the
screen.

But..... What happens?
After a few 'enter' keys, on screen apears:
1: This is the print statement.
3: This is a possible solution.

WHERE IS THE SECOND LINE?
It is in the file stderr_catch.txt!!!

**** See the problem?
Please Tell me? Why is the prompt produced by raw_input() printed to
the error channel? It should be stdout, just as the print statement
does.

Looking at the python source code on
http://svn.python.org/view/python/ta...4864&view=auto
[found: 'builtin_raw_input(PyObject *self, PyObject *args)'].

One thing that I notice is that the code checks whether stdin and
stdout are connected to a terminal ("isatty" function), but I do not
know why the prompt ends up on stderr then.....

**** What is the solution?
I have noticed this behaviour under DOS in Windows XP, Windows 2000,
Windows 2003 Server, Windows vista, and Linux. How do I get
raw_input() to send it's prompt to stdout?

Friendly greetings

Rens
Jan 26 '08 #1
Share this Question
Share on Google+
8 Replies


P: n/a
On Jan 26, 7:23 am, Dox33 <Rens.Duijs...@gmail.comwrote:
I ran into a very strange behaviour of raw_input().
I hope somebody can tell me how to fix this.
===CUT===
*** Thirst, redirect stderr to file, STRANGE behaviour......
From the command prompt I run:
python script.py 2stderr_catch.txt
This should redirect strerr to the file and stdout should stay on the
screen.

But..... What happens?
After a few 'enter' keys, on screen apears:
1: This is the print statement.
3: This is a possible solution.

WHERE IS THE SECOND LINE?
It is in the file stderr_catch.txt!!!

**** See the problem?
Please Tell me? Why is the prompt produced by raw_input() printed to
the error channel? It should be stdout, just as the print statement
does.
I recently ran into this behaviour myself, and reported it both here
and to the python-dev mailing list. See
http://groups.google.com/group/comp....8b7c47873a4a1e

It turns out that *if* you don't have GNU readline installed, Python
falls back to its own implementation of readline, which is hard-coded
to send the prompt output to stderr. Guido agreed that this is wrong,
and a bug for it has been entered into the Python bug tracking
database.

Your workaround until this bug is fixed is to install GNU readline,
and rebuild your python installation to use it rather than the fall-
back version.
Jan 26 '08 #2

P: n/a
Hello Mike,

Thanks for your reply.
Since I momentarily do not have the ability to build a new python
executable, I would like to ask for your help in this case.
Are you able to supply me with a corrected version?

Friendly greetings

Rens Duijsens

On 26 jan, 16:50, Mike Kent <mrmak...@cox.netwrote:
On Jan 26, 7:23 am, Dox33 <Rens.Duijs...@gmail.comwrote:


I ran into a very strange behaviour of raw_input().
I hope somebody can tell me how to fix this.
===CUT===
*** Thirst, redirect stderr to file, STRANGE behaviour......
From the command prompt I run:
python script.py 2stderr_catch.txt
This should redirect strerr to the file and stdout should stay on the
screen.
But..... What happens?
After a few 'enter' keys, on screen apears:
1: This is the print statement.
3: This is a possible solution.
WHERE IS THE SECOND LINE?
It is in the file stderr_catch.txt!!!
**** See the problem?
Please Tell me? Why is the prompt produced by raw_input() printed to
the error channel? It should be stdout, just as the print statement
does.

I recently ran into this behaviour myself, and reported it both here
and to the python-dev mailing list. *Seehttp://groups.google.com/group/comp.lang.python/browse_thread/thread/...

It turns out that *if* you don't have GNU readline installed, Python
falls back to its own implementation of readline, which is hard-coded
to send the prompt output to stderr. *Guido agreed that this is wrong,
and a bug for it has been entered into the Python bug tracking
database.

Your workaround until this bug is fixed is to install GNU readline,
and rebuild your python installation to use it rather than the fall-
back version.- Tekst uit oorspronkelijk bericht niet weergeven -

- Tekst uit oorspronkelijk bericht weergeven -
Jan 27 '08 #3

P: n/a
I believe a workaround to the bug of raw_input sending the prompt to stderr
is
print 'prompt:',
a = raw_input()

Not nice, but possibly better that waiting for a corrected binary.


Jan 27 '08 #4

P: n/a
Dox33 <Re***********@gmail.comwrites:
Thanks for your reply. Since I momentarily do not have the ability
to build a new python executable, I would like to ask for your help
in this case. Are you able to supply me with a corrected version?
You can simply choose not to use raw_input, and use sys.stdin.readline
instead. Or define your own corrected raw_input:

def my_raw_input(msg):
print msg,
return raw_input()
Jan 27 '08 #5

P: n/a
Yes, I know.
There are several ways to work around the problem.
(Look at the innitial code I provided in this discussion start)
Fact is, every time I'm getting a script from somewhere or someone, I
have to search and replace all the affected code.
Not very conveniant.
That's why I rather would have a correct working version.

On 27 jan, 04:20, Hrvoje Niksic <hnik...@xemacs.orgwrote:
Dox33 <Rens.Duijs...@gmail.comwrites:
Thanks for your reply. *Since I momentarily do not have the ability
to build a new python executable, I would like to ask for your help
in this case. *Are you able to supply me with a corrected version?

You can simply choose not to use raw_input, and use sys.stdin.readline
instead. *Or define your own corrected raw_input:

def my_raw_input(msg):
* * print msg,
* * return raw_input()
Jan 27 '08 #6

P: n/a
En Sun, 27 Jan 2008 12:51:51 -0200, Dox33 <Re***********@gmail.com>
escribi�:
Yes, I know.
There are several ways to work around the problem.
(Look at the innitial code I provided in this discussion start)
Fact is, every time I'm getting a script from somewhere or someone, I
have to search and replace all the affected code.
Not very conveniant.
That's why I rather would have a correct working version.
Add this on your sitecustomize.py module (or create one)

import sys

def raw_input(prompt=None):
if prompt: sys.stdout.write(prompt)
return original_raw_input()

import __builtin__
original_raw_input = __builtin__.raw_input
__builtin__.raw_input = raw_input

It just replaces the builtin raw_input with a custom function.

--
Gabriel Genellina

Jan 27 '08 #7

P: n/a
On Sat, 26 Jan 2008 04:23:36 -0800 (PST), Dox33
<Re***********@gmail.comwrote:

<snip>
>WHERE IS THE SECOND LINE?
It is in the file stderr_catch.txt!!!

**** See the problem?
Please Tell me? Why is the prompt produced by raw_input() printed to
the error channel? It should be stdout, just as the print statement
does.
Isn't this the norm in Unix shells also? In bash the "read" command
prints the prompt on stderr and the "select" command prints both the
menu and prompt on stderr.

sb
Jan 28 '08 #8

P: n/a
YES!
This is what I was looking for.
Great! All works fine now.

Thank you very much Gabriel.

Gabriel Genellina schreef:
Add this on your sitecustomize.py module (or create one)

import sys
def raw_input(prompt=None):
if prompt: sys.stdout.write(prompt)
return original_raw_input()

import __builtin__
original_raw_input = __builtin__.raw_input
__builtin__.raw_input = raw_input

It just replaces the builtin raw_input with a custom function.
Jan 28 '08 #9

This discussion thread is closed

Replies have been disabled for this discussion.