Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > blocking read on stdin on Windows?

Reply
Thread Tools

blocking read on stdin on Windows?

 
 
Jeff Learman
Guest
Posts: n/a
 
      09-04-2004

I want to do a very simple thing in Windows. (Using Python Shell.)

I want to write a prompt to sys.stdout and read the user input.
(Ideally, without waiting for a newline.)

Here are the problems I'm encountering. Newbie problems, no doubt.

sys.stdin.read() gives me an attribute error
sys.stdin.readline() doesn't block waiting for input. And even
if it did, it would block waiting for a newline.

I thought sys.stdin was supposed to behave like a File object.
In Python Shell it's actually idlelib.rpc.RPCProxy, but that's
understandable. But shouldn't it support read()?

And without termios (unavailable on Windows), how would I
set the file to nonblocking read mode? PyWin32 doesn't seem to
have any help, but I might just have missed it.

I assume a programming language & system would have a pretty
simple way to get input from the user!

Thanks,
Jeff

PS: Python rocks. I've used it a lot, but so far only on UNIX,
and generally for filters or web scripts -- haven't needed to
ask any questions before.

 
Reply With Quote
 
 
 
 
Dennis Lee Bieber
Guest
Posts: n/a
 
      09-04-2004
On Sat, 04 Sep 2004 11:23:12 -0400, Jeff Learman <(E-Mail Removed)>
declaimed the following in comp.lang.python:

>
> I want to do a very simple thing in Windows. (Using Python Shell.)
>
> I want to write a prompt to sys.stdout and read the user input.
> (Ideally, without waiting for a newline.)
>

Library reference
Section 22 (M$ specific)
Subsection .1.2 (Console I/O)

lib> kbhit( )
lib> Return true if a keypress is waiting to be read.
lib>
lib> getch( )
lib> Read a keypress and return the resulting character. Nothing is
echoed to the console. This call will block if a keypress is not already
available, but will not wait for Enter to be pressed. If the pressed key
was a special function key, this will return '\000' or '\xe0'; the next
call will return the keycode. The Control-C keypress cannot be read with
this function.
lib>
lib> getche( )
lib> Similar to getch(), but the keypress will be echoed if it
represents a printable character.
lib>
lib> putch( char)
lib> Print the character char to the console without buffering.
lib>
lib> ungetch( char)
lib> Cause the character char to be ``pushed back'' into the console
buffer; it will be the next character read by getch() or getche().

stdin tends to be buffered by the OS -- the OS doesn't release
anything until the new-line. You have to use OS specific operations to
get to the data in the buffer.

--
> ================================================== ============ <
> http://www.velocityreviews.com/forums/(E-Mail Removed) | Wulfraed Dennis Lee Bieber KD6MOG <
> (E-Mail Removed) | Bestiaria Support Staff <
> ================================================== ============ <
> Home Page: <http://www.dm.net/~wulfraed/> <
> Overflow Page: <http://wlfraed.home.netcom.com/> <

 
Reply With Quote
 
 
 
 
Jeff Learman
Guest
Posts: n/a
 
      09-04-2004

