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

[Hans Dembinski]

Hi there,

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
guys.

 

[Robert M. Emmons]

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.

Rob

 

[Donn Cave]

Quoth "Robert M. Emmons" <[email protected]>:
|> 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, (e-mail address removed)

 

[Hans Dembinski]

Thank you for your ideas, that really helped me.
It works now.

So the answer to my question is YES.