Is it possible?: cat text.txt | python_script_which_also_gets_user_input.py

[Donn Cave]

Quoth "Robert M. Emmons" <RobMEmmons at 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, donn at drizzle.com