(sheepish grin: didn't see the MS-specific chapter!)

Thanks

Dennis Lee Bieber wrote:

> On Sat, 04 Sep 2004 11:23:12 -0400, Jeff Learman <(E-Mail Removed)>
> declaimed the following in comp.lang.python:
>
>
>>I want to do a very simple thing in Windows. (Using Python Shell.)
>>
>>I want to write a prompt to sys.stdout and read the user input.
>>(Ideally, without waiting for a newline.)
>>

>
> Library reference
> Section 22 (M$ specific)
> Subsection .1.2 (Console I/O)
>
> lib> kbhit( )
> lib> Return true if a keypress is waiting to be read.
> lib>
> lib> getch( )
> lib> Read a keypress and return the resulting character. Nothing is
> echoed to the console. This call will block if a keypress is not already
> available, but will not wait for Enter to be pressed. If the pressed key
> was a special function key, this will return '\000' or '\xe0'; the next
> call will return the keycode. The Control-C keypress cannot be read with
> this function.
> lib>
> lib> getche( )
> lib> Similar to getch(), but the keypress will be echoed if it
> represents a printable character.
> lib>
> lib> putch( char)
> lib> Print the character char to the console without buffering.
> lib>
> lib> ungetch( char)
> lib> Cause the character char to be ``pushed back'' into the console
> buffer; it will be the next character read by getch() or getche().
>
> stdin tends to be buffered by the OS -- the OS doesn't release
> anything until the new-line. You have to use OS specific operations to
> get to the data in the buffer.
>


 
Reply With Quote
 
Jeff Learman
Guest
Posts: n/a
 
      09-04-2004

Hmm, getch() and getche() don't block.

The lib ref page says, "Read a keypress and return the resulting
character. Nothing is echoed to the console. This call will block if a
keypress is not already available, but will not wait for Enter to be
pressed." However:

import msvcrt

print msvcrt.kbhit()
print "prompt: ",
ch = msvcrt.getche()
print
print ord(ch)

Results -- without typing a key:

0
prompt:
255

Any ideas?

Thanks,
Jeff

Dennis Lee Bieber wrote:

> On Sat, 04 Sep 2004 11:23:12 -0400, Jeff Learman <(E-Mail Removed)>
> declaimed the following in comp.lang.python:
>
>
>>I want to do a very simple thing in Windows. (Using Python Shell.)
>>
>>I want to write a prompt to sys.stdout and read the user input.
>>(Ideally, without waiting for a newline.)
>>

>
> Library reference
> Section 22 (M$ specific)
> Subsection .1.2 (Console I/O)
>
> lib> kbhit( )
> lib> Return true if a keypress is waiting to be read.
> lib>
> lib> getch( )
> lib> Read a keypress and return the resulting character. Nothing is
> echoed to the console. This call will block if a keypress is not already
> available, but will not wait for Enter to be pressed. If the pressed key
> was a special function key, this will return '\000' or '\xe0'; the next
> call will return the keycode. The Control-C keypress cannot be read with
> this function.
> lib>
> lib> getche( )
> lib> Similar to getch(), but the keypress will be echoed if it
> represents a printable character.
> lib>
> lib> putch( char)
> lib> Print the character char to the console without buffering.
> lib>
> lib> ungetch( char)
> lib> Cause the character char to be ``pushed back'' into the console
> buffer; it will be the next character read by getch() or getche().
>
> stdin tends to be buffered by the OS -- the OS doesn't release
> anything until the new-line. You have to use OS specific operations to
> get to the data in the buffer.
>


 
Reply With Quote
 
Dennis Lee Bieber
Guest
Posts: n/a
 
      09-04-2004
On Sat, 04 Sep 2004 16:35:00 -0400, Jeff Learman <(E-Mail Removed)>
declaimed the following in comp.lang.python:


> Any ideas?
>

Seems to work here (W98SE, "MS-DOS PROMPT" window)...

G:\>type t.py
import msvcrt

print msvcrt.kbhit()
print "prompt: ",
ch = msvcrt.getche()
print
print ord(ch)

G:\>python t.py
0
prompt: a
97

G:\>python t.py
0
prompt:
0


Note -- the second one was <ctrl-@>; IOW, a "null" byte.

G:\>type t.py
import msvcrt

print msvcrt.kbhit()
print "prompt: ",
ch = msvcrt.getche()
print
print `ch`


G:\>python t.py
0
prompt:
'\x00'

--
> ================================================== ============ <
> (E-Mail Removed) | Wulfraed Dennis Lee Bieber KD6MOG <
> (E-Mail Removed) | Bestiaria Support Staff <
> ================================================== ============ <
> Home Page: <http://www.dm.net/~wulfraed/> <
> Overflow Page: <http://wlfraed.home.netcom.com/> <

 
Reply With Quote
 
Jeff Learman
Guest
Posts: n/a
 
      09-05-2004

Aha. It works for me too, if I run from DOS prompt.
It's only failing when I run from IDLE Python Development Environment.
I'll file a bug report.

Thanks for your help! I'd be happy to help you out in return;
just let me know if you want some piano or Hammond organ tracks
for original recordings

Jeff

Dennis Lee Bieber wrote:

> On Sat, 04 Sep 2004 16:35:00 -0400, Jeff Learman <(E-Mail Removed)>
> declaimed the following in comp.lang.python:
>
>
>
>>Any ideas?
>>

>
> Seems to work here (W98SE, "MS-DOS PROMPT" window)...
>
> G:\>type t.py
> import msvcrt
>
> print msvcrt.kbhit()
> print "prompt: ",
> ch = msvcrt.getche()
> print
> print ord(ch)
>
> G:\>python t.py
> 0
> prompt: a
> 97
>
> G:\>python t.py
> 0
> prompt:
> 0
>
>
> Note -- the second one was <ctrl-@>; IOW, a "null" byte.
>
> G:\>type t.py
> import msvcrt
>
> print msvcrt.kbhit()
> print "prompt: ",
> ch = msvcrt.getche()
> print
> print `ch`
>
>
> G:\>python t.py
> 0
> prompt:
> '\x00'
>


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
peek at stdin, flush stdin Johnathan Doe C Programming 5 05-17-2013 04:30 PM
How to pass stdin of a C++ program to the stdin of a process createdwith ShellExecute() Ben C Programming 2 08-29-2009 09:47 PM
Non blocking socket keep blocking on read ? Serge Savoie Ruby 4 10-01-2008 03:16 PM
Non blocking read from stdin on windows. barr Python 1 12-25-2004 11:12 PM
Reading stdin once confuses second stdin read Charlie Zender C Programming 6 06-21-2004 01:39 PM



Advertisments