Raw_input with readline in a daemon thread makes terminal text disappear

John O'Hagan research at johnohagan.com
Tue Oct 20 06:40:24 EDT 2009


On Mon, 19 Oct 2009, Aahz wrote:
> In article <mailman.1448.1255618675.2807.python-list at python.org>,
> 
> John O'Hagan <research at johnohagan.com> wrote:
> >I'm getting input for a program while it's running by using raw_input in a
> >loop in separate thread. This works except for the inconvenience of not
> > having a command history or the use of backspace etc.
> >
> >That can be solved by loading the readline module; however, it results in
> > a loss of visible access to the terminal when the program ends: nothing
> > is echoed to the screen and the history is invisible (although it is
> > there - hitting return executes whatever should be there normally). The
> > only way to get it back is to close the terminal and open a new one.
> 
> Can you restructure your program so that input gets handled in the main
> thread?
> 
I can, but then I can't Ctrl+C out of the main program (which is a thread in 
that scenario). This applies with or without readline loaded. I have seen 
some, um, threads on this subject, and from memory it's complicated.

The raw_input and readline docs mention that the former uses the latter for 
history and line-editing features. I haven't been able to find out exactly how, 
but a theory occurs to me that the pair together somehow temporarily "steal" 
control of the command-line while raw_input is accepting input - at least this 
would explain the missing command-line when raw_input is terminated in a 
daemon thread.

Since posting this question, I worked around it by making the input loop 
thread non-daemon, and having it run only while an Event object's flag is set - 
it's unset at the end of the program. That way, I just have to hit return one 
more time to let the loop find the unset flag and we can exit cleanly.

This has the unplanned benefit that the closing of the separate output window 
(a terminal in a subprocess, listening on a socket) can also wait on the same 
flag, so the workaround looks as if it's on purpose.  ;) 

Still open to any cleaner suggestions, of course.

Regards and thanks,

John



More information about the Python-list mailing list