W. Cole Davis wrote on 2011-04-08 15:52: > I apologize for the delayed response to your quick one. Unfortunately > the change to sys.stdin.fileno() does not change the problem because it > returns the same value. I think there might be a flaw in my approach to > attempting to use urwid here in a non-conventional way so let me explain > further. > > I have a Python project that is originally executed by mpi using the > SPMD model. So the application is run on multiple processes across > multiple nodes. The application determines what type of node it is on > and executes the application path appropriate for its type. In fact the > only node that acts differently from the rest is on the head-node. The > head-node is the only node to import and execute urwid, but mpi routes > all of the application output (stdout, stdin, stderr...) back to the > head-node (which is great) but it also pipes the head-nodes output to a > separate output buffer. I believe this is what causes the problem. Is > there was a way for me to interface with the raw_display.Screen object > to create one with the correct fd (which I would determine) prior to it > running its own start? Seems improbable considering its built into its > constructor.
You should be able to make a raw_display.Screen subclass that sets changes the values of self._term_output_file and self._term_input_file. Or you could set sys.stdin and sys.stdout to different files before initializing the screen. The tcgetattr/tcsetattr calls in start and stop should be fixed to use the fd from self._term_input_file instead of the present hard-coded value of 0 as well. (I'll accept a patch) Ian _______________________________________________ Urwid mailing list [email protected] http://lists.excess.org/mailman/listinfo/urwid
