This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rickbking
Recipients ajaksu2, draghuram, rickbking
Date 2008-04-08.17:37:42
SpamBayes Score 0.00320511
Marked as misclassified No
Message-id <>
In-reply-to <>
(this is really 2 mails because my home email address was not registered so they were rejected at first)
Right - I wasn't too clear. The module stashes stdin, whether from sys 
or passed in, in self.stdin. When it reads input it uses a flag 
"raw_input" to determine whether to use raw_input or 
self.stdin.readline(), but the flag is not reset when a different stdin 
is passed in, so raw_input is always true.

The flag should be True/False, and I didn't think of setting it directly 
to be honest because it never occurred to me that I should have to do that to get a cmd class that i just instantiated with a different input object to use the one it was created with. I think the flag should be eliminated and replaced 
with the test self.stdin == sys.stdin anyway.

I also entered a feature request to add a stack of stdin's which are 
stacked when you want to process lines in a file, and then pop off the 
stack automatically at end of file. This would make it easy to write a 
command-line tool, like i'm doing, so that any input object could enter commands that change to other input objects and then restore the previous input object....this would allow for nesting of command files. There would be special conditions for 
sys.stdin (sys.stdin can only be used if there are no items on the 
stack). This could all be done outside the module, but it's so easy when 
it's integrated right in there.

I think I understand better what you are getting at, but it makes more 
sense to me to be explicit in the code and not take advantage of the 
fact the raw_input always works off sys.stdin. Also, I see now that 
maybe the idea was to have raw_input be changeable so that you could 
switch back and forth between "stdin" (whatever that is), and some other 
input object - I'm having a hard time seeing the usefulness of that, 
though. Anyway, instantiating a cmd class with a non-stdin input object 
and then having to set raw_input to False to get it to use that input 
object seems wrong.
does this make sense?
-Rick King

Daniel Diniz wrote:
> Daniel Diniz <> added the comment:
> I don't think it should stop using raw_input just because you changed
> stdin, as you can change it to something that will work with raw_input.
> Consider:
>>>> import sys
>>>> sys.stdin = open("/dev/tty")
>>>> raw_input()
> a
> 'a'
> You can tie it to any object (e.g. a GUI input) that supports the file
> protocol and keep using raw_input. Or change Cmd.use_rawinput to 0 to
> use stdin.readline directly.
> On a related issue. Cmd.use_rawinput should be "True", not 1...
> ----------
> nosy: +ajaksu2
> __________________________________
> Tracker <>
> <>
> __________________________________
Date User Action Args
2008-04-08 17:37:47rickbkingsetspambayes_score: 0.00320511 -> 0.00320511
recipients: + rickbking, draghuram, ajaksu2
2008-04-08 17:37:45rickbkinglinkissue2571 messages
2008-04-08 17:37:42rickbkingcreate