Quoth "Robert M. Emmons" <Ro********@cs.com>:
|> I run in a problem with a script, that shall work similar like the c-program
|> "most". It should be able to get some text on execution via a pipe but also
|> is interactive by the user via the curses module (for scrolling and stuff).
|> The problem is: if you call the script like that, you connect stdin to
|> text.txt and any later keyboard input is ignored, since curses also reads
|> from stdin.
|> I have the rather blurry impression that this could be possible with
|> threading or forking inside the script, but I nether did things like that
|> before and am hopeful to get some cool advice from you experienced
|
| I'm not sure, I've not tried this. The suggestion I'd have is redirect
| the the input that curses reads to /dev/tty if you can figure out how to
| do that.
|
| Python does have some redirection capability built in the the sys
| module, i.e. it's possible to separate sys.stdin and sys.__stdin__ and
| handle them sepratelty. Just for tty direct IO, that would be easy. I
| just don't know about curses, because it probably is outside of python.
/dev/tty sounds like a good bet to me -- assuming we're on UNIX.
I wouldn't waste much time on sys.stdin - might work, but likely
sys.stdin is irrelevant to curses. File redirection that's effective
across all I/O in the process happens at the UNIX file descriptor
level, with functions like posix.dup2(). Try this -
txt = os.fdopen(os.dup(0), 'r')
os.close(0)
os.open('/dev/tty', os.O_RDONLY)
I believe some applications in this position simply use unit 2,
rather than opening /dev/tty, since it's highly likely to be open
on the terminal. While 2 is normally used for write access only,
0, 1 and 2 are all just dups of the same read/write file descriptor
open on the tty.
Donn Cave,
do**@drizzle.com 
